User Centric Identity + Federation Demo
Kim took the effort of recording and posting the demo that we had at Catalyst ’06. Thanks Kim. It’s been discussed by Paul Toal, Paul Squires, Paul Madsen and Craig Burton.
In case anyone is looking for details on the demo, here is the general flow:
- User shows up at the Portal.
- Authenticates using Infocard (or userid/password)
- The Infocard server/module retrieves the xmlToken, does the decryption, validation etc…and retrieves user attributes.
- The information is passed to the app server (portal) that creates a local session.
- User clicks a link to the partner SP website (Portal is now acting as the IdP).
- User information from the session is retrieved, another SAML/WS-Fed assertion is generated (partner SP has trust relationship with the Portal IdP).
- Partner SP receives the SAML assertion, does the parsing, validation etc.
- Depending on the target platform, a corresponding integration kit is invoked. e.g. in case of Salesforce, it invokes their delegated authentication API; In case of Weblogic, it invokes Ping Identity’s implementation of Weblogic SSPI. In case of Siteminder, creates CA’s proprietary SMSESSION. In case of Oblix, creates the OBSSOCookie….you get the idea.
- User is redirected to the Partner SP site…..and hopefully he is logged in.
By the way, there is an extension of this demo which isn’t shown in the video….it allows you to use the infocard information to get a SAML assertion (thru PingTrust), adds it to the WS-Security header and invokes a Web service…. (why leave the SOA world behind 
).
At the root level, this was the intention….login to a website using Infocard. Once authenticated, use that information to authenticate/SSO to other websites (which may or may not be in the same domain). But I agree…..user-centric identity meets federation does sound a lot slicker
I’m a little leery of using the words ‘user centric identity’ and ‘federation’ in the same sentence. There has been a lot of discussion on this at the identity gang list (over 400 messages). There are lots of smart and bright people over there……so I’m sure they’ll figure it out. Personally, this is my take
The identity silos (Siteminder, Oblix, Salesforce etc.) are here and will remain. However…few minor details and browser redirects aside, you can use Infocards to log into the proprietary security domains without much change to the existing infrastructure.
Needless to say this is just the tip of the iceberg. There are many more use cases e.g. Portal to external 401K (user owns the data, user in the flow is required), Portal to Salesforce (employer owns the data, user in the flow may not be required), Portal to internal HR (employer owns the data, user in the flow is required), Portal to internal bug tracking system (employer owns the data, user in the flow is not required) that imposes their own requirements for user centricity and federation to compete/co-exist.
And of course there are quite a few implementation details yet to be worked out:
- What happens if the SP changes their public key? For self-issued card, PPID is computed of SP’s public key.
- Since the user name is not unique with Infocard, how does the SP perform personalization?
- What happens if the user changes one of the claims say email address. Does the SP retrieves it every time (I imagine it would need to store a local user profile).
- Is there (should there) be a way for SP to identity it’s the same user even if the user chooses to use different IdPs.
- In the consumer space, does the SP need to establish trust with every IdP possible. (If banks become the public IdP, there are ~18,000 banks in US).
- Are we going from ‘too many passwords’ to ‘too many Infocards’?.
- What happens if the user machines crashes and has to recreate the self-issued infocards again? What happens to the existing profiles at the SP site?
- And yes, the mobility issue.
I’m sure over time, industry will figure it out. For now, I’ll focus on the next demo.
Identity, Infocard | Ashish Jain | 
August 15, 2006 8:58 pm
Subscribe
Cardspace to authenticate to an OpenID IDP, at the behest of an OpenID RP, such that the OpenID IDP is a Cardspace RP) is OpenID followed by Cardspace – a weaker form of integration (and one of course possible with any other SSO system like SAML, as hilited by Ping). As I see it, the defining characteristic of both OpenID and Cardspace is how identity persona selection occurs. In the default (but not only) OpenID sequence, the user selects which persona to present to the RP by providing the appropriate
Cardspace to authenticate to an OpenID IDP, at the behest of an OpenID RP, such that the OpenID IDP is a Cardspace RP) is OpenID followed by Cardspace – a weaker form of integration (and one of course possible with any other SSO system like SAML, as hilited by Ping). As I see it, the defining characteristic of both OpenID and Cardspace is how identity persona selection occurs. In the default (but not only) OpenID sequence, the user selects which persona to present to the RP by providing the appropriate
Last year at Catalyst: We had one Information card-enabled Relying party . And no IdP. This year at Catalyst: We had 24 Relying Parties, 6 Identity Selectors and 11 Identity Providers.
[...] Search Home | About Me | My Employer | « User Centric Identity + Federation Demo [...]
[...] Last year at Catalyst: We had one Information card-enabled Relying party . And no IdP. This year at Catalyst: We had 24 Relying Parties, 6 Identity Selectors and 11 Identity Providers. [...]