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