TWITTER AS UTILITY is very similar to how “Email Photo” works when you’re in the Photos app. When you click on the button, the Photos app knows how to call the iOS API to send the picture to the Mail app. From that point on, it is the Mail app that deals with how to send it out as an email, including knowing which account on which email provider (out of many even) to use. The Photos app neither knows nor cares about this. In the Flickr app, an app backed by an online service, when I click on “Email Photo”, the app simply pulls down the URL for the photo and sends that (via the iOS API) to the Mail app. My Flickr service saw nothing about which email provider was used. This is how the “Tweet Photo” button could end up working (except that it doesn’t launch an app but rather an in-built interface to writing up the tweet). Through and after all this, no relationship exists between my Flickr account and my Twitter account. Implication = there is nothing to revoke either.

TWITTER AS IdP is much more involved in not only the app, but in the online service the app represents. The first time I download and launch an app like the LivingSocial app, it will want to associate that app with an account in the LivingSocial service. In a scenario where I’ve never LivingSocial before, it will want me to register for an account. In the current pre iOS 5 world, this involves the app showing me 3 options – “Register for Account”, “Sign In with Twitter”, “Sign In with Facebook”. Clicking on “Sign In with Twitter” would send me through the OAuth dance. If Twitter truly were an IdP in iOS, then this experience would change radically. (Hypothetically) I would instead get the option to “Sign Up with You Twitter Identity” or “Other Options”, and clicking on the first would just get me in, without having to go through the OAuth dance. In fact, if there were an iOS setting that allowed me to set my preference to  always register for services with Twitter (provided the service supports that), then I may never even see the sign up screen. And the backend service now relies on Twitter as my IdP, maybe even being authorized (OAuth permissioning) to interact with it even outside of when I use the app (like if I sign up for a deal while interacting with the website on my computer).

The implications of the latter are pretty vast, in terms of what controls iOS would need to provide users over how to authorize, permission and revoke access. This would be no easy undertaking, and like the Facebook privacy settings we all love to hate, could get very messy and complicated to understand and manage.

Your thoughts? And like I said, I look forward to learning more in today’s event.

Tags: Identity in Social Networking, iOS, iOS 5, OAuth, Twitter

First things first, it isn’t even clear if the integration between iOS and Twitter is based on OAuth or Twitter’s own xAuth. One would hope the former given Twitter’s stated direction. Ping Identity’s resident OAuth wizard Paul Madsen tried to imagine what the OAuth based integration would look like. Looking at it made me wonder if we’re seeing a radical change in how OAuth could be used on devices.

The problem is this: Apple is (justifiably) proud of the attention they pay to the usability of their products. And the OAuth flow would seem to be a problem here. In the simplest form, authorizing all the apps in iOS (camera, contacts, safari, etc) to have Twitter access would repeatedly send the user through the OAuth flow, a user experience I doubt Apple would agree to. So the question is whether a single request token asked for by iOS could be shared amongst all the apps on iOS. If yes, then how can the user manage permissions regarding what these apps can do individually? And how would they revoke a specific app? This model would make it highly unlikely that the integration would extend to 3rd party apps installed from the app store (because of that lack of separation).

Another possibility is that iOS will include some APIs that proxy the Twitter integration. So all communication to Twitter would simply originate from iOS, not from the apps directly. This would eliminate the need for multiple OAuth flows, but the same challenges around permissioning and revocation would remain. On Twitter, the user would just see one app authorized for access – iOS/iPhone/iPad. One way I can see Apple mitigating this while also opening this feature up to 3rd party apps is by adding their own app specific permission layer in the iOS settings. Which would be a practical way to manage this, and open up a whole slew of questions around OAuth and OAuth proxies on devices.

Of course, all of this is moot if the integration requires me to go into iOS settings and enter my Twitter username and password…

Tags: Apple, iOS, iOS 5, OAuth, Twitter

Option 1: OpenID Attribute Exchange

Some view provisioning as being little more than an attribute exchange. So it is natural to consider OpenID Attribute Exchange, which allows the federation service to request additional attributes from the OpenID Provider during the authentication flow. Essentially, when the federation service detects that the user doesn’t have an account, it could validate the claims it received as part of the token, and if it needs additional data, then it could add a request for those to its authentication request.

This can solve the data retrieval challenge, and squarely positions OpenID as a JIT Provisioning protocol. But the componentized architecture we have been assuming does face some other problems that it must solve in the enterprise cloud context. These are not problems with OpenID itself, rather with the overall architecture (again, this disappears when all 3 components are combined into a single service application, which is how OpenID-based RPs are able to do this today).

As discussed previously, when the SP is hosting more than one service, you often find that the attributes needed for provisioning depend on which service the user is trying to get access to. This means that the federation service would need to ask the OP for different attributes depending on which cloud service the user is trying to reach. Since the federation service can no longer just work off a static list of attributes that it should always query for, this adds the need for the federation service to able to ask the provisioning service for the list of attributes it needs, in the context of the specific service being provisioned. While the SchemaRequest operation in SPML could be used here, there needs to be a way to differentiate (in a standard way) the complete schema supported for the target by the provisioning system from that subset needed to create an account.

Another challenge created is for subsequent first interactions of the user with the other services hosted at the same SP. Since the provisioning system already knows the user, it already has some of the attributes it needs, but not all. So when the federation service queries it for which attributes it needs to retrieve, it should reply with just those attributes it doesn’t already have (from provisioning the user to a different service). The SchemaRequest operation cannot handle this scenario currently.

The bigger enterprise challenge is how the work on the OP side can be broken up between the OP (federation service) and the provisioning engine (policy and GRC service).

These are minor challenges to be sure (since you can always just get the full schema and update attributes that have changed to maintain consistency), but ones that become important when the flows are examined for compliance and consistency.

Option 2: SAML Attribute Query

In the last post, I mentioned how SAML (with the SSO Profile) and OpenID are both squarely positioned to handle the majority of the basic JIT Provisioning use cases. Good thing is, the SAML folks have been thinking about the attribute exchange problem as well, and in the spec have defined a mechanism to handle this called the SAML Attribute Query, which takes a different approach from the OpenID solution. The query for attributes in this case can go over what they call a back-channel. This can be leveraged to facilitate an attribute exchange between the Provisioning Services on each side of the federation boundary.

The big advantage of this model is that the front-channel (usually the browser, but could be other environments much harder to manipulate) is not getting overloaded with the data retrieval task. Also, since the two provisioning systems are talking to each other, they are fully aware of what is going on and can enforce standard provisioning policies as well as track and audit the happenings on the other side – major considerations in the enterprise space.

However, this does mean that it isn’t truly on-the-fly, since the SAML spec would require that a trust relationship be defined between the two sides ahead of time. There is actually a lot of interesting work being discussed right now in the SSTC that could directly influence fed-prov use cases, so I would encourage folks to keep an eye on that.

Option 3: OAuth + ArisID (IGF)

Last (but not least) is a possible solution that I first contemplated on my blog a few months ago, and have since been noodling over with other folks, and that is the thought of leveraging two emerging powerhouses – OAuth and the Identity Governance Framework. The idea here is very simple. When the user first goes to the SP, the SP can initiate the creation of an OAuth connection with the enterprise provisioning engine, facilitated by the user, of course (this is, after all, a user-centric protocol). The enterprise, for its part, can put in place policies and risk-based controls that would allow it to trust such a connection. With the connection between the parties established, the SP provisioning service can now use the ArisID APIs being defined as part of the IGF work to retrieve the data it needs. IGF adds a whole policy layer here, since the SP will provide a CARML declaration regarding itself (for instance, including details of its SAS 70 certification), the attributes it needs, and how it intends to use them (emailing user policies, storage policies, etc). The enterprise provisioning engine for its part can evaluate the CARML file and publish it’s own AAPML file with its policies.

One of the interesting things about this approach is that it enables the creation of on-the-fly trust between the two sides. The enterprise may never have dealt with this SP before, but can still interact with it with a certain level of trust. This trust is built on two separate components – the assertion from the user itself asking that provisioning take place (OAuth flow), and the CARML file declarations (IGF flow) – that make the creation of the federation a risk-based decision (automate-able) as opposed to a business decision (manual). Since this model also involves the provisioning engines on both sides, the security and policy controls can be enforced.

Still Work To Be Done

These models obviously need to be explored and poked at in depth to determine if they hold. And while these depend on some standards work that is still to be baked, there is a lot of other standards work happening (in particular in the OpenID and OAuth arenas) that could supplant these options completely.

And there are major lifecycle management issues still to be discussed and explored. How does one handle de-provisioning in a JIT Provisioning environment? How can SPs that want to know about profile updates find out outside of the user interaction? And how do all those workflow and policy based controls that are present in Provisioning systems today fit into all of this? Well, I will be exploring some of this in my Burton Catalyst North America talk on “Beyond SPML: Access Provisioning in a Services World” in July. So be sure to check out that session if you’ll be there. In the meantime, please keep leave your comments and feedback here so we can keep the discussion going.

[Ends Part 4 of 4]

Tags: Attribute Exchange, Cloud Computing, Federated Provisioning, Gluecon, GlueCon-FPSeries, Identity Governance Framework, IGF, JIT Provisioning, OAuth, OpenID, SAML

One of the topics that has been fodder for some animated discussion has been the topic of federated provisioning. As the cloud has brought federated authentication back into focus, it has also shone a light on the need for federated provisioning to power cloud identity. After a very interesting discussion that I had with some folks who are looking at identity in the cloud, I posed the following question on Twitter:

Had an interesting discussion this morning on how OAuth could be to federated provisioning what OpenID is to federated SSO. Any takers?

The Thesis

Federated provisioning is about creating an account with appropriate privileges in underlying systems on the Relying Party side when triggered by an authentication event (user comes to the RP service from the Identity Provider, or IdP, side). Further, the authentication token being presented to the RP does not contain sufficient claims (attributes, etc) for the systems on the RP side to create the necessary account (there are other scenarios, of course, but this is the common one I am trying to address). Consequently, we have a need for the RP to get provisioned with data from the IdP side.

Now in my post “The Thing About Federated Provisioning“, I pointed out that there are challenges in doing all of this just-in-time. Enterprises often resort to out-of-band pre-provisioning of accounts across the domain boundaries, which is where SPML proves to be adequate. But the demand for JIT mechanisms still exists. The cloud exacerbates this problem greatly, because pre-provisioning is pretty much impossible when you move up to the scale and loose coupling of the cloud. And the nature of SPML requires that extensive integration be done before the connection between the RP and the IdP can go live.

And this is where I believe OAuth could play a role. OpenID is already viewed as a lightweight solution for enabling federated authentication, with attribute exchange supporting the simpler data transport scenarios. We could now augment this flow by adding an OAuth-based data provisioning mechanism that allows a Provisioning Service on the RP side to connect back to a Provisioning Service on the IdP side and retrieve the data it needs to create the underlying accounts. Being based on OAuth, this would require far less integration than the SPML based approach would.

Mapping the concepts, the RPs Provisioning Service becomes the OAuth Consumer, while the IdPs Provisioning Service becomes the OAuth Service Provider. The interactions are outlined in the diagram below (greatly simplified for the purposes of this discussion).

The Challenge

But when you look at the actors involved in OAuth, you run into one problem – OAuth was defined with users in mind, not enterprises. So you find the User as part of the protocol, but nothing that would allow the Enterprise to have a say in the exchange. And this raises an interesting challenge.

Just like there are security issues to resolve in the OpenID protocol for it to satisfy enterprise requirements, there are policy challenges that would need to be resolved in the OAuth exchange as well. Connecting the services only requires that the user in the flow provide their assent, but if OAuth were to step in as a federated provisioning protocol, it would require some way for the enterprise to inject (fine-grained) business policy into the exchange. And what if approval workflow needs to enter the picture?

One thought would be to introduce an IGF style declarative policy mechanism that would allow the services on each side of the exchange to declare intent and policy, thereby allowing some automated decision making that ensures that security and business policies are honored by the exchange. Because when you are talking about fed-prov, a one-size-fits-all construct will be a non-starter.

My posting on twitter did generate some good feedback from folks like Eve Maler and Ashish Jain. I am interested to get people’s thoughts on the viability of this idea, and whether you think adding OAuth to provisioning systems would be part of the move to enabling enterprise identity management systems for the cloud.

Tags: Cloud Computing, Cloud Identity Model, Federated Provisioning, OAuth, SPML