Saturday Feb 14, 2009

Federated Provisioning - Liberty to the Rescue???

I thought I'd throw my hat into the ring of the current federated provisioning discussion (Ian, Nishant, Ian again, James) ...

Looking at the contentious #2 in Nishant's post, the Liberty Alliance standardized one approach to this several years ago with ID-WSF.

To recap the scenario:

Suppose two companies, Acme and Omega enter into a federation agreement, whereby employees of Acme will be able to access a service at Omega using their Acme credentials. There are two scenarios here for federated provisioning.

[...]

Acme decides that they are not going to decide beforehand which employees are allowed to access Omegas service. Instead, a link to the service is available on Acmes intranet, and whenever a user decides to go to the service, they should be given an account. In this case, no pre-provisioning is taking place. Instead, the provisioning has to occur in real-time, when the user accesses the service via the intranet link for the very first time.

The idea here is that when Omegas federation server encounters the incoming SAML token for a new user, it would recognize that the user does not have a federated account, and send the SAML token to Omegas provisioning server. The provisioning server would create the account right then and there, and return the necessary result back to the federation server so that the federation server can proceed to grant the user access.

Now, in my Liberty-tinged version, when sending a new user to Omega, Acme includes a reference to their Employee Profile (EP) service - essentially the service's endpoint URL - in the SAML assertion. This endpoint reference serves as both a description of where to find the service and permission for Omega (when sent as part of the signed SAML assertion) to invoke that service.

On receiving the assertion, Omega send a signed request to the EP service, the request containing the SAML assertion it just received. Now, the EP service knows that Omega is entitled to access that employee's data, since it has a signed SAML assertion, issued by Acme itself, that says exactly that (via the presence of the EP endpoint reference). The EP can return exactly the data required (this will have been configured according to the underlying contract between Acme and Omega).

Finally, if desired, the EP can leave a marker in the employee's account that says 'account provisioned at Omega', so that Acme doesn't send the EP reference in every SAML assertion. Alternatively, Acme could deliberately send the EP reference every time. Or even reset the marker when the employee's account changes in a significant way (say, her purchasing limit is changed) so Omega can fetch the new employee data.

In scenarios where manual intervention is required on the Acme side, the EP service can return a response that says "Come back later", and the Omega service relay that to the user.

Of course, de-provisioning is a different kettle of fish, but the advantage of federated access to services is that, once the employee is gone from the Acme end, he has no way to access the Omega service anyway, so de-provisioning is a little less urgent than if the employee was logging in to Omega directly.

Like I said, ID-WSF has been around for years. Perhaps it hasn't had much adoption because businesses weren't encountering the problems that it solves. Seems like that might change now...

Tuesday Sep 02, 2008

ID-WSF 2.0 Javapolis Video Online at Parleys.com

Another entry from the 'While-I-was-on-vacation' department... Video from my JavaPolis ID-WSF 2.0 session was posted at Parleys.com. This is the third and final session I did at JavaPolis last year, the previous two covering OpenSSO and SAML 2.0.

There's also a short report from the JavaPolis 2007 Speaker and JUG Dinner - you can catch a couple of glimpses of me enjoying the JavaPolis hospitality, though Harold and Alexis get speaking parts...

Monday Dec 17, 2007

Slides from JavaPolis 2007

OK - one more post in this jetlag-fuelled blogging frenzy...

Here are the slides from my JavaPolis 2007 sessions:

Many thanks to the JavaPolis organizers, in particular Frank Cornelis, for inviting me to speak and making me so welcome at JavaPolis. It was a pleasure and a privilege.

Monday Feb 12, 2007

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.

Tuesday Feb 06, 2007

Speaking at RSA Conference on Friday Feb 9 2007

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.

Monday Jan 15, 2007

InfoCard and Minimal Disclosure

[I would have left this as a comment on Kim's blog, but I don't have an InfoCard handy and I can't figure out how to register there for a good old username and password...]

Kim Cameron replies to a question from Eric Schultz with a description of how InfoCard (or is it CardSpace?) handles minimal disclosure, allowing the relying party to request only the information it needs. In Kim's example, the relying party requests four claims regarding the user via an OBJECT tag:

Then, according to Kim,

If, next time, the relying party doesn’t want to receive these claims, it just doesn’t ask for them. If it has stored them, it should be able to retrieve them when necessary by using ”privatepersonalidentifier” as a handle. This identifier is just a random pairwise number meaningless to any other site, and so there is no identity risk in using it.

But, but, but... how does the relying party know not to ask for givenname, surname and emailaddress the second (and subsequent) time round? It doesn't know that it's already collected those claims for that user, since it doesn't know who the user is yet...

If only there were some specification [PDF] (perhaps part of some sort of framework) that, given a token from an authentication, allowed you to get the data you needed, subject, of course, to the user's permission [another PDF]. Smile!

Sunday Nov 20, 2005

Demonstration of Identity Web Services

Following on from my recent posting of a Federation Manager demo showing Liberty ID-FF federated single sign-on, here is a demo of Access Manager and Federation Manager I showed at a Liberty 'eGovernment Forum' in Dublin back in April.

This demo shows an employee of the 'Department of Health and Children' logging into the department's portal, visiting another government department, the 'Stationery Office', to obtain an official report, and having the Stationery Office query their 'home' department for a mailing address via the Liberty Identity Web Services Framework (ID-WSF).

This is a very simple demo, but it demonstrates some key aspects of Liberty ID-WSF:

  • 'Bootstrap' from federated web single sign-on (ID-FF) to web services (ID-WSF).
  • Use of the Discovery Service to locate a web service for a given user. (This takes place 'under the covers' - the bootstrap provides the service provider, in this example the Stationery Office, with the location of the Discovery Service and a credential to use on behalf of the employee. The service provider queries the Discovery Service for the location of the Personal Profile service).
  • Use of the Personal Profile Service to retrieve a user's profile attributes.
  • Use of the RedirectRequest protocol (specified in the Liberty ID-WSF Interaction Service Specification) to allow the employee's 'home' department to prompt for confirmation that address information is to be released to the Stationery Office.

Just click the screenshot below to view the demo...


Click to view Flash presentation

UPDATED 11/21/2005 - corrected Interaction Service to RedirectRequest protocol - see comments

Wednesday Jun 29, 2005

Sun/Turkcell Liberty ID-WSF Proof of Concept

Great news in my inbox today: Sun and Turkcell (English-language version of Turkcell site) have published a paper on a recent proof of concept. Turkcell used Liberty's ID-WSF to implement an SMS service fulfilling three key requirements:
  • Protect subscriber privacy - subscribers' cellphone numbers (referred to as MSISDNs in the document) must not be revealed to 3rd party service providers.
  • Leverage subscriber location, again, while protecting subscriber privacy.
  • Use standards and off-the-shelf products wherever possible.
Turkcell used Sun Java System Access Manager as their identity provider, with an early access release of Sun Java System Federation Manager at the service provider. According to the document, "[Turkcell] successfully conducted a PoC project that has resulted with the accomplishment of all pre-defined requirements." Also, "We have found that the Liberty Alliance Specifications are brilliantly matching our needs and even exceeding in some ways." 
In the use case scenario, a GSM user sends a service request via SMS to a service provider to discover restaurants near the user's location. The service provider leverages the wireless operator's geo-location service, customizes content, and returns a corresponding list of restaurants back to the user.
Go read the paper and discover exactly how Sun's federation products and Liberty ID-WSF met Turkcell's requirements, and then some.
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