From: <go...@us...> - 2012-09-17 19:42:49
|
Revision: 14303 http://unicore.svn.sourceforge.net/unicore/?rev=14303&view=rev Author: golbi Date: 2012-09-17 19:42:43 +0000 (Mon, 17 Sep 2012) Log Message: ----------- Added UVOS attr profiles and clients sec section. Content is complete. Modified Paths: -------------- documentation/trunk/securityArchitecture/attributes.txt documentation/trunk/securityArchitecture/biblio.txt documentation/trunk/securityArchitecture/intro.txt documentation/trunk/securityArchitecture/profiles.txt Modified: documentation/trunk/securityArchitecture/attributes.txt =================================================================== --- documentation/trunk/securityArchitecture/attributes.txt 2012-09-17 19:22:14 UTC (rev 14302) +++ documentation/trunk/securityArchitecture/attributes.txt 2012-09-17 19:42:43 UTC (rev 14303) @@ -67,26 +67,12 @@ For the pull mode other servers can be used as well as UVOS: XUUDB and LDAP. Attributes stored in a local file can be considered also a trivial 'pull' solution. -Pushed SAML Attribute assertion requirements -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +There are several rules for SAML attribute assertions, which must be followed if the assertion +is going to be pushed to UNICORE server. Those rules are specified in section <<sec-saml-push-req>>. -In order to push SAML Attribute assertion the following rules MUST be fulfilled: -* The assertion MUST be inserted in the SOAP header element, in accordance to -the SOAP profile of the <<wss-saml>>, i.e. under the +<wss:Security>+ element. -* The assertion MUST NOT contain any +Audience+ restriction. -* The assertion MUST contain neither +Recipient+ nor +Address+ elements in +SubjectConfirmationData+. -* The assertion SubjectConfirmation method SHOULD be set to +urn:oasis:names:tc:SAML:2.0:cm:sender-vouches+. -* The assertion MUST NOT contain the +OneTimeUse+ restriction. -* The assertion +Subject+ element MUST be of +urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName+ type. -* The assertion MUST be signed by its Issuer. - -All other rules of the <<saml-core>> specification regarding attribute assertions MUST be fulfilled. - - - Distinguished attributes in UNICORE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Modified: documentation/trunk/securityArchitecture/biblio.txt =================================================================== --- documentation/trunk/securityArchitecture/biblio.txt 2012-09-17 19:22:14 UTC (rev 14302) +++ documentation/trunk/securityArchitecture/biblio.txt 2012-09-17 19:42:43 UTC (rev 14303) @@ -18,6 +18,8 @@ - [[[rfc2818]]] RFC 2818, HTTP Over TLS http://tools.ietf.org/html/rfc2818 - [[[saml-core]]] Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0 http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf +- [[[saml-profiles]]] Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0 +http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf - [[xacml]] OASIS eXtensible Access Control Markup Language (XACML) https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml - [[emi-xacml-profile]] EMI Common XACML Authorization Profile v.1.1 Modified: documentation/trunk/securityArchitecture/intro.txt =================================================================== --- documentation/trunk/securityArchitecture/intro.txt 2012-09-17 19:22:14 UTC (rev 14302) +++ documentation/trunk/securityArchitecture/intro.txt 2012-09-17 19:42:43 UTC (rev 14303) @@ -116,9 +116,23 @@ can not modify it. - - Security on the client side ~~~~~~~~~~~~~~~~~~~~~~~~~~~ -*TODO* +The standard library used for making client calls offers two factories for creating web service proxies: + + * +XFireClientFactory+ creates WS proxy, which will use a plain UNICORE client. The client will support + SSL and authentication, but won't cope with delegation or digital signatures. + * +UnicoreXFireClientFactory+ extends the above factory by configuring the handlers adding delegation and + producing digital signatures. + +There are two handlers performing the UNICORE-specific security work on the client side (both configured by the +latter factory): + + * +ExtendedTDOutHandler+ can insert a provided trust delegations into a request header, + if needed also the User assertion (with requested user or with other preferences). Additionally the handler + is capable of extending the delegation chain to the peer which is going to be contacted. See the <<sec-etd>> section + for details about delegations and request preferences. + * +DSigOutHandler+ is selectively signing the outgoing messages, using a configurable policy. See the + <<sec-nonrep>> section for details about the role of request signing. + Modified: documentation/trunk/securityArchitecture/profiles.txt =================================================================== --- documentation/trunk/securityArchitecture/profiles.txt 2012-09-17 19:22:14 UTC (rev 14302) +++ documentation/trunk/securityArchitecture/profiles.txt 2012-09-17 19:42:43 UTC (rev 14303) @@ -287,16 +287,172 @@ 'Subject' attributes of 'String' type. If there is a name clash, i.e. when generic attribute name is equal to one of the profile's predefined attributes, then the generic one is not available. +[[sec-saml-push-req]] +Pushed SAML Attribute assertion requirements +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +In order to push SAML Attribute assertion the following rules MUST be fulfilled: +* The assertion MUST be inserted in the SOAP header element, in accordance to +the SOAP profile of the <<wss-saml>>, i.e. under the +<wss:Security>+ element. +* The assertion MUST NOT contain any +Audience+ restriction. +* The assertion MUST contain neither +Recipient+ nor +Address+ elements in +SubjectConfirmationData+. +* The assertion SubjectConfirmation method SHOULD be set to +urn:oasis:names:tc:SAML:2.0:cm:sender-vouches+. +* The assertion MUST NOT contain the +OneTimeUse+ restriction. +* The assertion +Subject+ element MUST be of +urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName+ type. +* The assertion MUST be signed by its Issuer. + +All other rules of the <<saml-core>> specification regarding attribute assertions MUST be fulfilled. + + [[sec-uvos-profile]] -UVOS Attribute profile +UVOS attribute profile ~~~~~~~~~~~~~~~~~~~~~~ -*TODO* +UVOS uses extensively scoped attributes and representation of scoping is not defined in the core +SAML specification. +UVOS attribute names are the same attribute names as those visible in UVOS - there is one to one +mapping. The only special, pre-defined attribute name is an attribute used to carry the group membership +information. The attribute used for this purpose MUST have a name +urn:SAML:voprofile:group+. Values of +this attribute are groups, where the assertion subject is a member. -UVOS Attribute query profile +UVOS attributes MUST conform to the XACML attribute profile, as defined in <<saml-profiles>>. In particular +all attributes MUST have the +DataType+ attribute set with a value being the XACML type of the attribute +and +NameFormat+ equal to +urn:oasis:names:tc:SAML:2.0:attrname-format:uri+. + +SAML mandates to have a single occurrence of each attribute in assertion and it can happen that one SAML +assertion must carry the same attribute but valid in different scopes. Therefore the basic scoping is +defined on attribute value level. + +Attribute-wide scope CAN be used only for attributes without any value, which are defined only +in a scope of a single group. +\{urn:vo:SAML:2.0:attribute:ext\}attributeScope+ +attribute of the SAML +Attribute+ element is defined to carry the scope value. The scope is expressed using the +normal '/'-separated notation of group encoding. Lack of the scope attribute or the +/+ scope mark +a global (i.e. not scoped) attribute. Note that by default UVOS does not use this attribute wide scope, +in responses but the ScopedValue encoding with a single, scoped, nil attribute value (see below). However this +format is useful in queries, when a query is made for a specific, scoped attribute but +without any restrictions on values. + +Attribute value scope MUST be used all other cases for attributes which has at least one scoped value. +There are two possible formats of encoding the attribute value scope. The +AttributeValue+ element's attribute ++\{urn:vo:SAML:2.0:attribute:ext\}scopeType+ +MUST be used to define the scoping type used. The value of the attribute MUST be one of the following: + + * +urn:SAML:voprofile:SimpleScopedString+. This scoping type can be used only for string attribute values. Attribute + value itself is modified to carry the scope as follows: the fixed letter +@+ is appended to the original value and + then the scope. If a scoped attribute has no value defined in a group, then SAML attribute value is added, + only with the scope defined (i.e. the value starts from +@+). + * +urn:SAML:voprofile:ScopedValue+. This scoping type is defined by another attribute of the +AttributeValue+ element, + the +\{urn:vo:SAML:2.0:attribute:ext\}scope+. Its value MUST carry the attribute value scope. What is more, + the XACML DataType attribute of attribute value using this scoping type, MUST have the + +urn:SAML:voprofile:ScopedAttribute+ value. If a scoped attribute has no value defined in a group, then + an empty (nil) SAML attribute value is added, with the scope defined. + * +urn:SAML:voprofile:NonScopedValue+. This value means that the value is global, i.e. not scoped. + +Note 2: it is not possible to pass 'null' value of attribute using UVOS encoding. + +The XML schema defining the attributes which can be used to define AttributeValue scoping and the rules +used to choose scope expression format are provided in the next section. + +Example encoding of attribute 'a1' with one value 'v1', valid in group '/g' and 'a1' without value in group '/g1' +using ScopedValue: +--------- +<urn:Attribute Name="a1" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" + urnx0:DataType="urn:SAML:voprofile:ScopedAttribute" + urnx1:scopeType="urn:SAML:voprofile:ScopedValue" + xmlns:urnx0="urn:oasis:names:tc:SAML:2.0:profiles:attribute:XACML" + xmlns:urnx1="urn:vo:SAML:2.0:attribute:ext"> + <urn:AttributeValue urnx1:scope="/g" + xsi:type="urnx1:ScopedStringAttributeValueType">v1</urn:AttributeValue> + <urn:AttributeValue urnx1:scope="/g1" + xsi:nil="true" xsi:type="urnx1:ScopedStringAttributeValueType"/> +</urn:Attribute> +--------- + +Example encoding of attribute 'a2' with one value 'v1', valid in group '/g2' using SimpleScopedString: +--------- +<urn:Attribute Name="a2" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" + urnx0:DataType="http://www.w3.org/2001/XMLSchema#string" + urnx1:scopeType="urn:SAML:voprofile:SimpleScopedString" + xmlns:urnx0="urn:oasis:names:tc:SAML:2.0:profiles:attribute:XACML" + xmlns:urnx1="urn:vo:SAML:2.0:attribute:ext"> + <urn:AttributeValue xsi:type="xs:string" + xmlns:xs="http://www.w3.org/2001/XMLSchema" + xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">v1@/g2</urn:AttributeValue> +</urn:Attribute> +--------- + +Example encoding of group membership information: +--------- +<urn:Attribute FriendlyName="Group membership" + Name="urn:SAML:voprofile:group" + NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" + urnx0:DataType="http://www.w3.org/2001/XMLSchema#string" + xmlns:urnx0="urn:oasis:names:tc:SAML:2.0:profiles:attribute:XACML"> + <urn:AttributeValue xsi:type="xs:string" + xmlns:xs="http://www.w3.org/2001/XMLSchema">/g/sub</urn:AttributeValue> + <urn:AttributeValue xsi:type="xs:string" + xmlns:xs="http://www.w3.org/2001/XMLSchema">/g</urn:AttributeValue> +</urn:Attribute> +--------- + + +UVOS attribute query profile ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -*TODO* +UVOS supports one extension of SAML attribute query protocol. It allows to specify interest +only in attributes valid in a particular group (i.e. scoped in this group and globally valid). +To express such request a client has to place a +RequestedGroupScope+ element containing a +group, according to the XML schema defined below. + +UVOS fully supports requests for scoped attributes, i.e. putting scoped attributes in a SAML query +will result in returning attributes of the same scope. This behavior follows the core SAML specification rules. + +If the SAML query contains attributes, then scoping type used in response is the same as in the query. +If the query does not contain attributes (i.e. it is a query for all attributes), then the ++urn:SAML:voprofile:ScopedValue+ type is used by default. + +The XML schema defining the attribute query scoping extension and attribute value scope related attributes follows: + +------------- +<schema targetNamespace="urn:vo:SAML:2.0:attribute:ext" + xmlns:ext="urn:vo:SAML:2.0:attribute:ext" + xmlns="http://www.w3.org/2001/XMLSchema" + xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" + elementFormDefault="qualified" attributeFormDefault="qualified"> + + <import namespace="urn:oasis:names:tc:SAML:2.0:assertion" + schemaLocation="saml-schema-assertion-2.0.xsd" /> + + + <complexType name="RequestedGroupScopeType"> + <sequence> + <element name="Group" type="string" maxOccurs="unbounded" /> + </sequence> + </complexType> + <element name="RequestedGroupScope" + type="ext:RequestedGroupScopeType" /> + + <element name="RequestedAttributeDataType" type="string" /> + + <attributeGroup name="BaseVOAttributesGroup"> + <attribute name="scope" type="string" use="optional" /> + <attribute name="scopeType" type="string" use="optional" /> + </attributeGroup> + + <complexType name="ScopedStringAttributeValueType"> + <simpleContent> + <extension base="string"> + <attributeGroup ref="ext:BaseVOAttributesGroup" /> + </extension> + </simpleContent> + </complexType> +</schema> +------------- + + + + + + This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. |