Subject: RE: Does SAML browser binding assume existing SSO infrastructure? wasRE: one time use saml artifact
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: firstname.lastname@example.org phone: +1 512 436 1564) Chief Scientist, Security and Privacy, Tivoli Systems, Inc.
Powered by eList eXpress LLC