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

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

[Hal]
> >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.
[BobB]
> 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.

The point is that as proposed, SAML will not provide a SSO solution, merely
the means of connecting two (or more) domains that already have implemented
SSO solutions.

One can not simply take a standard Web server out of the box, add SAML and
have a pool of SSO servers, whether in a single security domain or multiple
domains. It is my impression that this is contrary to at least some people's
expectations as to the meaning of SSO as a requirement.

[...]


[Hal]
> >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.
[BobB] 
> 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.

But if you don't have one today, you WILL have to implement one, as the SAML
one will not work by itself.

Hal