Superpatterns Pat Patterson on the Cloud, Identity and Single Malt Scotch

7Nov/060

Federation Boot Camp

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.

Filed under: Federation No Comments
16Oct/060

Federation – Italian Style

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.

You can find out more in this short SunTV presentation and the Italian press release (English translation via Google).

Filed under: Federation No Comments
11Oct/060

CSO Article – The Truth About Federated Identity Management

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?.

Filed under: Federation No Comments
14Aug/063

Nice To Be Considered an ‘Industry Expert’ on Federated Identity…

...even if it's qualified by 'so-called' and my cluefulness is called into question :-)

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?

Filed under: Federation 3 Comments
20Jun/062

Liberty and WS-Federation

James McGovern directed this question to me in a recent blog entry:

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)?

Well, Liberty got out of the SSO business some time ago, contributing ID-FF to OASIS for inclusion in SAML 2.0. Liberty's technical focus is now on Web services, strong authentication and such.

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.

Filed under: Federation 2 Comments
10May/060

JavaOne 2006 San Francisco – TS-6673 – Federated Web Services With Mobile Devices

Rajeev Angal and I will be presenting 'Federated Web Services With Mobile Devices' next week at JavaOne 2006 in San Francisco. Here's the blurb from the session catalog at the JavaOne website:

Session ID: TS-6673

Session Title: Federated Web Services With Mobile Devices

Session Abstract: JSR 172, the Java™ Platform, Micro Edition (Java ME) Web Services Specification, is a key Java ME specification that defines APIs enabling mobile devices to invoke web services.

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

Time: 2:30pm

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.

Filed under: Federation No Comments
26Apr/060

Blogging Live from the Liberty Plenary Meeting, Washington, DC

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.

Filed under: Federation No Comments
19Apr/060

Multi-protocol User-centric Identity

Johannes Ernst replies to yesterday's post on Multi-protocol Identity Implementations:

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 ...

Paul Madsen makes a similar point, commenting

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?

Err...

Filed under: Federation No Comments
18Apr/061

Multi-protocol Identity Implementations

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

Filed under: Federation 1 Comment
18Apr/060

Project Liberty Adoption Newsletter #1

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

Filed under: Federation No Comments