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

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


>> >>[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
>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
>domain and SAML is only required to add on to this the means of
>across security (and technology) domains.

I guess the phrasing here seems harsh.  A domain which is going to serve as
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 --
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
identity state management "thingie" and figures out who the user is.  It
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
the SAML assertion, it consumes it JUST AS IF IT WERE A NATIVE
ACTION and sticks an entry of some sort in its own
scheme (because of its trust relationship -- established out-of-band with
to SAML) indicating who the user is.  The next time the user visits a
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
>SAML specify the entire solution without any such preconditions.

I'm not sure I remember this discussion, but I *CERTAINLY DON'T* want to
to implement an entire parallel identity-state-management scheme within my
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 Blakley (email: blakley@us.tivoli.com   phone: +1 512 436 1564)
Chief Scientist, Security and Privacy, Tivoli Systems, Inc.

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

Powered by eList eXpress LLC