Friday Jun 19, 2009

links for 2009-06-19

Friday Jan 18, 2008

Fine-Grained Authorization with Sun Java System Access Manager

Following on from last June's Sun Developer Network article on Basic Authorization with Sun Java System Access Manager, Robert Skoczylas of Indigo Consulting and Sun tech author Marina Sum recently published a second article, Developing Secure Applications with Sun Java System Access Manager, Part 2: Advanced Authorization.

This time, Robert and Marina look at how Sun Java System Access Manager can be used as a general purpose policy store, and, with some customization, can provide fine-grained authorization for UI elements rendered by both Java and .NET web applications. This is a great article to read if you've wondered how Access Manager can be used to authorize access to resources other that the usual web page URLs.

Wednesday Nov 28, 2007

Authorization with OpenSSO's Identity Services

One new area of work in OpenSSO is Identity Services, allowing a developer to easily write code to authenticate users, check if those users are authorized to access resources, retrieve those users' attributes etc. While all of this functionality has long been available in different forms, the new Identity Services work collects common identity tasks into an easy-to-use set of web services accessible via SOAP and REST. Now developers working in just about any language can join the identity party

Last month, Aravindan and Marina published a Sun Developer Network article showing how to use OpenSSO's identity services for authentication. This month, Lakshman Abburi joins them to cover authorization with identity services. The identity services client from part 1 is extended to check whether the authenticated user should be allowed access to a given resource, in this example, a URL. Although the article focuses on Java and NetBeans, as I mention above, you can invoke identity services from just about anywhere. Go read the articles, have a play, and leave a comment here or there if you do something really cool.

Monday Jun 25, 2007

Basic Authorization with Sun Java System Access Manager

As I reported yesterday at The Aquarium, Robert Skoczylas of Indigo Consulting and Sun tech author Marina Sum just published Developing Secure Applications with Sun Java System Access Manager, Part 1: Basic Authorization at Sun Developer Network. This article, part 1 of a series, presents a case study of implementing authentication, single sign-on, and authorization at a fictional health-care insurance company.

There's some really good stuff in there - Robert and Marina work from a high-level description of the problem right down to specific Access Manager customizations. In particular, the detailed description of customizing Access Manager's policy framework is well worth the read for anyone working with, or evaluating, Sun Java System Access Manager.

Tuesday Dec 12, 2006

More on Federated Authorization

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.

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 -




« July 2016