Title: RE: [security-services] SSO Profile confusion
Scott, you say once you satisify one bearer conf methods, the others can be ignored.
Can you clarify the following bullets in Profiles: 576, 578, and 580, and 584 -- which seem to contradict the above statement. They imply that one MUST verify various pieces against *any* bearer conf method (even if there is one that satisfied all requirements already)?
Thanks, Tom.
> -----Original Message-----
> From: Scott Cantor [mailto:]
> Sent: Thursday, July 28, 2005 1:07 PM
> To: Brian Campbell
> Cc: SAML
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. You may a link to this group and all
> your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
> oups.php
>
