Going on strike

This blog will be going on strike January 18 from 8AM to 8PM in support of the SOPA/PIPA protest.

This protest reflects my personal concerns about the upcoming US legislation and does not necessarily reflect those of my employer.

Introducing JSR 351 - The Java Identity API

The Java JCP has approved a new JSR relating to the use of Identity information within Java. The JSR351 charter is:

To define application programming interfaces and identity interaction models that facilitate and control the use of identity by applications and in access control decisions.

Ron Monzillo gave a talk (presentation available here) at JavaOne on JSR 351, I'll paraphrase his presentation with some of the highlights here:

IIW XII: Adding Identity Information to OAuth2

IIW XII is coming up October 18-20, so I thought I'd share with you a couple of discussions I'd like to open at IIW. The first one is how best to add user identity or authentication information to OAuth2.

The OAuth Identity Information Problem
As many of you know, OAuth2 enables a process whereby a client application, as authorized by a user, is issued a "valet key" (a token) for accessing protected resources controlled by the same user at some resource site/service provider.

One limitation of OAuth "valet keys" is that client applications do not receive information about the authorizing user. From the client application's perspective, the authorizing person is anonymous unless the underlying resource API (e.g. a social graph API) can reveal information about the authorizing user. To date, this has been the typical technique used with Twitter and Facebook. But what if, instead of a social graph API, the resource being accessed by a client application is a bank account, a set of medical test results, or a set of photos? Obviously not all resource service providers provide identity information. What if there was a standard way for client applications to obtain information about the authorizing user?

OpenID Connect's Proposal
Members of the OpenID Foundation have already been working on this. OpenID Connect has been touted by many as an important addition to OAuth2 because it would define a way for an artifact to be passed to the client application that the client could use to obtain more information--or, so I thought. Instead, the current "connect" specification suggests that an ID_token be given directly to the client in addition to the resource access token that shares basic profile information. Is this sharing of information going to be acceptable to all OpenID Providers? Shouldn't there be a trust mechanism between client applications and identity providers (OPs)?

Further, the "Connect" specification seems to assume that only OpenID Providers would be used by a resource provider and its OAuth authorization server. What happens if resource providers want to use multiple types of authenticating services such as local authentication via LDAP or federation through SAML? It seems there is something missing with the current Connect proposal. We need a way for OAuth to hand off identity information while not mandating a single protocol solution. We need a way for multiple federation protocols to work at the same time in an OAuth based service.

While I liked the original idea of OpenID Connect, I think the hand-off between OAuth2 and identity sources needs to be more flexible.

Proposing an OAuth Identity Draft Discussion
A new IETF OAuth Identity draft that lays the foundation for resource sites to be able to share artifacts that enable clients to obtain identity and personal information seems to be needed. It would enable an open solution whereby resource sites could freely choose from the many types of identity providers out there. A core OAuth Identity specification could leave room for differentiated service approaches (e.g. session management) between OpenID, SAML or any other protocol, while defining the key inter-op/hand-off points with OAuth2. Based on such an IETF draft, individual protocol profiles could then lay out the details of how particular protocols such as OpenID, or SAML, or other APIs/protocols should work in relation to OAuth2.

Comments? Thoughts?

If you are going to IIW XII, I'll have a quick ppt with some thoughts on the issues to get the discussion going. Let me know if you are interested in contributing.

ps. Don't forget to register for IIW.

Rushing Towards Cloudy Standards?

I have become recently worried about the rising popularity of informal standards these days. Informality is something that has been rapidly emerging in the rush towards cloud computing. The rush to develop new protocols is often quite important and is being done out of critical and urgent need. Many of these groups have achieved early success. Yet they remain afraid that getting the legal aspects of their work done is somehow a risk to success and isn't needed. Yet why undertake the work, if the outcome will be compromised by unclear rights for the users of the specification or its authors?

Andy Updegrove, an intellectual property lawyer, writes in a recent blog post:

The impetus for the new programs comes in part from the proliferation over the past several years of more and more ad hoc development efforts focusing on individual protocols and other Web standards. These efforts have typically been very bare bones, utilizing the same techniques employed by open source projects (indeed, they have often been launched by the same developers). In contrast to traditional standards development, such a project involved no more than a Wiki and perhaps a few additional Web pages. Not surprisingly, they have also often been launched by teams that have had little or no prior experience with the traditional standards development process, or the reasons why that process has evolved to operate in the way that it does.

Why not avoid this mess and use well proven paths to success with existing standards development organizations? What was wrong with organizations like Kantara, OASIS, the W3C, and even the IETF? The perception seems to be that these organizations are just too bureaucratic and/or too expensive. Many didn't see the value they create. Many, without cause, just felt that it was the domain of large companies and that only big companies could participate. Yet when I checked out the facts, most of these organizations support both individual and corporate memberships that are in fact very low (in the hundreds of dollars). 

Recently, the World Wide Web Consortium (W3C) had many of the same observations and initiated a committee to dry and develop a more agile process. Andy observes that many shunned well proven paths for a more utilitarian approach:

This utilitarian approach allowed for very rapid development, but it also meant that the resulting work product was created without the benefit of any of the supporting infrastructure, tools and protections that a traditional standards development project provides:  

• The developers were not bound by the terms of an intellectual property rights policy, meaning that a participant with ill intent could set up a “submarine patent” trap without worrying about the legal consequences. 

• There is no legal organization to own a trademark in the protocol to ensure that claims of compliance cannot be made when in fact a product is not compliant, thus jeopardizing the credibility of the protocol or standard. 

• There may be no one to provide ongoing support for the effort if the participants later drift away. 

• There is no organization to promote the work product, or to lend credibility to the result. 

• There is no in-place pool of members to provide breadth of input to maximize the quality of the result, or to act as a springboard for broad and rapid adoption when the effort is complete. 

Andy writes, the response to this phenomenon was the formation of the Open Web Foundation. It is a good start, but OWF only partially addresses the gap between a "protocol group" and a "traditional standards organization". I have to agree.

Read Andy's blog post to get the full story.

Note: as usual, the opinions expressed are my own personal opinions and do not necessarily reflect those of my employer. I am not a lawyer, but do participate in several standards organizations.

SCIM at IIW - Looking for Simple and Effective

I attended several sessions at IIW last week discussing the new Simple Cloud Identity Management (SCIM) proposal. Already, there have been several positive and negative blog posts on SCIM. I won't try to rehash them, but here are a list of a few:

• Martin Kuppinger, Kuppinger-Cole, April 23, SCIM – will SPML shortcomings be reinvented?
• Nishant Kaushik, Oracle, April 25, SCIMming the Surface of User Provisioning
• Dave Kearns, Network World, April 29, SCIMing the provisioning landscape
• Patrick Harding, Ping Identity, April 29, Why SCIM over SPML? Why not?
• Mark Diodati, Gartner, May 6, SCIM and the Future of Standards-Based Provisioning
• Dave Kearns, Network World, May 10, Got SCIM?

SCIM Related Links:

• Information Site
• Google Code Project Site

SCIM supports a couple of key data flows which are:

• Copy and update identities from an enterprise cloud subscriber (ECS) to a cloud service provider (CSP) based on some event based triggers [ECS to CSP].
• Copy and update identities between cloud service providers [CSP to CSP].

For a list of possible event triggers, and flow details, check out the scenarios document here.

During the discussions, there was a question about having new operations designed to differentiate between delete and disable/suspend. For workflow based systems, suspend is often more preferable to delete. It also allows an account to be easily re-enabled. One issue this question exposes is that different end-points might interpret update events differently. For example, upon receiving a "delete" event from an ECS, a CSP might simply choose to suspend an account for either practical or even legal reasons. Thus one complication might be that read-after-delete confirmation techniques might not work as expected. Or even more tricky is the idea that the cloud-vendor might still want to allow logins by the user even if the cloud application is disabled -- if only because the cloud vendor wants to be able to gracefully redirect the user back to their enterprise to request re-enabling.

On another subject, should updates be bi-directional? If SaaS applications are generating value and hence data, how much identity information will need to be synchronized in the reverse, back to the enterprise clients, and bi-directionally between CSPs? The group felt that while this wasn't out of the question, but that the current priority was definitely unidirectional. This makes sense. At present, most cases seem to focus on centralized workflow initiated events such as hiring and retiring. 

As with many of the commenters above, I can't help but think we've been here many times before. Will SCIM work as well inside the enterprise as suggested by Mark Diodati? Maybe, but I do think there are some new multi-organizational twists to the old enterprise problem. Ownership and control of data is a new challenge not present in the classic enterprise scenarios. On the subject of "lightweight", Dave Kearns wrote this morning, is it really about finding lightweight solution? Patrick Harding points out, none of this matters if it isn't adopted. Good questions. Me, I just want something simple and effective. It is the latter requirement that makes this hard.

OAuth: Does it replace federation?

Today I received a question about OAuth and whether it replaces existing federation deployments. Would OAuth, WS-Trust, and SAML work together? The answer is no. In fact, OAuth is built to use any authentication system, local or federated.

Note: Coincidentally, Paul Madsen, also posted an interesting graphic that gives a swim lane view of OAuth's flow with an IDP. 

I discussed some of this in my earlier post "OAuth: Does it authenticate?" Instead of prescribing what authentication is possible with OAuth, the OAuth specification simply assumes that there is some form of authentication mechanism in place that is acceptable to the service provider. It could be local authentication (e.g. as seen on Facebook, etc), or federation from SAML, OpenID, etc.

Here are a couple of diagrams (click to enlarge) showing the use of OAuth with a federated IDP. In Figure 1, the client application "ClientApp" of an employee of "IndependentId Enterprise" wants to access a cloud application service hosted by cloudsvc.org. In step 1, ClientApp sends an authorize request to the cloud service via the smartphone browser to the endpoint:

https://cloudsvc.org/authorize/cloudService/independentid

The authorization service determines if the browser already has an authenticated Web SSO session with the user. If not, the authorization point determines the user's home IDP by looking at the original authorize URL. In this case, it indicates the authorization was for IndependentId.com. The user's browser is redirected to IndependentId's SAML IDP where the user authenticates and a SAML Assertion is returned (step 2).

Figure 1

In Figure 2, the Cloud Service Provider having received the users SAML Assertion and authenticating the user, determines by policy that all IndependentId users automatically grant access to the "CloudApp Service". In step 3, the authorization service then redirects the users browser back to:

clientApp://independentid&code=i1WsRn1uB1&

The phone switches to ClientApp and passes it the redirect URL which contains the authorization code. In step 4, ClientApp then uses the code, along with its own client_id and client credentials (e.g. client_secret) and obtains an access token. Finally, in step 5, the client app is able to access the CloudApp Service. Note that the ClientApp can continue accessing the service for as long as the access token is valid which may be minutes, hours, days, or permenantly depending on the security requirements.

Figure 2

There are lots more variations on this. For example, during the authorization request, the IDP endpoint may not be known. In that case a NASCAR style authentication process could take place. Also, in step 4, the token server could elect to return a refresh token. This allows the ClientApp to maintain a longer session with the service without having to re-authenticate the user. Meanwhile, access tokens still maintain a shorter lifetime forcing the ClientApp to silently re-authenticate and provide a refresh token to continue to validate the clients access over time.

OAuth: Does it Authorize? Yes, but much more

My previous post asked the question "Does OAuth do authentication"? In this post, I explore OAuth2 and its support of authorization.

When most people ask the question about whether OAuth2 supports authorization, you might be thinking in terms of today's authorization/access management/policy systems. But, as mentioned in my previous post, authorization here is within the terms of how HTTP defines it. A fairly low-level distinction that convolves authentication and authorization. To really answer the question we must look at how HTTP defines authorization. Then we can begin to look at the larger implications of how OAuth2 impacts authorization in a more modern, higher level view.

What is HTTP Authorization?

Consider authorization from the standpoint of HTTP/1.1 (RFC2616). Section 14.8 defines authorization as a user-agent providing an authorization request-header field with its HTTP request(often after receiving a 401 response). The value of the authorization field consists of

"credentials containing the authentication information of the user agent for the realm of the realm of the resource being requested."

It seems that the authorization header specified in RFC2616 is not really an authorization, but rather an authentication credential. But consider the time frame when RFC2616 was authored. In that timeframe, authorization was rather simplistic. Do you have an account? If so, you are 'authorized'. Note: I may be over-simplifying the specifications here, but I think it you'll see more clearly where this is going.

So what does OAuth2 do for authorization?

Classic web access management (e.g. Oracle Access Manager) support users who use browsers accessing protected web sites. Over time, the control exerted over what users could do has become increasingly fine-grained such is the vision with XACML. Yet, typically these systems involve end-users requesting web resources rendered in browsers, or distinctly there may be separate "service" managers (such as Oracle Web Services Manager) supporting WS-* based services over SOAP.

OAuth2 supports a range of new use case scenarios. Many do not directly involve a user or a browser, but rather define a client application acting on behalf of a resource owner's (e.g. the user) behalf using only HTTP to access REST based services in a lightweight fashion. From an authorization perspective, OAuth2 use cases introduce the new capability that client applications, each with their own identity, act on behalf of a users that own resources and can perform service calls with a specified "scope". In its simplest form, OAuth2 provides a means to identify and perform authorization of two security credentials: that of the user that owns a resource, and that of an application.

What credential relationships are supported?

OAuth2 enables most combinations of relationships and in theory allows for extensions define new ones. Currently defined are:

• A client app, who also has the resource owner credentials, acting on behalf of a resource owner (see Resource Owner Password flow).
• A client app obtaining user/owner authorization (see Authorization Code flow).
• An unidentified client (typically javascript in a browser) acting on behalf of a resource owner (see Implicit Grant flow).
• A client app acting using its own authority (see Client Credential flow).
• A relationship defined using an extension (see Extensions flow). For example, a client app using an externally generated SAML2 Bearer assertion. The SAML assertion defining what Identity and/or what rights are being expressed.

What about OAuth2 authorization goes beyond security credentials?

RFC 2616 together with sister specification RFC2617 (Basic Authentication) define a rather simple notion of "authorization" as simple rights corresponding to a single user account. In OAuth2, we have the possibility of 2 entities: a client app acting on behalf of a resource owner.

But, to further narrow the focus from specifically what a specific client can do can do in a particular credential relationship, OAuth2 introduces the notion of scope. Scope defines capabilities of a client application performed on behalf of the resource owner. These capabilities may be thought of as roles or entitlements within the resource API. Typical examples are of the style: readProfile, updateProfile, readStatus, updateStatus, readBalances, payBills, executeTrades and so on. OAuth2 says almost nothing about what the possible values of scope can be - it is entirely up to the site being protected to determine meaning. In theory then, it is possible to set very specific scope such as the right to access a very specific URL. But in practice, it seems the use of scope is usually defined by the underlying web service API as enabling simple "capabilities".

For a more in depth discussion on capabilities, check out Hal Lockhart's recent post on "The Property-Capability Spectrum of Attributes".

What forms of authorization can be supported by OAuth2?

OAuth2 systems can support any number of authorization systems so the types of authorization that can be supported are unlimited. However, because the end-result of an OAuth2 authorization flow is always an authorization token (aka access token) to be used in a subsequent operation, the types of authorizations that can be handled are limited to those decisions that can be calculated in advance. At the time of authorization in OAuth, remember that that actual resource has yet to be accessed, so no transaction is occurring.

As an example, consider that OAuth2 systems can clearly handle [actors and scopable actions bolded for emphasis]:

"CheckPayer may writeChecks for Phil"

vs. a contextual or transactional authorization decision of

"CheckPayer may write a check on behalf of Phil for $50 payable to Nishant now".

The latter decision will still have to be decided by a policy system within the context of the transaction rather then within the context of an OAuth2 authorization. The reality is the likely OAuth2 products will define a mix of "capability" style authorizations together with access management systems. Thus if, the first statement was known as "philCheckToken" embodies the right of a client to write checks for "Phil", then the transactional statement might be:

"philCheckToken writes check for $50 payable to Nishant"

We know that the client (identified by philCheckToken) is allowed to writeChecks for Phil. Now the transaction policy simply checks to see if Nishant is a valid recipient and if the amount is within policy (and potentially whether Phil has $50). In OAuth2, these authorization systems will work together to make in-advance "capability" assertions, together with applying fine-grained decisions in the context of actual transactions.

OAuth: Does it authenticate? Well...Yes and No. And that's a good thing!

I'm not kidding. OAuth itself doesn't seemed to be defined. It's not an acronym just a name. In fact the specification draft simply says:

The OAuth 2.0 Authorization Protocol

"OAuth" itself isn't spelled out in most places. Wikipedia says its "Open Authorization". But who knows. I can't tell you how many times this question comes up. But if you ask me, it doesn't matter and that is a good thing. Let's dive into the question of authentication...

Does OAuth authenticate users?

No. The answer here is clearly no. Not only does OAuth not authenticate users, but it doesn't have anything to say about user authentication. But hang on, see the next question...

Does OAuth accomplish user authentication?

Yes. The answer here is yes, but the method is indirect. If you read my post on OAuth flows, you will know that OAuth has an "authorization" step that requires users to authorize clients to act on their behalf. For OAuth, authentication then is a logical conclusion of authorization.

In order to authorize a client to act on behalf of a user, the user must be known.

For a user to be known, the user must be authenticated.

Therefore, if a user has authorized a client, they must have authenticated.

This logic flow is at the heart of OAuth's power. Because authentication of participants is a necessary requirement of authorization, OAuth doesn't have to say how authentication is accomplished. Because of this, OAuth can be integrated with all sorts of authentication systems and protocols such as: LDAP, OpenID, SAML, WS-Trust, WebSSO, etc - placing OAuth at the crossroads of identity.

Ok, so does OAuth authorize?

Now you're jumping ahead. That's the subject for the next blog post. Stay tuned.

OAuth Flows - Extended

Updated: Revised flow to add javascript implicit flow.

I received a lot of interesting comments on my previous post, "Does OAuth Have Legs". That post was about trying to understand what was meant by legs in OAuth. It included a useful diagram which I have since updated based on feedback. The revised diagram is available below (click to enlarge).

A couple of notes:

• The flows depicted are from the perspective of what a client app has to do to access a protected resource.
• The general consensus was that "legs" was meant to refer to parties and not the number of steps though co-incidentally, it was often the same. The consensus on the OAuth mailing list seems to be to now refer to, 2-party or 3-party flows.
• Each party has one or more "roles" as defined in OAuth: Resource role (the resource being requested), Token Service Role (the server issuing access tokens), and Authorization Service Role (the server that determines if the end-user has granted permission, and if not obtains it).
• The Implicit Request (OAuth v13, sec 4.2) is actually a dual-role request. It requires that the authorizing server also issue tokens. I have put this in a separate "dual-role" box in the diagram.
• There may be additional exchanges not shown in the diagram such as logging in the user in order to obtain authorization. These are not shown since they are out of scope of the OAuth specification and should not impact the client (i.e. because authorization is obtained from the user using an external browser).

Lightweight Web Services

There has been growing interest in a group of protocols, namely HTTP, REST, OAuth, and JSON, and how they can support web services. REST and JSON, have been around for a while, but one of the puzzling problems was how to handle authentication in REST especially for non-browser based clients using HTTP. So far the only options have been BASIC authentication or SSL/TLS mutual authentication. So far, neither of which have been adequate (but that's a whole other blog post). However, more recently OAuth2 emerged, and offers some possibilities - especially for access to user controlled resources.

Another reason for interest in these protocols has been the emergence of cloud services and smart phones. Instead of using traditional web services such as WS-*, cloud service providers are opting for lighter weight, more quick to implement approaches that focus on basic HTTP. Smart phones with increasingly popular 'app stores' and their obvious need to be lightweight also figure heavily in this surge in interest OAuth, REST, and JSON. It occurs to me that the common theme here is a drive towards something I'll call "lightweight web services".

Pragmatic cloud proponents argue that WS-* and other specifications like SAML, ID-WSF and so on have all become bloated and unworkable. They are just too much for application developers to handle. Why not get 'lightweight' and use specifications like the PortableContacts spec to transfer personal information? Traditionalists argue about security, privacy and other important aspects. In contrast, lightweight web services focus on transport layer security to do most of its work.

Are proponents trading off security, inter-operability, and flexibility for one-shot-at-a-time lightweight services? Let's take a look at the key technologies/standards that comprise lightweight web services so far and talk about some of the challenges/drivers going forwards...

HTTP is the foundation upon which Lightweight Web Services are built. The founding protocol on the web, HTTP is getting a new look as new application clients begin using HTTP rather than just browsers. Driven by social media and the emergence of smart-phone applications and cloud services, HTTP is now the foundation protocol upon which both browsers and application clients are accessing resources and services on the web.

REST has been around for a while. Before it was popular, early web systems used REST like calls in the 90s (before it was called REST). REST creates simple, easy to document APIs that are more URL centric that seem to be more friendly to developers. The emergence of social network APIs (e.g. the Facebook Graph APIs) are good examples. It seems that many developers would rather trade discovery based code generation (e.g. facilitated by WSDLs) for simple-to-read web site documentation and manual code writing against a simple REST API.

JSON or JavaScript Object Notation is the new XML. It enables simple results from REST based service calls to be returned to clients. From wikipedia...

"It is derived from the JavaScript programming language for representing simple data structures and associative arrays, called objects. Despite its relationship to JavaScript, it is language-independent, with parsers available for most programming languages."

OAuth2, originally a method of delegating authorization to access web services (typically used in social media), OAuth2 is quickly becoming a badly needed authentication/authorization services for non-browser web application clients. While browser authentication had quickly migrated from BASIC Authentication (defined by RFC 2617) to Forms based authentication supported by cookies, OAuth provides new browser-less client applications a needed method to authenticate to web services using the HTTP Authorization header.

Shaping Lightweight Web Services

Lightweight web services have come on so strong proponents have generated "need it yesterday" demand for features that aren't yet defined or standardized. Some features are critical and while others are debatable. At present, there is still no standardized authentication token suitable for non-browser web service clients; no signing and/or encryption of content (other than TLS); no concept of message handling and much more. Are we rushing to re-invent here because of the design to have a single tool for all jobs? Or is this just a case of building out REST services to a supportable, secure level of some sort?

The lightweight web has so far been a loosely associated set of technologies with some interesting design patterns in common. As enterprises are quickly joining the community, it seems important that lightweight web services gain a more formal status with discussion in a new working group.

I invite everyone to help further define what are Lightweight Web Services and to help define a WG to help steer the development of relevant IETF and non-IETF standards that make up lightweight web services.