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: Does SAML browser binding assume existing SSO infrastructure? was RE: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
> 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.

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 recall
Irving Reid, for one, expressing this view. Perhaps this assumption in your
approach should be raised more explicitly to TC as a whole.


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

Powered by eList eXpress LLC