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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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


Subject: Re: [security-services] SSO Profile confusion


Brian Campbell wrote:
> 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. 

Subject confirmation is how you verify the right of an attesting entity 
to use an assertion within an application. In SSO, the right is 
established by "bearing" it, and by satisfying restrictions contained in 
the other attributes inside the confirmation element.

What's meant is that somewhere inside the assertion, a bearer 
confirmation exists that the bearer can satisfy. Any other 
confirmations, bearer or otherwise, are to be ignored once you satisfy one.

What's vague is what to do when multiple assertions exist.

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

If you don't allow more than one, an assertion will pretty much never be 
forwardable and the use cases pretty much dwindle to hop to hop.

A simple use case: Put a holder of key confirmation inside a SSO 
assertion containing the key and NameID of the SP. You've just created a 
token the SP can use to impersonate the principal at some web service.

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

There weren't any specific requirements that I ever understood. It 
seemed to be vague to me. There were no rules about what could appear, 
and no rules about whether additional assertions looked a certain way. 
Same as now.

You had to have an AuthenticationStatement with a Bearer or Artifact 
confirmation, but beyond that, no rules.

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

We did. I thought it was silly to package up attributes in an assertion 
that was about to expire. I also assumed that was the reason for 
allowing multiple assertions in the first place, otherwise it doesn't 
make much sense to bother allowing it.

> 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 agree. I tried to change that model, but was told not to. ;-)

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

Yeah, I think that is the only way to read core and profiles together.

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

Yep, it is, IMHO. But I think that wording would have just confused 
readers more than using the term "bearer assertion" does. I'd rather 
leave it at "an assertion containing at least one bearer method that 
conforms to this profile".

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

I agree. We also intend to move to a single assertion now that we can 
expire the assertion how we want to.

-- Scott


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