[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] SAML 2.0 Constrained Delegation Profile
Hi Prateek, How does one know that a particular subject is allowed to delegate to another subject? The SSTC should be aware of work going on in the XACML TC with respect to delegation. The most recent draft specification is: XACML v3.0 administration policy Working Draft 10, 5 December 2005: http://www.oasis-open.org/committees/download.php/15764/access_control-xacml-3.0-admininstration-wd-10.zip This allows XACML policies to be used to control delegation chains. Such chains could be used to control which identity tokens can be used, and for which audiences, as well as many other types of restrictions. We have discussed using SAML to carry these delegation policies, as well as carrying Attributes connected with delegation. Would a joint meeting be useful in discerning whether there are actually two different categories of use cases here? Regards, Anne Anderson Prateek Mishra wrote On 12/05/05 22:30,: > > ------------------------------------------------------------------------ > > 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 > > > ------------------------------------------------------------------------ > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php -- Anne H. Anderson Email: Anne.Anderson@Sun.COM Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]