[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 inkey 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_workgro >>> >>> >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_workgroup.php. > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]