You might have read Hubert's recent blog entry on the Federation Boot Camp - an intensive week-long course covering advanced Federation Manager topics. Hubert has more news on the Boot Camp today - hop on over there for the course description, and email for more information.
Somehow, this passed me by back in March/April, but a presentation at Sun's Customer Engineering Conference last month brought it back into focus - Italy's Ministry of Transportation has deployed a new Motorist Portal, providing services such as online payment of vehicle registration fees and traffic tickets.
What's interesting here is that drivers log in to the Motorist Portal to view their driving record, vehicle registration etc, but make payments via another government agency, Poste Italiane. The Motorist Portal acts as a SAML identity provider, with Sun Java System Access Manager authenticating users and providing single sign-on to Poste Italiene's service provider for 40 million Italian drivers - possibly one of the biggest live SAML deployments in the world.
I just finished reading The Truth About Federated Identity Management by Sarah D. Scalet at CSO. It's a good read, focussing on the importance of the business case in deploying federated identity and the fact that 80% of the work in any federation deployment is on the business side. The technology, by comparison, pretty much "just works". Make sure you hit the sidebar too: Thinking of Doing Federated Identity Management?.
James McGovern asks
when was the last time he [Pat Patterson of Sun] asked members of Project Liberty to start sharing pain points outside of the Project Liberty forum for others to consume and learn from?
Well - that's precisely what many members of Project Liberty recently did in the recent Identity Open Space in Vancouver. As its name suggests, this event was open to all-comers and jointly produced by the Liberty Alliance Project and some of the leading participants in the Internet Identity Workshop. We had some fascinating discussions, mostly documented (to greater or lesser extent) in the wiki.
Another interesting aspect of this event was that (as I blogged previously) IOS attendees were able to also attend Liberty's plenary sessions (under NDA), observing and even contributing to the discussion. My understanding (and no warranty, express or implied, is attached to this statement) is that the Liberty folks were very happy with the way this all turned out and keen to repeat it regularly in the future.
In the meantime, there will be another IOS next month in Santa Clara. Although this IOS is in association with the Digital ID World Conference, I wouldn't be surprised to see many of the Liberty folks there.
See you there, James?
Pat Patterson, what would it take for you to get Liberty Alliance to embrace the WS-Federation specification? Having federation capabilities built directly into an operating system is liberating...
I'm not sure what James means, exactly, by 'embrace', but here is an answer to a more precise question - could you mix-and-match WS-Federation with the Liberty Alliance Project's Identity Web Services Framework (ID-WSF)?
ID-WSF is independent of the actual SSO mechanism - the dependency is on the token, or, more precisely, the token carrying specific information. ID-WSF 1.1 can use SAML 1.1 tokens, ID-WSF 2.0 will be able to use both SAML 2.0 and SAML 1.1 tokens.
WS-Federation's USP is that it abstracts the token away from the SSO mechanism - a WS-Federation SSO can carry any token you like - SAML 1.1, SAML 2.0, Kerberos, whatever.
So, you can bootstrap from WS-Federation to ID-WSF if you obtain a suitable SAML token via WS-Fed SSO. Section 4 of the draft ID-WSF 2.0 Discovery Service specification defines SAML 2.0 and SAML 1.x Attributes that carry the Discovery Service endpoint reference (EPR). For example, here is a SAML 2.0
<AttributeStatement> containing a Discovery Service EPR:
<AttributeStatement xmlns="urn:oasis:names:tc:SAML:2.0:assertion"> <Attribute Name="urn:liberty:disco:2005-11:DiscoveryEPR" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <AttributeValue> <wsa:EndpointReference> <wsa:Address>https://example.com/disco/</wsa:Address> <wsa:Metadata> <Abstract> The Principal’s Discovery Service Resource </Abstract> <ServiceType>urn:liberty:disco:2005-11</ServiceType> <ProviderID>http://example.com/</ProviderID> <SecurityContext> <SecurityMechID>urn:liberty:security:2005-02:TLS:bearer</SecurityMechID> <sec:Token ref="..." usage="urn:liberty:security:tokenusage:2005-11:SecurityToken" /> </SecurityContext> </wsa:Metadata> </wsa:EndpointReference> </AttributeValue> </Attribute> </AttributeStatement>
There are some minor syntactic differences in the SAML 1.x version:
<AttributeStatement xmlns="urn:oasis:names:tc:SAML:1.0:assertion"> <Subject> <NameIdentifier Format="urn:liberty:iff:nameid:federated"> d0CQF8elJTDLmzE0 </NameIdentifier> </Subject> <Attribute AttributeName="DiscoveryEPR" AttributeNamespace="urn:liberty:disco:2005-11"> <AttributeValue> <wsa:EndpointReference> <wsa:Address>https://example.com/disco/</wsa:Address> <wsa:Metadata> <Abstract> The Principal’s Discovery Service Resource </Abstract> <ServiceType>urn:liberty:disco:2005-11</ServiceType> <ProviderID>http://example.com/</ProviderID> <SecurityContext> <SecurityMechID>urn:liberty:security:2005-02:TLS:bearer</SecurityMechID> <sec:Token ref="..." usage="urn:liberty:security:tokenusage:2005-11:SecurityToken" /> </SecurityContext> </wsa:Metadata> </wsa:EndpointReference> </AttributeValue> </Attribute> </AttributeStatement>
Such an attribute gives you everything you need to invoke the Discovery Service on behalf of a principal - its location (
https://example.com/disco/ in the examples above) and a token representing the principal - and it can be carried via WS-Federation just as easily as SAML.
It's up to vendors to make this work. If ADFS can be customized/extended to provide the above SAML attribute in a WS-Federation SSO then other vendors' products can consume it. No further specification or standardization is required, since, again, WS-Federation allows any token as its payload and ID-WSF doesn't care about the SSO mechanism as long as the token carries the Discovery Service EPR.
Which brings us round to the original question - "what would it take for you to get Liberty Alliance to embrace the WS-Federation specification". I believe this is moot, since, as I have shown, SSO is orthogonal to Liberty's current activities. SAML 2.0, WS-Federation, come one, come all.
Finally, yes, I agree - "having federation capabilities built directly into an operating system is liberating" - it would have been even more liberating had Microsoft adopted the federation standard agreed long ago by the rest of the industry and built SAML 2.0 into the operating system. However, we live in the real world and work to satisfy our customers' requirements. You will see WS-Federation support in future versions of our products - in fact, we've already done a PoC showing WS-Federation.
Session ID: TS-6673
Session Title: Federated Web Services With Mobile Devices
Mobile devices are becoming an ever more popular means of transacting business; at the same time carriers and service providers are looking to differentiate themselves from their competition and cater to the ever increasing demand to provide more services to their consumers. This session describes a means of securely providing access to web resources and web services using open standards such as OASIS SAML V2.0 and Liberty ID-WSF from a Java ME enabled mobile device.
Wireless carriers act as Identity Providers (IdPs) in business alliances known as 'Circles of Trust' (CoTs), authenticating customers and providing them secure access to a range of Service Providers (SPs). This federated model gives customers a seamless experience that is much more than the sum of its parts. For example, a wireless carrier could form a CoT with itself as IdP and SPs providing services such as email, calendar, mapping, weather, hotel reservations, travel information and ringtones. A customer authenticates at the wireless carrier - the carrier then provides secure single sign-on to each SP via signed assertions of the customer's identity.
As we move from simple single sign-on to identity web services, this federated environment forms the basis for providing a portfolio of services to the customer. For instance, the wireless carrier could host a location service enabling SPs to provide value-added services such as weather and hotel reservations based on the customer's current location.
The Liberty ID-WSF and OASIS SAML V2.0 standards provide the necessary security characteristics such as privacy, confidentiality, user consent and non-repudiation to make such interactions work in a federated environment. This session will show developers how a Java ME enabled mobile device can use JSR 172 to leverage ID-WSF and SAML V2.0 in accessing federated services and providing real value to customers.
Session Topic: JAVA ME
Session Type: Advanced How-Tos
Speaker/s & Speaker/s Company: Rajeev Angal, Sun Microsystems, Inc.; Pat Patterson, Sun Microsystems, Inc.
Date: Friday May 19 2006
Location: Moscone Center Esplanade 301
Join Rajeev and I next Friday and discover how to implement your own mobile federated web services. Or federated mobile web services. Anyway - see you next Friday.
I'm sitting here in Liberty's Technology Expert Group (TEG) wearing my I'm blogging this t-shirt. One of the TEG co-chairs actually asked if I really was blogging the meeting, given Liberty's rules on confidentiality (themselves freely available in the Liberty Membership Kit).
Well, yes, I am blogging the meeting
I can tell you that Liberty is welcoming a number of new members to their first Plenary meeting, including Fulvens (a small UK consultancy) and Credentica, with whom you may be familiar from earlier postings. We've covered a lot of ground over the past couple of days in TEG, syncing up with Liberty's Strong Auth Expert Group today for an interesting discussion on, uh, strong authentication.
Well - that's about all I can tell you for now. For more, go join Liberty and come meet with us in Vancouver in July.
Let's take this a step further. If user-centricity is really what we are after, it follows that I am my own identity provider in many circumstances, doesn't it? (Even if I let somebody else manage the server that runs the code and stores the data.) There seems to be a C2C model as well. What might the dynamics be there? That's the truly decentralized, peer-to-peer version of identity ...
Users acting either as their own Identity Providers or as direct identity consumers will present a different set of challenges of multi-protocol support for the sites with which they interact.
Assuming we are talking about widespread adoption, I think the user experience will be key here. Only a few hardy souls are going to tolerate managing several personal identity providers (PIPs). What we need is some higher level UI that might let us manage several credentials, each with their own protocol - perhaps a sort of 'metasystem' to make sense of it all?
Interesting to see the discussion over the past few days between Phil Windley and Johannes Ernst on multi-protocol identity implementation. I've been through a couple of iterations of this myself, with last year's Microsoft/Sun Web SSO specifications and the Burton Catalyst multi-protocol federation demo.
There is a complex dynamic between identity providers supporting many protocols to service a wide range of relying parties and the converse, relying parties supporting many protocols to allow users to authenticate at any one of a range of identity providers. In the B2C world, it seems likely that the role of identity provider will naturally gravitate towards the big guys - maintaining a secure identity infrastructure is expensive - scale provides natural economies. This would seem to indicate that identity providers will be able to dictate terms - "My way or the highway", but we haven't seen much evidence of that. On the contrary, identity providers seem to be the ones interested in multi-protocol support at their end - the multi-protocol identity provider hub model that we demonstrated with Access Manager at Catalyst.
The logic is that, once you have an infrastructure for storing identities and authenticating users, supporting 2, 3 or 4 protocols isn't much more difficult than supporting 1. The relying party is in a different position - their core business is the service they are providing - horoscopes, online gaming, a blogging platform, whatever. The relying party wants to pick a protocol, implement it with identity provider #1 and add identity providers over time without a bunch of extra expense and complexity.
On the other hand, in the B2B arena, the dynamics may turn out to be the reverse, as relying parties (service providers) such as 401(k) providers, health benefits providers and even political action committees implement federated SSO to allow company employees to leverage their enterprise login to access external resources. Here, the relying party may take the driving seat, implementing a range of protocols as they implement federation with a range of their customers. Enterprises are deploying federation internally first, hooking up divisions, so when a service provider offers federated SSO the identity provider is likely to have already selected a technology.
Caveat - this is a rapidly evolving market (who would have foretold the explosion in user-centric identity?) and the above is based on the observations of one guy talking to a random bunch of enterprises and organizations. I'm perfectly prepared for a bunch of incoming links over the next few weeks/months/years explaining just how wrong I was
Following on from last months entry on Liberty Adoption, the good people at the Liberty Alliance Project have published the first in a quarterly series of newsletters on the topic: Liberty Alliance Project Global Adoption Newsletter, Edition One. It's actually a pretty good read, with John Butare and Michael Hatten of Intel's Information Services and Technology Group answering questions on their company's deployment of Liberty, a case study of BIPAC's use of federation (I've written about how BIPAC use Sun's identity management products and the fact that this is Sun's first Liberty deployment previously) and a detailed look at adoption in the eGovernment (e-government? egovernment?) sector. All this and not a telco (or car rental company!) in sight