Superpatterns

Pat Patterson on Identity Management, Federation and Single Malt Scotch

accessmanager adfs authentication authorization bloggers blogwatch burtongroup cardspace catalyst donbowen extensions fam federation federationmanager fisl identity idwsf infocard java javapolis libertyalliance lightbulb links microsoft opends openid opensource opensso php planetidentity podcast roller saml sdn sso sun tokyo ubuntu video webservices wsfederation

« Sun and Microsoft... | Main | Federated Authorizat... »

05 Dec · Tue 2006

YADIS/XRI Identifier Resolution with SAML 2.0
[ demo iiw2006b lightbulb openid opensso php saml xri yadis ]

This week at Internet Identity Workshop 2006b I've been demonstrating some work I've been doing to combine YADIS/XRI Identifier Resolution (as in OpenID) with SAML 2.0 Web Browser SSO Profile. The user experience is:

I go to a service provider (relying party)
I enter my identifier (URL or i-name)
I authenticate at my identity provider
I can access services at the service provider

The magic takes place between steps 2 and 3: the service provider resolves the user's identifier, which might be a URL or an i-name, to the location of a SAML 2.0 identity provider. The service provider can now do vanilla SAML 2.0 with the identity provider. The easiest way to see what's going on is via a demo, so, here you go:

Click to view Flash presentation

By the way - the service provider is implemented on top of Project Lightbulb. I need to do some tidying first, but I'll put the YADIS/XRI code there soon.

UPDATE - coverage of this demo at IIW2006b:

Lightbulb: Bringing SAML to PHP
Internet Identity Workshop demonstrations steal the show - nice pic on this one. Left-to-right we have Doc Searls, my good self, Shin Adachi and JP Rangaswami.

@ 04:16 PM PST Comments [4]

Trackback URL: http://blogs.sun.com/superpat/entry/yadis%2Fxri_identifier_resolution_with_saml

Comments:

Does Federated Identity sometimes require Federated Authorization? If so, how come this isn't ever discussed. Maybe you could address in future blog entry...

Posted by James on December 07, 2006 at 06:21 AM PST #

Following the proposed model the service provider (relying party) needs to collect every possible identity provider set of metadatas, which takes us again to the Liberty model. How can a relying party afford to allow the whole set of identity providers?

Posted by Chema on January 15, 2007 at 02:39 AM PST #

Hi Chema, the service provider/relying party does indeed need to fetch metadata for each identity provider (just as an OpenID relying party needs to dereference the user's URL or i-name for each login), but it need not keep it persistently - the metadata can just be discarded at the end of the login. The service provider can choose to allow all identity providers or only a given set, just as in 'classic' OpenID.

Posted by Pat on January 15, 2007 at 09:45 AM PST #

Very nice video.
It would help for people who are a little more new to this though if you added slides in between the messages showing the routing of the messages. You could have a slide of the main actors (the user agent, the web site one is looking for authentication from, the authenticator,...) and have a glowing arrow show the direction of the message. Something like that would help get an overview of what is happening.

Posted by Henry Story on March 01, 2007 at 01:04 AM PST #

Name:
E-Mail:
URL:
	Notify me by email of new comments
	Remember Information?