SSO between a SAML SP and an OpenID RP
From Project Concordia
Contents |
Use case description
Alice visits her favorite pizza site to order a pizza. The pizza site requires Alice to sign in which Alice does via her SAML identity provider. Now that the pizza is on its way, Alice goes to update her pictures at zooomr.com. Alice is SSO'd into Zooomr based on her previous SAML authentication.
Workflows
Additional information and related work
George post - Identity Meta-System SSO
Peter Williams' post on the OpenID general list about multi-protocol brokering, e.g. when receiving an OpenID authentication request that you want to handle as a SAML web SSO authentication request. The email thread touched on two aspects that may be relevant for further standardization (vs. handling this automatically in APIs):
- A standard mapping from one type of request to the other
- Metadata for routing to a SAML IdP vs. an OpenID Provider as appropriate
The thread refers to the ISSO work (specs, related demo) as a possible source of further standardization.
Related events
Contacts and contributors
Questions
- DavidRecordon - Is this really a protocol interop use case or rather implementation specific to a Provider which knows how to speak both SAML and OpenID and can map between them?
- Good question. I guess we'd need to define "protocol interop" first. It seems that to make any two or more protocols interop, then something has to know about both of them. That "something" could be a gateway, or libraries at the SP or IdP or both.
- Peter Williams - An OpenID Provider being co-resident with an SAML SP site seems very analagous to LDAP listener fronting the X.500 Directory access protocol. All PRoviders are required to use "local means to" complete userauthentication, after all.The L in LDAP was lightweight, and the service defined by the DAP in LDAP was identical to the DAS defined (abstractly) in X.500. Whereas LDAP used strings, internet conventions and https for secure signaling, ISO had specified for OSI-based DAP protcols when specifying a DAS,and signed operations much like SAML does. It obviously makes not the slightest difference whether one uses strings or binary messages, tho https channels do have very different security properties to signed messages.
- Peter Williams - Is this LDAP an example one of interop, or co-residency? It was co-residency. The X.500 architecture EXPECTED products to use native (e.g. string formats) when working with proprietary clients. When the network negotiated an interworking need, then and only then did one swap to using the (lightweight or heavyweight) interworking standard, suitably profiled for different communities.
- Peter Williams - we have to beware to OpenID tryin to cliam by word changes that its invented something new. Words and conceptual presentation shifts and even lower security entry points are often valuable, however, to get better adoption in generation#2 of something. When completing a security analysis, nuveau terms must never be allowed to make the slighest difference. By focussing on web2.0 technology sets, OpenID may be able to do for SAML what LDAP did for X.500; and thats the key to why bother with co-residency. Of course, as LDAP advanced, it became just as complex as the X.500 services it "simplified", if not more so.
