[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
