RE: [security-services] SSO Profile confusion

["Scott Cantor" <cantor.2@osu.edu>]

> According to the wording in section 2.4.1 of Core (see bottom 
> of mail), it sounds like only one <SubjectConfirmation> needs 
> to be verified.  But the wording above makes it sound like 
> all <SubjectConfirmation> elements need to be verified, with 
> a Method attribute of bearer.  

I see what you mean. I think the wording in 4.1.4.3 is indeed wrong, the use
of "any" is too broad. It's very hard to actually say what is meant.

> Basically the same as the previous question but with respect 
> to NotOnOrAfter.

I think to be consistent with core, if you have multiple bearer methods
present, you have to isolate on each one and repeat the rules until you find
one that passes. And of course, since some of the rules have MUSTs around
the attributes that have to be present, if you had a bearer method that
didn't include some of those attributes, it's considered to have failed for
the purposes of this profile.

> Also, what if there are multiple assertions, one of which 
> fulfils the criteria from 4.1.4.2 but another one, perhaps an 
> assertion containing only attribute statements, that does not 
> have any <SubjectConfirmation> elements?

Welcome to my world. What did y'all do in SAML 1.1? From my recent
experience, the answer is "break".

I personally like the interpretation that if you send multiple assertions,
they all ought to be independently confirmable via this profile, whether
they've got authn statements or not.

> What if it had a 
> <SubjectConfirmation> with a Method attribute other than 
> bearer?  What if it had a <SubjectConfirmation> that couldn't 
> be verified?

Clearly you could find other confirmations in them. They just get ignored.
But no confirmy, no letty inny.

> Here the wording is "the bearer <SubjectConfirmationData>" 
> where in the previous two sections it is "any bearer 
> <SubjectConfirmationData>."  Is there a mistake here or is 
> there a reason for this subtle change in wording?

See above.

> Does the "SHOULD" wording here mean that my previous 
> questions are really moot and I can do whatever I feel like 
> or personally think is most appropriate (except for the MUSTs)?

Yep. I've noted before that the TC did not accept a model in which relying
parties were *forced* to do anything. It's a liability model. If you don't
follow the MUSTs, then you SHOULD NOT rely on it. If you do, that's up to
you.

> 4.1.4.5 POST-Specific Processing Rules
> 
> I understand that the intent of this is to prevent replay of 
> assertions used to SSO when the POST binding is used.   But 
> what exactly is a 'bearer assertion'?

An assertion containing a confirmation element with a bearer method. In this
profile, additional attributes are also required, but as a matter of
definition, that's about all it means.

> Is a bearer assertion any assertion that has an 
> <AuthnStatement> and a <Subject> element with at least one 
> <SubjectConfirmation> element containing a Method of 
> "urn:oasis:names:tc:SAML:2.0:cm:bearer" that contains a 
> <SubjectConfirmationData> element that contains a Recipient 
> attribute containing the service provider's assertion 
> consumer service URL and a valid NotOnOrAfter attribute but 
> that does not contain a NotBefore attribute and also has an 
> InResponseTo attribute corresponding to the ID of the 
> <AuthnReqest>, if there was a request, but no InResponseTo 
> attribute if the <Response> was unsolicited?

Technically, yeah. I think that wording is naturally sub-optimal, so "bearer
assertion" was used.

> Is a bearer 
> assertion any assertion that conforms to these restrictions 
> or must it also have been specifically relied upon to create 
> a security context for the principal?  Or is a bearer 
> assertion any assertion that has a <SubjectConfirmation> 
> element containing a Method of 
> "urn:oasis:names:tc:SAML:2.0:cm:bearer"?  I'm sure there are 
> many other permutations that might be considered reasonable 
> interpretations here but one way or the other it's not clear to me.

I don't see why it matters, since this is just adding an additional
requirement saying that any assertions you're confirming in this profile
should be replay-checked. Whether assertions that don't fit the profile are
also bearer assertions isn't really relevant. But I think the set of "bearer
assertions" in the world is a superset of those that follow this profile.

Save for a stray "any", I think the biggest concerns I have are with:

- clarifying how additional assertions should look (noting that I did a
revamp of the schema precisely to allow attributes to be more effectively
carried in the single assertion anyway)

- clarifying whether additional assertions from other issuers should be
expected/permitted

- clarifying what in the heck a second authentication statement is supposed
to mean, or even better ruling it out like I originally wanted to do

-- Scott