Re: [wss] Referencing SAML Assertions

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

Don,

This is a interesting point, especially when the assertion is not 
signed. BTW, I checked out the core
docs, and some of the other binding docs, to see if we ever show such an 
example, and I couldn't
find one.

In the case of SAML binding, it is recommended/expected (although not 
required) that assertions
containing a holder-of-key SubjectConfirmation element be signed by the 
aurthority; in which case
it would not be necessary for the message sender to sign over the 
assertion. A signature over the
msg msg content should suffice. This consideration may reflect why such 
an example does not occur
in the X509 and kerberos bindings where the security tokens (and thus 
key bindings) are
presumably also protected by signing or encryption by a trusted authority.

Although holder-of-key leaves the door open to unsigned assertions, the use
of SAML assertions with a sender vouches confirmation method clearly 
requires:

> 418 To satisfy the associated confirmation method processing of the 
> receiver, the sender
> 419 MUST use its key to integrity protect the assertions and those 
> elements of the SOAP
> 419 message that the sender is vouching for.


I will add an example to (the sender-vouches case) to show how the 
assertion is
referenced in the signature.

There are a couple of other changes that I'd like to make to the SAML 
profile.

1. The description of the holder-of-key confirmation method should be 
modified to
allow an  authority to authorize holders of other than the subject key 
to act as the
subject. This would enable an authority-vouches form of impersonation, 
whereby the
authority produces assertions that allow intermediates to act on behalf 
of the subject
of the assertion. As an additional consideration, the audience 
restriction field of the
assertion could be used to limit, at which targets, the authority has 
authorized
impersonation of the subject (by the key holders).

2. It should be possible to reference a SAML assertion by SAML artifact. 
One reason
to do this, is to obviate the need for encrypting sensitive assertion 
content when the assertion
must pass through intermediates.

Barring any objections, I would like to make these changes to the 
binding and make the
modified document available for the FTF.

Ron

Flinn, Don wrote:

>I believe that an example of how to reference a SAML assertion in the ds:SignedInfo element in the SAML Token Binding document is needed.  There is an example for using the wsse:SecurityTokenReference in the ds:KeyInfo.  This is ok with respect to the digital signature spec as the KeyInfo element has a choice of a child element "any" with lax processing.  However, the ds:SignedInfo does not have that flexibility in what is allowed so I believe that the same approach cannot be used for ds:SignedInfo with breaking the digital signature spec.  Possibly a different approach to referencing the SAML assertion is intended for the ds:SignedInfo but I can not determine this from the writeup.  One reason that one would want to do this is to sign both the SAML assertion and the SOAP body, thus tying the SAML assertion to the SOAP body. 
> 
>Don
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
>  
>