Title: RE: [security-services] SSO Profile confusion
As Scott and I noted, there is some inconsistency
between Core and Profiles about that. Scott is suggesting (and I agree) that
Core is correct and that Profiles needs to be fixed.
From: Thomas
Wisniewski [mailto:]
Sent: Thursday, July 28, 2005
11:43 AM
To: Scott Cantor; Brian Campbell
Cc: SAML
Subject: 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
>
