Re: Does SAML browser binding assume existing SSO infrastructure? wasRE: one time use saml artifact

[George Robert Blakley III <blakley@us.tivoli.com>]

Hal,

>> >>[Hal]
>> >>I am still not sure I understand the proposed protocol. Is it
>> >>described in a
>> >>posted message? For example, what happens when the browser
>> >>goes to a second
>> >>site? Presumably they are redirected to the AP, but how does
>> >>the AP know
>> >>they are the "same" subject and not force them to
>> >>re-Authenticate?
>>
>> [Prateek]
>> The assumption is that the AP has some form of security engine
>> in place that can track its own authenticated users. Typically,
>> this takes place thru a session which is represented in some
>> form in an encrypted cookie and some additional state
>> information at the AP. Certainly, this is a strong assumption
>> but one which does seem to be met by a large class of security
>> systems.
>>
>> When the user returns to the AP, the AP examines the security
>> context of the user and determines if the user session is still
>> valid.
>>
>> Some of these issues were discussed in the bindings con-call and
>> in the minutes I issued
>>
http://lists.oasis-open.org/archives/security-bindings/200107/bin00000.bin
>
>OK, I see so you model is that there are a bunch of independant secuity
>domains which have their own proprietary methods for doing SSO within
their
>domain and SAML is only required to add on to this the means of
cooperating
>across security (and technology) domains.

I guess the phrasing here seems harsh.  A domain which is going to serve as
the
source of SSO "to" another domain needs to know who the user is.  In order
to know
this it needs to have some sort of identity-state-management scheme --
encrypted
cookie, entry in SSL session table at the server, magic pixie dust,
kerberos ticket,
etc....; it doesn't really matter.

When it comes time to cross the domain boundary, the source domain looks in
its
identity state management "thingie" and figures out who the user is.  It
then
generates a SAML assertion which tells the target domain who the user is.
The target domain also has an identity state management scheme.  When it
receives
the SAML assertion, it consumes it JUST AS IF IT WERE A NATIVE
AUTHENTICATION
ACTION and sticks an entry of some sort in its own
identity-state-management
scheme (because of its trust relationship -- established out-of-band with
respect
to SAML) indicating who the user is.  The next time the user visits a
destination
in the target domain, he (she) has the necessary state to have an identity
--
whether it's an encrypted cookie, entry in.......

>Personally I have no problem with this approach, as our product like yours
>currently has these mechanisms, but in past, others have expressed an
>intention to use SAML as the entire infrastructure. This would require
that
>SAML specify the entire solution without any such preconditions.

I'm not sure I remember this discussion, but I *CERTAINLY DON'T* want to
have
to implement an entire parallel identity-state-management scheme within my
own
domains in order to implement cross-domain SSO via SAML.

>I recall Irving Reid, for one, expressing this view. Perhaps this
assumption in your
>approach should be raised more explicitly to TC as a whole.


--bob

Bob Blakley (email: blakley@us.tivoli.com   phone: +1 512 436 1564)
Chief Scientist, Security and Privacy, Tivoli Systems, Inc.