Does SAML browser binding assume existing SSO infrastructure? was RE:one time use saml artifact

[Hal Lockhart <hal.lockhart@entegrity.com>]

> >>[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.

Hal