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

[George Robert Blakley III <blakley@us.tivoli.com>]

Hal,

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

I think this is sort of true by definition, as the "glue" which connects
the
SAML protocol up to the trust-evaluation mechanism of the target server and
the
trust-assertion mechanism of the source server seems to me to be
implementation-specific
& hence out of scope of our specification.  But perhaps you have another
deficiency in
mind.  I agree it's a concern.  Perhaps at the FTF we ought to talk about
how we're
all going to achieve interoperability BASED ON SAML in products.

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

I don't agree with this.  I think I can just implement glue which exports
information
from my existing mechanism to SAML and imports information from SAML into
my existing
mechanism.  Do you not think so?

--bob

Bob Blakley (email: blakley@us.tivoli.com   phone: +1 512 436 1564)
Chief Scientist, Security and Privacy, Tivoli Systems, Inc.