OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[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]