[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: SAML 2.0 Constrained Delegation Profile
SAML 2.0 Constrained Delegation Profile ----------------------------------- The contents of this note are modeled after [cantor-delegation]. Use-cases and motivation for this profile may be found in [morgan-use-case]. 0. Profile Identification URI: urn:oasis:names:tc:SAML:2.0:profiles:delegation 1. <saml:Assertion> Usage For the purpose of supporting delegation, the <saml:SubjectConfirmation> element is used to identify the delegate and the key to be used by it to confirm its identity, and the <saml:AudienceRestriction> element is used to signal the use of this profile and to identify the relying parties with whom the delegate can use the assertion to authenticate and authorize its activites on behalf of the principal. Other assertion contents MUST be interpreted as defined by the SAML 2.0 Assertions and Protocols specification [SAML2Core] and any applicable profiles of use. 1.1 <saml:SubjectConfirmation> Delegation permission in an assertion is expressed by including a <saml:SubjectConfirmation> element with a Method attribute equal to urn:oasis:names:tc:SAML:2.0:cm:holder-of-key in the assertion's <saml:Subject> element. Each delegate is identified with a distinct <saml:SubjectConfirmation> element that MUST contain: + a <saml:BaseID>, <saml:NameID>, or <saml:EncryptedID> element that names the delegate + a <saml:SubjectConfirmationData> element (with an xsi:type of saml:KeyInfoConfirmationDataType) containing at least one <ds:KeyInfo> element specifying a key belonging to the delegate Muliple keys MAY be included in multiple <ds:KeyInfo> elements, but each <ds:KeyInfo> element MUST identify a single key. A <saml:SubjectConfirmationData> element MAY include a standard set of XML attributes that restrict the confirmation process beyond requiring proof of key possession, such as Address, Recipient, NotBefore, and NotOnOrAfter [SAML2Core]. These attributes can be used to “finetune” the capability of the corresponding delegate to use the assertion. 1.2 <saml:AudienceRestriction> At least one <saml:AudienceRestriction> element containing a <saml:Audience> element with the value of urn:oasis:names:tc:SAML:2.0:profiles:delegation MUST be included in an assertion created in accordance with this profile. The use of the elements discussed in this profile in an assertion that does not contain this <saml:Audience> value are unspecified. Additional <saml:AudienceRestriction> elements MAY be included to constrain the delegation “scope” of an assertion by identifying a set of one or more relying parties who can accept the assertion. An SP (or IdP) can be designated by including its unique identifier in an included <saml:Audience> element. Alternatively, an affiliated set of service providers can be designated as a unit by including the affiliation's identifier. 2. Processing Model at Relying Party Relying parties must follow the processing model described in [SAML2Core] and any relevant profiles (e.g., [WSS-STP]). In addition, when when processing an assertion with <saml:AudienceRestrictionElement> set to: urn:oasis:names:tc:SAML:2.0:profiles:delegation relying parties MUST: (a) Ensure that the <saml:SubjectConfirmation> element associated with the delegate key MUST include one of the following as a sub-element: <saml:BaseID>, <saml:NameID>, or <saml:EncryptedID> (b) ensure that the values associated with the attesting entities <saml:BaseID>, <saml:NameID>, or <saml:EncryptedID> element correspond to system entities acceptable as delegators by the relying party. The means by which such a relationship is defined is outside the scope of this specification. (c) ensure that validity constraints implied by elements such as Address, Recipient, NotBefore, and NotOnOrAfter are met. ------------------------------------------------------- References: [cantor-delegation] SAML 2.0 Single Sign-On with Constrained Delegation, 01, October 2005 http://shibboleth.internet2.edu/docs/draft-cantor-saml-sso-delegation-01.pdf [morgan-use-case] Delegation/intermediaries use case model, 00, November 2003 http://www.oasis-open.org/apps/org/workgroup/security/download.php/4402/draft-morgan-sstc-delegation-model-00.pdf
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]