[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wss] the saml token profile depends on non-global attributes in key identifier/wsse schema does not support keyIdentifier element extensibility
Ron, It sounds to me like your approach is on the right track. In particular, you divide the problem into two categories: 1. the self-contained message that includes the saml:Assertion referenced in the KeyIdentifier with a Direct Reference URI. This category appears not to have any issues. 2. the external case where the saml:Assertion needs to be acquired from outside the message. In this case, as you suggest, the SecurityTokenReference is element-extensible, and the necessary info to acquire the assertion can be contained in one or more elements added to the STR. In addition the KeyIdentifier, which is attribute-extensible, can have attributes indicating that the extended STR elements can be used to access the assertion. This seems to me to be consistent with the intent of the WS core spec and usage of the STR. One suggestion to consider is the following: saml:Assertions can be generally accessed by either AssertionIDReference or AssertionArtifact, both of which are saml-defined elements. The suggestion is to include one or the other of these elements along with the saml:AuthorityBinding in order that a processing application has the general options available to access the assertion from the authority. Possibly, the KeyIdentifier could be augmented when the ValueType is "saml:Assertion" to have an additional attribute such as AccessMethod="Remote", which would suggest to the processor to look for the additional STR elements for accessing assertions. Rich -----Original Message----- From: Ron Monzillo [mailto:Ronald.Monzillo@Sun.COM] Sent: Wednesday, January 21, 2004 4:59 PM To: Chris Kaler Cc: wss@lists.oasis-open.org; Levinson, Richard Subject: Re: [wss] the saml token profile depends on non-global attributes in key identifier/wsse schema does not support keyIdentifier element extensibility Chris Kaler wrote: >The have historically been problems mixing content type. This is >currently a simple type and it sounds like SAML needs a complex type. >I think that in this case it might be advantageous to separate them. >Maybe we should think about a KeyReference in V1.1 which SAML and >others could use to specify more structured types of references? >Thoughts? > > That would work for the future. Do you think the approach I outline below is appropriate given the 1.0 wsse schema? That is, I don't think the outlined approach is an example of mixing content. The keyIdentifier remains simple, but in some cases it depends on an additional element being conveyed in the encompassing STR. Ron >-----Original Message----- >From: Ron Monzillo [mailto:Ronald.Monzillo@Sun.COM] >Sent: Wednesday, January 21, 2004 1:37 PM >To: Chris Kaler >Cc: wss@lists.oasis-open.org; Levinson, Richard >Subject: Re: [wss] the saml token profile depends on non-global >attributes in key identifier/wsse schema does not support keyIdentifier >element extensibility > > > >Chris Kaler wrote: > > > >>Sorry, I mis-read as attributes. >> >>For this case why not just define a new SAMLKeyIdentifier element >>which has the specific content you need and parallel what DSig did for >>X.509? >> >> >> >> >I think that would work, but I would prefer to be able to work within >the existing alternatives of direct reference and key identifier. > >Perhaps the element you suggest could extend keyIdentifier, although I >have seen recommendations that advocate that extensibility by >derivation be applied to abstract as apposed to concrete types. > >What do you think ofthe following > >* A key identifier reference - a generic element (i.e. ><wsse:KeyIdentifier>) that conveys a security token identifier as a ><wsse:EncodedString> and indicates in its attributes (as necessary) the >key identifier type (i.e. the <wsse:ValueType>), the identifier encoding > >type (i.e. the <wsse:EncodingType>), and any other parameters necessary >to reference the security token. > >When a key identifier is used to reference a SAML assertion, the key >identifier MUST contain as its element value the corresponding ><saml:AssertionID>. The key identifier MUST also contain a ><wsse:ValueType> attribute and the value of this attribute MUST be the >wsse:KeyIdentifier/@ValueType from Table 2. When the ><wsse:EncodingType>xsi:string. attribute is not specified, the element >value of the key identifier MUST be encoded as > >When a key identifier is used to reference a SAML Assertion that MUST >be > >acquired from an assertion authority, a <saml:AuthorityBinding> element >MUST be contained in the <wsse:SecurityTokenReference> element >containing the key identifier. The contents of the ><saml:AuthorityBinding> element MUST be as defined in SAMLCore ><#saml_core>. > > > >>-----Original Message----- >>From: Ron Monzillo [mailto:Ronald.Monzillo@Sun.COM] >>Sent: Wednesday, January 21, 2004 11:28 AM >>To: Chris Kaler >>Cc: wss@lists.oasis-open.org; Levinson, Richard >>Subject: Re: [wss] the saml token profile depends on non-global >>attributes in key identifier/wsse schema does not support keyIdentifier >>element extensibility >> >>Chris, >> >>Attribute and element extensibility are different. >>You can have any attribute in keyIdentifier, but >>you can't have any element. >> >>To use a keyIdentifier to reference an off msg >>SAML assertion, we need to know the saml:location >>and saml:binding attributes to be able to dereference >>the assertion id. The saml attributes are not global, thus they cannot >>be directly included in keyIdentifier via its attribute extensibility >>(although they could be cloned). >> >>SAML defines a global element called AuthorityBinding that contains >>the saml:location and saml:binding attributes. The AuthorityBinding >>element could have been directly included in keyIdentifier if >>EncodedString supported element extensibility. >> >>My long term preference is to use a Direct Reference, but SAML is in >>the process of defining URI reference forms. >> >>My current thinking is that I will advocate including a >>saml:AuthorityBinding >>element at the top of the STR, when location and or binding attributes >>are >>needed to interpret a contained keyIdentifier. >> >>What do you think and thanks for answering. >> >>Ron >>Chris Kaler wrote: >> >> >> >> >> >>>I believe if you trace back the type of EncodedString you will find >>> >>> >>> >>> >>that >> >> >> >> >>>it does support attribute extensibility. EncodedString extends >>>AttributedString which allows for any attributes: >>> >>> <xsd:anyAttribute namespace="##other" processContents="lax"/> >>> >>>What am I missing? >>> >>>-----Original Message----- >>>From: Ron Monzillo [mailto:Ronald.Monzillo@Sun.COM] >>>Sent: Tuesday, January 20, 2004 2:04 PM >>>To: wss@lists.oasis-open.org >>>Cc: Levinson, Richard >>>Subject: [wss] the saml token profile depends on non-global attributes >>>in key identifier/wsse schema does not support keyIdentifier element >>>extensibility >>> >>>The schema for wsse:KeyIdentifier does not support element >>>extensibility. >>> >>>The SAML token profile relies on non-global saml attributes (i.e. >>>saml:local >>>and saml:binding) to format keyIdentifier SecurityTokenReferences. >>> >>>The non-global attributes could be replaced with the global >>>saml:AuthorityBinding >>>element, if the wsse:KeyIdentifier supported element extensibility. >>> >>>There are 2 paths forward. >>> >>>. Modify the wsse:schema to allow any element to be included in >>>keyIdentifiers >>> >>>. use Direct References with an optional contained AuthorityBinding >>>element to reference SAML assertions, when the authority and binding >>>must be sepcified >>>to acquire the assertion. >>> >>>I am working on modifying the profile to take the latter approach, >>>but would appreciate feedback from the TC. >>> >>>Any comments? >>> >>>Ron >>> >>><xsd:complexType name="KeyIdentifierType"> >>>- >>> <xsd:annotation> >>><xsd:documentation>A security token key >>>identifier</xsd:documentation> </xsd:annotation> >>>- >>> <xsd:simpleContent> >>>- >>> <xsd:extension base="wsse:EncodedString"> >>><xsd:attribute name="ValueType" type="xsd:anyURI"/> </xsd:extension> >>></xsd:simpleContent> >>></xsd:complexType> >>> >>>Ron Monzillo wrote: >>> >>> >>> >>> >>> >>> >>> >>>>BTW, in section 3.3, we need to change the way SAML keyIdentifier >>>>references >>>>are composed, as the Binding and Location attributes are not global. >>>>Perhaps we can >>>>use the SAML AuthorityBinding construct, as apposed to its internal >>>>attributes. >>>> >>>> >>>> >>>> >>>> >>>> >>>To unsubscribe from this mailing list (and be removed from the roster >>> >>> >>> >>> >>of >> >> >> >> >>>the OASIS TC), go to >>>http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgr >>>o >>> >>> >u > > >>> >>> >>> >>> >>p >> >> >> >> >>>.php. >>> >>> >>> >>> >>> >>> >>> >> >> >> >> > > >To unsubscribe from this mailing list (and be removed from the roster >of the OASIS TC), go to >http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgrou >p.php. > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]