Virtual Identity Dialogue

Nishant just posted a blog asking "Can OAuth do what SPML hasn't?" in particular in regards to "federated provisioning".

Just to make sure everyone understands what we are talking about - let's use an example use case where federated provisioning could be required:
Acme Medical Tools has entered an agreement with an online CRM provider. The CRM provider supports the use of SAML to authenticate the Acme Medical Tools users. However, for Acme Medical Tools to be able to use this CRM provider they must have a local account in the CRM provider's database. Federated provisioning would allow these accounts to be dynamically created and updated using an agreed upon method.

There are basically 2 methods to support federated provisioning:
1 - The CRM system could use attributes provided in the SAML assertion from the IDP 
2 - The CRM system can request the attributes from the IDP using a separate request

I would like to point out that we have customers who have done both scenarios. I even wrote the example being used in our current on-demand demonstration for 11g Identity Management. And in the first case - it is possible that SPML could be used on the SP (the CRM provider) (e.g. the federation server gets the attributes and then calls SPML to create/update the record).

But in regards to the where OAuth could possibly be used is in the 2nd scenario.
As shown by this diagram:

So for example the CRM system would make a "Web Service" (I put in quotes because this could be SOAP or REST, standard (like DSML) or proprietary ) call back to the IDP to fetch the user's attributes.

This Web Service would need some type of authentication/authorization to enable it.  And I think the question is whether OAuth could be a solution besides the usual suspects (e.g. username/password, certificates, some other esoteric WS-* security system nobody except the people who wrote the Mayan calendar understands).

OAuth does have some distinct advantages:
1 - It's very simple to implement - it's more like implementing an application-specific, one-time use password - so small shops with less expertise can implement solutions
2 - It doesn't require certificates (it's almost 2010 and managing/signing certificates is still very difficult
3 - Because OAuth tokens have a native time-to-live capability could simplify the process of renewing service agreements 

To make the discussion easier to follow here is a simple diagram that shows basic OAuth steps.

Nishant correctly points out that OAuth expects an end-user involved. This is because the initial use case OAuth was designed to solve was to eliminate the need for 3rd party services to have your password to access those services. For example if you wanted to create a T-Shirt on CafePress using a photo you had on Flickr - OAuth could be used to access your Flickr account from CafePress without CafePress needing your actual Flickr password. The OAuth token could also have a "time-to-live" attached to it so that for example CafePress could only have access to your Flickr data for 4 hours.

He then wonders if IGF policies could be used. It's an interesting idea on the IGF spec and one we'll have to explore further if people do want to use OAuth for these types of scenarios. The other benefit that IGF could offer to this picture besides defining the spec is that policies could be natively known to the client application via the ArisID API. The API is the area of IGF where I have been spending most of my IGF related time lately and hopefully will be able to share more about that soon.

The other component that comes to mind is that OAuth services will need to be able to allow individuals to map tokens to user identies besides themselvs. For example the Acme Medical Tools federated business manager authorizes the CRM service to access the Acme Medical Tools People Web Service but wants to insure the OAuth token corresponds to the CRM Service - not the actual business manager.  That is an area where other access management components can play a part - entitlements, access management, secure authentication.

This is also potentially related to the new User Managed Access (UMA) initiative in the Kantara Initiative. The goal of UMA is to make it easier for consumers to better manage the data relationships with their vendors. This is not only about privacy but also about enabling new business cases. For example if you are looking to buy a new car - instead of starting the usual searching and maybe asking your friends - you could post a "Personal RFP" that listed your requirements. Federated Provisioning would be needed so the dealerships could get information about you to do their own analysis. UMA would define the protocol around publishing the RFP and how the dealerships could access your data and how you can manage that relationship.  The project was started by Eve Maler and I'm participating as a consulting, non-voting member because as I told Eve - I'm one of a small minority who understands - Identity 2.0, SOA and CRM. 

Hopefully I've shed some more light on the subject for people to think about. I would really like to know if your organization has been looking at federated provisioning and/or OAuth.

Posted via email from Virtual Identity Dialogue