Ben Laurie posts flame-bait this morning, with an entry titled 'Liberty Loves Silos'. I always find it amazing how folks ascribe the most sinister motivations to Liberty - maybe now that a load of our (previously private) mailing lists are publicly visible, people will see that we are really fluffy and cuddly (except Conor, of course, he's a bit prickly).
Anyway - back to the point... My understanding (I wasn't there for a lot of the early work, so I'm happy to be corrected here) is that the motivation for automated discovery was a seamless user experience. Asking the user for the location of her identity provider, discovery service, calendar service or whatever was seen as a bump in the road, rather than user empowerment. What we're seeing now is a lot of thinking around how we can combine ideas of user identifiers (URLs or i-names) with SAML 2.0 for SSO and ID-WSF 2.0 for Web services. For example, YADIS/SAML or OpenID/ID-WSF.
In any case, user privacy, consent and control has always been foremost - hence all the work on defining how a user can consent to attributes being shared between providers [PDF], not to mention security and privacy [another PDF, I'm afraid].
One big news item - the economics of Liberty participation just changed, radically: effective May 1, individuals can join Liberty Alliance as associate ($100) or sponsor ($250) members. Fees have also been reduced for enterprises and other organizations - see the new Membership Matrix (PDF) for details.
Also, the Technology Experts Group (TEG) mailing list is now publicly viewable. Paul explains some of the rationale. TEG is the powerhouse of the Liberty Alliance (no offense to Public Policy, Business and Marketing or any of the other expert groups!), turning market requirements into specifications; this move makes that mechanism completely transparent.
Looks like the trend towards openness and participation is spreading!
Thanks to Charles for this pointer (and to Dennis for pointing it out): David Goldsmith does a great job in this video explaining the problems inherent in the proliferation of online identities and how federation and Sun's product line (Sun Java System Access Manager and Sun Java System Federation Manager) address them. After working through a couple of real-world examples, David goes on to provide useful definitions of common federation buzzwords, such as 'circle of trust', 'identity provider' and 'service provider'. Well worth watching if you want to get up to speed quickly! Click here for the video.
Slides from my RSA Conference session: “SOA-401 – Federated SOA: Harmonizing ID Security and Web Services”
I just uploaded the slides from my RSA Conference presentation last week: Federated SOA: Harmonizing ID Security and Web Services.
A few words of explanation on the opening slides... Sara Gates was originally booked to present in this slot. As you almost certainly already know, Sara left Sun a little while ago, and I inherited her slot. So, my opening gimmick was to introduce myself as Sara and then say "Of course, I'm not Sara, you can see and hear that, but how could a Web service tell the difference?". It was spoilt a little on the day by the RSA Conference announcer introducing me as Pat Patterson, but I made the point that if I had tried to introduce myself as Sara...
Anyway, in the presentation, I start from the position of unprotected web service interactions, working through transport-layer security via TLS/SSL to point-to-point message-layer security to Liberty Alliance's Identity Web Service Framework (ID-WSF), pointing out the different properties of each level. The session was recorded - I'm not sure if the recording will be publicly available, but, if so, I'll update this entry with a URL when it goes online.
It being RSA week, the news comes thick and fast... I've just seen the press release announcing that the Government of Norway has deployed a whole slew of Sun hardware and software, including Access Manager and Federation Manager, for its pioneering citizen portal, MinSide (English translation: MyPage). Quoting from the press release:
[...] the MinSide [MyPage] portal will roll-out six initiatives that will enable secure, browser-based access to healthcare, tax, motor vehicle registration, social security, student loans and many other government services.
As part of the solution, Sun Java(TM) System Access Manager and Sun Java(TM) Federation Manager help the Norwegian government manage secure access to services by offering single sign-on (SSO) as well as enabling federation across trusted networks of government agencies, service providers and customers. It provides open, standards-based authentication and policy-based authorization with a single, unified framework. This improved security framework is based on the Liberty and SAML standards to protect all aspects of the portal.
I'll be speaking at the RSA Conference on Friday at 9am in Gold Room 310 on Federated SOA: Harmonizing ID Security and Web Services. I'll be looking at the role of identity in Web services, from the very basics of transport-level security to the Liberty Alliance's Identity Web Services Framework (ID-WSF), and how these are realized in Sun Java System Access Manager and Sun Java System Federation Manager. Do come along and say "Hi!"
You might also be interested in Eve Maler and Brett McDowell's session Federated Identity: Evolving Past Industry Strife - Eve and Brett will be talking about the Liberty Alliance's current course and roadmap for the future.
[WS-Federation 1.1], when are thought leaders at vendors like Sun going to come clean and mention this in their blogs. Their silence is suspicious! This is clearly going to become the industry standard for federated single sign-on, despite anything those bozos at OASIS say.
With credit and apologies to James McGovern for stealing his format
Conor and Paul both recently responded to James' questions on federated authorization. Conor quite rightly pointed out that I managed to describe two common scenarios involving federation and authorization without explicitly answering the question - "Does Federated Identity sometimes require Federated Authorization?". As much as it pains me, I have to agree with Conor here - federated identity per se does not require federated authorization - rather, the resource owner might require it. It all depends on the use case that you're implementing.
James also alerted me this morning to a very interesting post from Shekhar Jha. I'll have to take the time to read the SecPAL paper properly, and, even then, there are people far better qualified than me to comment on this, but it does look interesting - particularly the fact that there is a natural language-like, non-XML syntax.
Shekhar goes on to discuss relationships in the identity domain. I refer Shekhar to the excellent work done by Paul on the People Service - FAQ, white paper [PDF], specification [PDF]. This seems to map neatly onto what Shekhar is saying.
Does Federated Identity sometimes require Federated Authorization? If so, how come this isn't ever discussed. Maybe you could address in future blog entry...
There are two models here. In the first model, a given user has a profile (set of attributes) stored at an attribute provider (which may or may not be the same as that user's identity provider). The user goes to a service provider, the service provider receives a SAML 2.0 Assertion containing some set of attributes, and the service provider acts as both the policy decision point (PDP), deciding, on the basis of the user's identity (including the attributes), which resources the user may access, and the policy enforcement point (PEP), restricting the user's access appropriately. Here's a real example in the enterprise space...
Sun has deployed federated single sign-on with BIPAC - BIPAC is the Business Industry Political Action Committee provides expert policy analysis, research and communications on campaigns and elections, and fosters business participation in the political process. Sun employees can access political information on the BIPAC website - who their elected representatives are, their voting record etc.
When I go to the BIPAC site, it redirects me to Sun, I log in with my Sun employee number and password and I'm redirected back to BIPAC with a SAML assertion containing a number of attributes - iirc, whether I'm a US citizen, whether I'm a member of a 'restricted class' of employees and my zip code. Note that the assertion does not identify me personally - it only tells BIPAC that I am a Sun employee with these attributes. Now the BIPAC site can act as the PDP, deciding what I can access, based on those attributes, and as the PEP, constraining my access to the BIPAC site according to those decisions.
In the second model (which is what I think James means by 'federated authorization'), the service provider is still a policy enforcement point, but the policy decision point is elsewhere. In our BIPAC example, the BIPAC site would still redirect me to Sun for authentication, but need not receive any attributes in the SAML assertion - just a pseudonym (SAML Name Identifier) that it can use to refer to me; again, BIPAC doesn't know who I am - the pseudonym can be a one-time identifier - used in this interaction, but never re-used - so I can't be tracked across visits. Now the BIPAC site can make an authorization request of a PDP at Sun, including my pseudonym and a reference to the resource I want to access. The PDP evaluates policy, essentially doing the same thing as the BIPAC PDP did in the previous example, and returns a response to BIPAC that indicates whether access to the resource should be allowed or denied.
Having these two models allows us to factor out authorization and put it where it makes sense. It may well be that it is the service provider that is responsible for policy, based on information provided by an attribute provider (model 1), or, alternatively, the service provider may simply request an authorization decision from a PDP, without being party to the data underlying the decision (model 2).
In terms of specs, both SAML and WS-Federation enable model 1 - passing attributes in assertions which are themselves carried in authentication responses. XACML is the basis for model 2, and is profiled for use with SAML by the SAML 2.0 profile of XACML v2.0 [PDF]. I'm not aware of any commercial products that implement this specification today (perhaps that's why no vendors are talking about it?), but OpenSSO is a good place to go to talk about requirements and implementation - you can sign up to the 'users' mailing list here.
Does this answer your question, James?
UPDATE - perspectives on this from
And responses from James -