Jaime has also posted a detailed presentation on Sun’s federated identity management products – Access Manager, Federation Manager and OpenSSO.
Cool eye candy for Suse 10.1
Covers both SUSE 10.0 and 10.0
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.
Links to commonly referenced information in the Sun Java System Access Manager 7 2005Q4 documentation collection.
Eric is Product Line Manager for Federated Identity Management here at Sun, which kind of sounds like a tongue twister, but it is his real job, honest. Eric takes the customer requirements, engineering’s hare-brained schemes, the specifications and standards appearing from various august (or not) bodies and, somehow, magically, orchestrates the production of Access Manager, Federation Manager and OpenSSO.
Yup – Eric is just about the busiest guy I know. Go read his thoughts, and leave lots of comments. Eric really needs the notification email to fill out his inbox. Honest
Now, this is interesting. In talking about the benefits of single sign-on, we often make the assertion that security is reduced as users have to remember more passwords. In the past, this statement was largely based on anecdotal evidence, but now we can point to the DTI Information Security Breaches Survey 2006, conducted by PricewaterhouseCoopers for the U.K. Department of Trade and Industry (as reported by Reuters via CNet News). The full report is interesting reading; there is also an executive summary and a set of factsheets, one of which focuses on Identity and Access Management.
To quote the survey:
The more IDs and passwords users have to remember, the more likely the business is to have had unauthorised access.
So – the corollary is, as we reduce the number of IDs and passwords users have to remember, the less likely the business is to have had unauthorized access. Hence the security benefit of single sign-on (SSO).
My colleagues over in marketing (Hi Julie!) have done a great job reworking our Identity ‘landing area’ – http://www.sun.com/identity. There’s a bunch of new stuff there; my favourite is the ‘What is Federation?‘ Flash preso in the Resources section – a slightly sideways look at what we mean when we say ‘federation’. Highly recommended, even if you (think you) already know federation inside out.
Another great resource is the Sun Identity Insights Program – sign up to get a regular newsletter “highlighting market trends and news, industry reports, case studies and upcoming Sun Identity Management events”, receive exclusive invitations to Sun Identity Management Net Talk events and discussions and much more. Here’s a link to the newsletter archive, so go take a look and, if you like what you see, sign up!
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