A while ago I blogged about the Access Manager ‘Configuration and Customization’ training course in Burlington, MA, presented by Allan Foster. Well, I’ve just heard that Allan is presenting it again in Amersfoort in the Netherlands, on January 22nd. If you’re in Western Europe and you want a great grounding in AM, you might just want to go…
[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
OK, Eve, you got me. Here are my five.
- I’m not really Pat. My legal name is Andrew Patterson. There were four Andrews in my class at school, so we all got nicknames. Mine was Pat, short for Patterson. The others were Fingers, Rico and Chads.
- My original university application (UCCA, for those of you who were in the UK education system at the time) was for medicine. That didn’t work out – medicine’s gain was computing’s loss. Or something.
- I have Scottish ancestry (from my parents on back) – I got married in a kilt and occasionally wear it for special occasions.
- I just got selected for Sun’s SEED mentoring program. I struck the jackpot in that my mentor is a (very well known) Sun Fellow, but I can’t go into any more detail there right now. With my mentor’s permission, I’ll blog about this as it goes along.
- My guilty pleasure is Cadbury’s Dairy Milk Chocolate. My mother-in-law brings kilograms of CDM when she visits from the UK and it has a special drawer in our fridge. There’s nothing like a couple of squares straight from the fridge with a nice cup of tea 🙂
The XMLSIG FOR DYNAMIC LANGUAGES project aims to create a set of libraries for securing XML format information in accordance with the W3C Digital Signature and Encryption standards. The libraries enable developers to rapidly integrate digital trust servic
XML Security Library is a C library based on LibXML2. The library supports major XML security standards: XML Signature, XML Encryption, Canonical XML, Exclusive Canonical XML.
Libxml2 is the XML C parser and toolkit developed for the Gnome project (but usable outside of the Gnome platform), it is free software available under the MIT License. XML itself is a metalanguage to design markup languages, i.e. text language where sema
The Libxml-Ruby project provides Ruby language bindings for the GNOME Libxml2 XML toolkit. It is free software, released under the MIT License
The PyXML package is a collection of libraries to process XML with Python.
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.
Brooks’ 1987 essay on (the impossibility of) software engineering panaceas
…to move into either videography or singing. From the un-talent show at IIW 2006b:
UPDATE 1 No idea what was happening here!
UPDATE 3 Paul Madsen’s view
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 –
This week at Internet Identity Workshop 2006b I’ve been demonstrating some work I’ve been doing to combine YADIS/XRI Identifier Resolution (as in OpenID) with SAML 2.0 Web Browser SSO Profile. The user experience is:
- I go to a service provider (relying party)
- I enter my identifier (URL or i-name)
- I authenticate at my identity provider
- I can access services at the service provider
The magic takes place between steps 2 and 3: the service provider resolves the user’s identifier, which might be a URL or an i-name, to the location of a SAML 2.0 identity provider. The service provider can now do vanilla SAML 2.0 with the identity provider. The easiest way to see what’s going on is via a demo, so, here you go:
Click to view Flash presentation
By the way – the service provider is implemented on top of Project Lightbulb. I need to do some tidying first, but I’ll put the YADIS/XRI code there soon.
UPDATE – coverage of this demo at IIW2006b:
- Lightbulb: Bringing SAML to PHP
- Internet Identity Workshop demonstrations steal the show – nice pic on this one. Left-to-right we have Doc Searls, my good self, Shin Adachi and JP Rangaswami.
In between all the talk of federation, PHP and web services, we sometimes lose sight of the fact that bread-and-butter single sign-on and access control still has huge value in improving both security and the user experience. Over at the Sun Developer Network, Marina Sum and I just published an article – Sun and Microsoft Interoperate for Web Authentication, Part 1 – focusing on how Sun Java System Access Manager and its policy agents integrate with Microsoft IIS to provide both single sign-on and access control – right down to Windows ACLs on files on disk.
As the article mentions, some functionality (specifically, the basic authentication plugin – from the ‘Configuration of the Policy Agent for HTTP Basic Authentication’ heading to the end – sorry, there is no handy name anchor in there to link to) will be released in AM Policy Agent for IIS 2.2-Hotpatch6 sometime in the next few weeks. I’ll post here as soon as this is available; at that point you will be able to work through the entire article. In the meantime, much of it works with the current policy agent, so you can get started straight away.