[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] SAML 2.0 Constrained Delegation Profile
Anne, Thanks for your note with links to recent XACML outputs. As I understand it, the scope for the SSTC effort is modest - some means of expressing constrained delegation within a SAML assertion. I should have a draft (vs e-mail) published by the 30th. I dont believe there is any direct overlap with XACML efforts in the area of delegation policy. So the answer to your question [A] below is: it isn't in scope for us. Of course, how XACML might choose to use SAML assertions to convey policy or delegation-related matter is another matter. I would hope there would be some way to layer such usage on top of the SAML delegation profile. Why don't we plan on a follow-up discussion in mid-january? Is this a reasonable approach? - prateek >[A] >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 >> >> > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]