Friday Dec 08, 2006

Federated Authorization

In a comment to a previous blog entry here, James McGovern asks

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 -

Tuesday Apr 18, 2006

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

Tuesday Jan 24, 2006

Sun Eats Its Own Liberty Dog Food

One question that I'm often asked by customers is "How is Sun using the Liberty Alliance Project specifications?". Well, my stock answer is 'BIPAC'. 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.

Now, this is obviously sensitive stuff, with huge implications for privacy. The 'old way' of accessing BIPAC would have involved a regular batch process to synchronize identity information from Sun to BIPAC; Sun employees would authenticate at BIPAC with their Sun ID and a BIPAC-specific password. In this old model, BIPAC would know exactly who I was and would be able to build a profile of my activity on the site. Not only that, I'd have another password to write on a post-it note and stick to my monitor remember.

The 'new way' of accessing BIPAC authenticates employees at Sun (using Sun Java System Access Manager) and uses Liberty ID-FF to give employees single sign-on to BIPAC. Now - here's the clever bit - no personal information is transmitted in the single sign-on process. BIPAC have no idea who I am - all they know is that I am an authenticated Sun employee. BIPAC can then use ID-WSF to retrieve a strictly limited set of attributes, including my zip code. So now, all Sun know is that I am a Sun employee in 90210 (well, I can dream). They have everything they need to tell me who my elected representatives are at every level up to Dubya, but no more. They don't know who I am, since they don't need to know who I am. This document gives some more detail on the deployment. Here I am demonstrating the system at a Liberty eGovernment Forum last year in Dublin:

Looking at the wider context, this was an ideal first deployment of Liberty for Sun. A real need for Liberty's privacy features combined with low risk - BIPAC is a valuable service, but not critical to Sun's core business. Watch this space for news as we roll Liberty and SAML out across Sun's other business partners, and, if you're at the RSA Conference next month, be sure to catch Sun's Yvonne Wilson at IMP-101 'Implementing Federated Identity: What Products Do You Need?'. Yvonne is an architect in Sun IT and will be covering our BIPAC integration in her presentation.

About

superpat

Search

Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today