Re: [wss] Comments on SAML Token Profile

[Ron Monzillo <Ronald.Monzillo@Sun.COM>]

STP Implementations are currently interpreting the value of
wsse:SecurityTokenReference/wsse:Reference/@ValueType
to determine that they are looking for the saml AssertionId attribute.

Any code that interprets (local) Direct references, could
be parameterized to do its lookup based on id attribute name.

The addition of a new attribute to the wsse:Reference element to
indicate the name of the attribute could simplify the work of
interpetting the reference (mapping it to the right attribute name).

That said, it sounds like you are trying to build an index as you
go along, and you will likely encounter the references after the
elements for which the index must be built. As such, it sounds like we
are talking about techniques advocated by MPROF, and for which there
is some disagreement as to whether there is any disadvantage to building
the index with an extended list of attributes name (corresponding to the
token types you understand).

Any code that is building such an an index (before schema parsing)
of elements by wsu:id value, could be extended to build the
index based  on a list of supported id attribute names.

Knowing what id attribute names (for referenceable elements)
you support as a wss-security processor seems to be an important
aspect of making sure you don't put things in your id index,
that you don't support. Otherwise you will be wasting cycles.

I don't think spec changes are necessary

IMO, any requirement that tokens be wrapped such that the name of their
id attribute can be presumed adds unnecessary complexity to the things
interpretting the target tokens. Moreover, there already is a proliferation
of  token wrapping mechanisms given "embedded" STR's and
BinarySecurityTokens...where at most one should have been sufficient.

Ron

Anthony Nadalin wrote:

> (1) I don't see that there are different classes of tokens, the core 
> describes the behavior, and as others have pointed out it needs some 
> wording changes to be more clear
> (2) We successfully interoped but had all sorts of issues and this was 
> one of them, sure we can overcome anything in code, but we think that 
> if changed it will be in-line with the core
> (3) The REL token profile and schema use a wsu:Id, maybe the interop 
> document could have been a little more clear
>
> Anthony Nadalin | work 512.838.0085 | cell 512.289.4122
> "Levinson, Richard" <rlevinson@netegrity.com>
>
>
>                         "Levinson, Richard" <rlevinson@netegrity.com>
>
>                         06/24/2004 08:27 PM
>
> 	
>
> To
> 	
> Michael McIntosh/Watson/IBM@IBMUS
>
> cc
> 	
> Anthony Nadalin/Austin/IBM@IBMUS, wss@lists.oasis-open.org
>
> Subject
> 	
> RE: [wss] Comments on SAML Token Profile
>
> 	
>
>
> Mike,
>
> My reasons for preferring not to change include the following:
>
> 1. As mentioned earlier - this creates 2 classes of tokens, which
> will probably cause confusion and inconsistencies in processing
> approaches. Possibly an approach, such as Maneesh Sahu
> suggested, with a wss:SecurityTokenWrapper to handle all
> such cases would be appropriate, so there would only be
> one class of XML token in this regard.
>
> 2. Six and possibly seven companies have already successfully
> interoperated with the current profile, so it does not appear to
> be particularly difficult technically to implement for a token processor
> without getting involved with token schemas.
>
> 3. Both the REL and SAML profile specifications use this mechanism,
> so I think it is more of a reasonable interpretation of the core spec,
> rather than "ambiguities allowing it".
>
> However, not being an author of either the core or any of the profiles,
> and since this is the first time this situation appears to have come up,
> I think the authors who produced the descriptions of the direct reference
> URI and ValueType attributes would be a tremendous help to guide us
> as to the intentions of these attributes and whether profiles were 
> intended
> to have the type of flexibility that appears to have surfaced.
>
>  Rich Levinson
>  Netegrity
>
>  _____  
>
> From: Michael McIntosh [mailto:mikemci@us.ibm.com]
> Sent: Thu 6/24/2004 8:18 PM
> To: Levinson, Richard
> Cc: Anthony Nadalin; wss@lists.oasis-open.org
> Subject: RE: [wss] Comments on SAML Token Profile
>
>
>
> Richard,
>
> The core obviously should be more clear in this area. The point I am
> trying to make is that, regardless of any ambiguities present in the core,
> references to local tokens by URI should not require token specific schema
> processing.
>
> I do not understand the resistence to this simple change. It does not
> require any changes to SAML, the only impact is on the WSS: SAML Token
> Profile. I think the benefits or token schema independent dereferencing
> far outweigh any negative impact of the addition of an outer token
> element.
>
> Can you please explain your reason for not wanting to make this change?
> Please don't say just because ambiguities in the core allow it.
>
> Thanks,
> Mike
>
> "Levinson, Richard" <rlevinson@netegrity.com> wrote on 06/24/2004 08:00:11
> PM:
>
> > It appears to me that the WS-Security core spec is loose
> > enough to accept both your interpretation and the interpretation
> > that is in the SAML Token Profile spec. Lines 305-308 show
> > the use of a "custom token" where the particular token
> > has a wsu:ID that is referenced by the STR that has only
> > a URI attribute.
> >
> > I think it is reasonable to consider a SAML Assertion to
> > be a "custom token" in this sense, with the exception that
> > the SAML Assertion does not allow the wsu:Id attribute.
> >
> > As such, the SAML Token profile has chosen to take advantage
> > of the ValueType attribute which states "... specifications
> > for individual token types MAY define specific processing
> > rules and semantics around the value of the URI and how it
> > SHALL be interpreted.". (lines 705-707)
> >
> > It would seem reasonable to me that when a recipient encounters
> > a token with a particular ValueType that the recipient would
> > know whether or not it contains the facilities for processing
> > such a token. In the case of the SAML Assertion, the processing
> > facility would seem to be little more than applying the same
> > technique used to establish wsu:Id as an ID type attribute, i.e.
> > to establish the AssertionID as an ID type attribute, as well,
> > when dereferencing the URI with the SAML ValueType.
> >
> > If we were to take the "strict interpretation" then XML tokens
> > would be divided into two classes: those that allow wsu:Id attr
> > and can be peers of other tokens in the Security header and
> > those that don't, which would have to reside one level lower.
> >
> > Possibly, the authors of the clauses that we are citing could
> > weigh in and help us resolve the interpretations.
> >
> >    Rich Levinson
> >    Netegrity
> >
> >
> >
> > -----Original Message-----
> > From: Michael McIntosh [mailto:mikemci@us.ibm.com
> <mailto:mikemci@us.ibm.com> ]
> > Sent: Thursday, June 24, 2004 5:59 PM
> > To: Levinson, Richard
> > Cc: Anthony Nadalin; wss@lists.oasis-open.org
> > Subject: RE: [wss] Comments on SAML Token Profile
> >
> > "Levinson, Richard" <rlevinson@netegrity.com> wrote on 06/22/2004
> 09:44:43
> > AM:
> >
> > > I have reviewed this comment and I think it may be an overly
> > > restrictive interpretation of the intended usage of the URI attribute
> > > described in
> > the
> > > WS-Security core spec, section 7.2, lines 699-701.
> >
> > The lines you reference state that "... If a fragment is specified, then
> it
> > indicates the local ID of the token being referenced."
> >
> > I think you also must look at Section 4 (lines 363-374) which state
> "There
> > are many motivations for referencing other message elements such as
> > signature references or correlating signatures to security tokens. For
> this
> > reason, this specification defines the wsu:Id attribute so that
> recipients
> > need not understand the full schema of the message for processing of the
> > security elements. That is, they need only "know" that the wsu:Id
> attribute
> > represents a schema type of ID which is used to reference elements.
> However,
> > because some key schemas used by this specification don't allow
> attribute
> > extensibility (namely XML Signature and XML Encryption), this
> specification
> > also allows use of their local ID attributes in addition to the wsu:Id
> > attribute. As a consequence, when trying to locate an element referenced
> in
> > a signature, the following attributes are considered:
> > ? Local ID attributes on XML Signature elements ? Local ID attributes on
> XML
> > Encryption elements ? Global wsu:Id attributes (described below) on
> > elements"
> >
> > I think this make it clear that the intent is to require wsu:Id for ID
> type
> > attributes (other than those defined in XML Signature and XML
> > Encryption) because doing otherwise would require the WSS processing to
> have
> > access to and process the schema for every part of every message.
> >
> > Please explain why the SAML token profile could not add an outer element
> > containing a wsu:Id element?
> >
> > >
> >
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-securit
> <http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-securi
> t>
> > y-1.0.pdf
> > >
> > > In particular, the ValueType attribute (lines 702-708) appears to be
> > intended
> > > to provide token-specific processing rules to be applied in
> > > conjunction
> > with
> > > the URI attribute. In the case of SAML 1.1 assertions, the SAML
> > ValueType
> > > indicates that the saml:AssertionID should be treated as an XML ID
> > > type attribute. As described in section 4.2 lines 418-425, this may be
>
> > > done without requiring XML schema validation.
> > >
> > > I have also looked at the REL Token Profile specification that has
> > > been approved by the TC and this appears to suggest using this same
> > > mechanism with direct references in Table 2 (section 3.4 line 150) and
>
> > > shows this
> > mechanism
> > > used in the example in section 3.5.1 lines 308-309, 336-342,  and
> > > again
> > in
> > > the example in section 3.6.1 lines 404-405, 423-425 (although the
> > ValueType
> > > appears to have been left out in this 2nd example).
> >
> > The REL Token Profile makes it clear that where a Local Direct Reference
> is
> > used, that it be done using s reference to the wsu:Id attribute. The
> other
> > forms of reference are for external references.
> >
> > >
> > >
> >
> http://www.oasis-open.org/apps/org/workgroup/wss/download.php/7347/oasis-___
> <http://www.oasis-open.org/apps/org/workgroup/wss/download.php/7347/oasis-__
> _>
> > _-wss-
> > > REL-token-profile-1.0-draft08-clean.pdf ,
> > >
> > > From my reading of these documents plus the use of the STR mechanism
> > > in scenario 3 of the SAML Interop, which is compliant with the
> > recommended
> > > usage in the SAML Token Profile (Section 3.3.1 lines 318-319, lines
> > 326-331)
> > >
> > >
> >
> http://www.oasis-open.org/apps/org/workgroup/wss/download.php/6877/WSS-SAML-
> <http://www.oasis-open.org/apps/org/workgroup/wss/download.php/6877/WSS-SAML
> ->
> > 11.pdf
> > >
> > > it appears that both the SAML and REL authors and interop participants
> > have
> > > interpreted the usage of ValueType and URI in the STR element to allow
> > for the
> > > token (license or assertion) having its own ID-type attribute.
> > >
> > >     Rich Levinson
> > >     Netegrity
> > >
> > >
> > > From: Anthony Nadalin [mailto:drsecure@us.ibm.com
> <mailto:drsecure@us.ibm.com> ]
> > > Sent: Monday, June 21, 2004 2:39 PM
> > > To: wss@lists.oasis-open.org
> > > Subject: [wss] Comments on SAML Token Profile
> >
> > > We ran into some inconsistencies while participating in the recent
> > > SAML
> > interop.
> > > The WSS core specification describes a "Direct Reference" mechanism to
> > be used with
> > > STRs. A Reference element with a URI attribute is used. When the
> > referenced token
> > > is located within the Security header, the URI contains a shorthand
> > XPointer
> > > reference to the token. In order for this to work, the token element
> > must contain
> > > an attribute of type ID. WSS defines the wsu:Id attribute with type ID
> > for naming
> > > the reference. Direct references within the message should not require
> > token
> > > specific methods so we suggest the following actions be taken:
> > >
> > > 1) Errata to the WSS core to make it clear the tokens must have an
> > attribute named wsu:Id.
> > > 2) Change to the SAML Token Profile to use an wsu:Id attribute or use
> > > a
> > wsse:KeyIdentifier
> > >
> > > Anthony Nadalin | work 512.838.0085 | cell 512.289.4122
> >
> >
> > 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
> <http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup.ph
> p> .
> >
>
>
>
>