RE: [security-services] SSO Profile confusion

["Brian Campbell" <bcampbell@pingidentity.com>]

Sorry to be so slow to respond to this.  No real excuse other than just
being busy with the other demands of work...  some comments/thoughts
inline below.

> -----Original Message-----
> From: Scott Cantor [mailto:cantor.2@osu.edu]
> Sent: Friday, July 15, 2005 11:53 AM
> To: Brian Campbell; 'SAML'
> Subject: RE: [security-services] SSO Profile confusion
> 
> > 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.

[Brian Campbell] 
So I guess that begs the question - what is actually meant?  I'll be
quite honest that I've never really understood the intent behind the
subject confirmation stuff. 

> > 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.

[Brian Campbell] 
That makes sense and was more or less the way that I read it but is
really only one of many reasonably interpretations.   What was the
reason for allowing an arbitrary number of subject confirmations?  Like
I said before, I just don't get it.

> > 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".

[Brian Campbell] 
I don't remember exactly.  There were specific requirements as to what
constituted an "SSO Assertion" and we validate that one of those is
present.  If I remember correctly, we were a little less strict with
assertions that weren't being relied on to create the session for the
principal.  

Practically, however, I'm not sure it really matters because I've yet to
see an AP/IDP implementation that doles out multiple assertions in a
single response. 

The model seems to always be that you can have 0..n assertions and each
assertion can have 0..n confirmation methods.  But for SSO you must have
at least one particular kind of assertion with at least one particular
kind of confirmation.  Validation of this model is a little tricky and
reporting back the results of the validation in a meaningful way is
extremely difficult.     


> 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.

[Brian Campbell] 
I tend to agree with that I think.
 
> > 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.

[Brian Campbell] 
I love the technical terms :)  But what you're saying is that they must
be one confirmable (is that even a word?) confirmation that conforms to
the SSO profile requirements?  And the rest can be ignored?  

> > 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.

[Brian Campbell] 
I must have missed that - thx for the clarification.

> > 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.

[Brian Campbell] 
I see.  I guess my feeling is that in a normative spec, the technically
correct wording should be used even when it's sub-optimal.  My intuition
also tells me that perhaps when the wording is sub-optimal to that
extend - that maybe something is more complicated than it needs to be.

> > 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. 

[Brian Campbell] 
Fair enough but I guess I'm still not sure what assertions I should be
confirming.   And, for that matter, what confirming is really all about
but maybe that's my own misunderstanding. 

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

[Brian Campbell] 
It would be nice to clarify the stray 'any'(s) I think.
 
> - 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)

[Brian Campbell] 
The schema revamp was a huge improvement I think.  And my IDP will only
be sending one assertion.  But the schema and the spec still allow for
multiple assertions so some clarification about what an SP can/should
expect and how it should deal with it would be very helpful. 

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

[Brian Campbell] 
That would be good :)

> - 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

I'd vote for ruling it out.  I don't see what allowing it gets you other
than just complicating matters.