OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [saml-dev] Destination vs. Recipient and signing of Assertionvs. Response


> 1) For us to verify that the SAML message was really intended for us,
> does the IDP need to provide the Destination attribute of <Response>, or
> Recipient attribute of <SubjectConfirmationData>? Or both?

Recipient inside the assertion is a MUST, as is the Audience. Destination is 
a binding issue. If you sign the message, the binding as specified requires 
the attribute. If not, it doesn't matter if you include it because it can't 
be trusted anyway. And yes, it's duplicative, that's why Recipient exists. 
But not every message carries an assertion.

>    SubjectConfirmation and SubjectConfirmationData are described in the
> SAML core spec (2.4.1.1 and 2.4.1.2) as elements which are used by a
> "relying party" to verify the relationship between the Subject and the
> "asserting party". SubjectConfirmation doesn't seem to have anything to
> do with who should act on the entire Assertion (its scope seems smaller
> than the Assertion).

SubjectConfirmation has everything to do with who should act on an 
assertion. No confirmation, no act. You toss it. There's probably no element 
in SAML that's as important, or is understood less. It's what binds the 
assertion to a security technology. SAML alone doesn't really act as a 
security token format, it's a normalization around some other token that is 
specified in that element. In the case of Bearer, it's a "null" token, in a 
sense because there is no security beyond possession.

>    Yet, the Response processing rules under Web SSO Profile (SAML
> Profiles 4.1.4.2) do imply that SubjectConfirmationData's Recipient
> should be used as an overall check by the "relying party" that it was
> really intended for them.

Yes, and it's mandatory to include it. All of the security, such as it is, 
comes from that element. How it's protected (i.e. signed) is a different 
question. It can be done several different ways (signed assertion, signed 
response, simple-sign binding).

> 2) The answer to the above affects what portion of the SAML message
> should be signed -- i.e. if we are relying on the Destination attribute
> then the entire <Response> should be signed, correct?

Yes, but you can sign the assertion alone, and barring a good reason, that's 
normally what you want to do. One reason for signing the Response is that 
you can get away with a vanilla signature URI of "" to indicate the whole 
message, which is one way of avoiding some of the nastier aspects of XML 
Signature.

> 3) Also the Security Consideration doc section 6.4.2 (HTTP POST Binding

SecCons has stale information left over from 1.1 and is not worded 
consistently. That section is basically errata, I'd say.

> I can't find anything that says "when using HTTP POST binding the
> *entire* SAML message must be integrity-protected".

And you never will because that's a profile question, not a binding 
question. I believe that the SSO profile says explicitly that you can sign 
either layer, but I don't have it in front of me right this second.

HTH,
-- Scott


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]