[wss] Action: related to issue 28 - using STR to reference SAMLassertions

[ronald monzillo <ronald.monzillo@sun.com>]

Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

> Item 28  Technical - SAML Binding: Include the use of the URI 
> attribute (on SecurityTokenReference) from the SS TC submission
> Hal Lockhart requested new discussion based on Ronald Monzillos 
> comments to the group.


In our last teleconf, I was asked to describe the issues I encountered, 
trying to
define STR forms for SAML assertions.

Issue 28 was raised (by Prateek) to indicate that a SAML assertion 
identifier
by itself (as used by verison 02 of the SAML binding) is insufficient to 
reference
a SAML assertion that is supposed to be pulled by a SOAP message recipient.

The URI of the Authority is also required.

So I took a look at the specification of STRs in Core, and tried to come up
with a reference form for this SAML use case. I attempted to document 
what I learned
about STRs in section 3.3 of the SAML binding.

> The WS-Security specification defines the 
> <wsse:SecurityTokenReference> element
> for referencing security tokens. Three forms of token references are 
> defined:

> · An element reference  a security token specific XML element that 
> contains an
> identifier and perhaps locator of a security token within the message 
> or at some
> external location.

> · A URI reference  a generic element that conveys in its attributes, 
> the security
> token URI and token type value ( i.e. ValueType) that define the 
> location and
> perhaps identifier of a security token occurring either within the 
> message or at
> some external location. A URI containing only a fragment identifier is 
> interpreted
> as identifying the corresponding security token within the message in 
> which the
> fragment identifier occurs.

> · A key identifier reference  a generic element that conveys in its 
> attributes, the
> security token identifier ( i.e. wsu:id) and token type value ( i.e. 
> ValueType) that
> identifies a security token with matching wsu:id and ValueType 
> occurring within
> a <wsse:Security> header of the message. Identifier references may 
> only be
> used to reference security tokens that carry matching attributes, which
> approximately restricts their use to Binary Security Tokens attributed 
> as a result
> of their encapsulation in XML.

I concluded that none of the above are sufficient by themselves to 
reference a security token
at a SAML authority. A URI reference comes the closest, but its use to 
carry both an assertion
identifier and authority location and identifier would likely conflict 
with SAML's use of URIs
for identifying the authority part of a reference. So I decided to 
propose that a URI reference
and a token specific element reference be combined to support this SAML 
STR use case.

>
> A URI reference containing a URL may be combined with a token specific 
> element
> reference to yield a location qualified reference.
> In The SAML binding of WS-security, a referenced SAML assertion is 
> identified by a
> <saml:AssertionIDReference> occurring either as an element reference 
> or as a
> String value fragment identifier in a URI reference. 


This all seems a bit awkward to me. It makes one wonder why we aren't 
using a
keyInfo element with an ID attribute containing the assertionID, and 
with a contained
ds:retrieval method with a URI attribute containing the authority URI, 
and with a
Type attribute identifying (by URN) the SAML binding to be used to acquire
the assertion.

KeyInfo
ID = 123456
RetrievalMethod
URI="http://www.acme.com/saml-authority";
Type= urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding

Similarly it would seem that the case of a reference to an on-message 
assertion
could be handled using a keyInfo element with an ID attribute 
(optionally) containing
the assertionID, and with a contained ds:retrieval method with a URI 
attribute containing an
assertion identifying URI fragment or an Xpath expression, and with a 
Type attribute
identifying (by URN) a SAML assertion (perhaps by assertion type if 
there are such urn's).

KeyInfo
ID = 123456
RetrievalMethod
URI=#123456
Type=urn:oasis:names:tc:SAML:1.0:assertion

I guess there could be a problem with the KeyInfo ID attribute being 
able to carry a SAML
assertion ID, although that doesn't appear to be the case.

Comments?

Ron