A 'Robust' Schema Approach for SCIM

This article was originally posted on the Oracle Fusion Blog, Feb 24, 2015.

Last week, I had a question about SCIM's (System for Cross-domain Identity Management) approach to schema. How does the working group recommend handling message validation? Doesn't SCIM have a formal schema?

To be able to answer that question, I realized that the question was about a different style of schema than SCIM supports. The question was assuming that “schema” is defined how XML defines schema as a way to validate documents.

Rather then focus on validation, SCIM’s model for schema is closer to what one would describe as a database schema much like many other identity management directory systems of the past. Yet, SCIM isn't necessarily a new web protocol to access a directory server. It is also for web applications to enable easy provisioning. The SCIM schema model is "behavioural" - it defines the attributes and associated attribute qualities a particular server supports. Do clients need to discover schema? Generally speaking they do not. Let’s take a closer look at schema in general and how SCIM’s approach supports cross-domain schema issues.

Many Definitions of Schema and Many Schema Practices

Looking at the definition in Wikipedia, schema is a very broadly defined term. It can define a software interface, a document format (such as XML Schema), a database, a protocol, or even a template. There is even a new JSON proposal called JSON Schema. This too is very different from XML Schema. It has some elements that describe data objects, but JSON Schema focuses a lot more defining a service and more closely resembles another schema format: WADL.

With XML schema, the bias seems to be about “enforcement” and “validation” of documents or messages. Yet, for many years, the REST/JSON community has been proud of resisting formalizing “schema”. May it just hasn't happened yet. This does appear to be an old debate with two camps claiming the key to interoperability is either strict definition and validation, or strict adherence to flexibility or “robustness” or Jon Postel’s law [from RFC 793]:

“Be conservative in what you do, be liberal in what you accept from others.” 

12 years ago or so, Arran Swartz blogged "Postel's law has no exceptions!". I found Tim Bray’s post from 2004 to be enlightening - "On Postel, Again". So, what is the right approach for SCIM?

The Identity Use Case

How does SCIM balance the "robustness" vs. "verifiability" to achieve inter-operability in a practical and secure sense? Consider that:

There is often a cross-domain governance requirement by client enterprises that information be reasonably accurate and up-to-date across domains.
Because the mix of applications and users in each domain are different, the schema in one domain is will never exactly be the same as in another domain.
Different domains may have different authentication methods and data to support those methods and may even support federated authentication from another domain.
A domain or application that respects privacy tends to keep and use only the information it has a legitimate need for rather than just a standard set of attributes.
An identifier that is unique in one domain may not be unique in another. Each domain may need to generate its own local identifier(s) for a user.
A domain may have value-added attributes that other domains may or may not be interested in.

SCIM’s Approach

SCIM’s approach is to allow a certain amount of “specified" robustness that enables each domain to accept what it needs, while providing some level of assurance that information is exchanging properly. This means that a service provider is free to drop attributes it doesn't care about when being provisioned from another domain, while the client can be assured that the service provider has accepted their provisioning request. Another example, is a simple user-interface requirement where a client retrieves a record, changes an attribute and puts it back. In this case, the SCIM service provider sorts out, whether some attributes are to be ignored because they are read-only, and updates the modifiable attributes. The client is not required to ask what data is modifiable and what isn’t. This isn't a general free-for-all, that the server can do whatever it wants. Instead, the SCIM specifications state how this robust behaviour is to work.

With that said, SCIM still depends largely on compliance with HTTP protocol and the exchange of valid JSON-parsable messages. SCIM does draw the line with regards to the information content “validation” in an abstract sense like XML schema does.
Does the SCIM completely favour simplicity for SCIM clients? Not exactly. Just as a service provider needs to be flexible in what it accepts, so too must SCIM clients when a service provider responds. When a SCIM service provider responds to a client request the client must be prepared to accept some variability in SCIM responses. For example, if a service provider returns a copy of a resource that has been updated, the representation always reflects the final state of the resource on the service provider . It does not reflect back exactly what the client requested. Rather, the intent is that the service provider informs the client about the final state of a resource after a SCIM request is completed.

Is this the right model?

Let’s look at some key identity technologies of the past, their weak points and their strong points:

• X.500 was a series of specifications developed by the ITU in 1988. X.500 had a strict schema model that required enforcement. One of the chief frustrations for X.500 developers (at least for myself) was that while each server had its own schema configuration, clients were expected to alter their requests each time. This became particularly painful if you were trying to code a query filter that would work against multiple server deployments. If you didn’t first “discover” server configuration and adjust your code, your calls were doomed to fail. Searching became infuriating when common attributes weren’t supported by a particular server deployment since the call would be rejected as non-conformant. Any deviation was cause for failure. In my experience X.500 services seemed extremely brittle and difficult to use in practice.
• LDAP, developed by the IETF in 1996, was based on X.500, but loosened things up somewhat. Aside from LDAP being built for TCP/IP, LDAP took the progressive step of simply assuming that if a client specified an undefined attribute in a search filter, that there was no match. This tiny little change meant that developers did not have to adjust code on the fly, but could rather build queries with “or” clauses profiling common server deployments such as Sun Directory Server vs. Microsoft Active Directory and Oracle Directory. Yet, LDAP still carried too many constraints and ended up with some of the brittleness as X.500. In practice, the more applications that integrated with LDAP the less able a deployer was able to change schema over time. Changing schema meant updating clients and doing a lot of staged production testing. In short, LDAP clients still expected LDAP servers to conform to standard profiles.
• In contrast to directory or provisioning protocols, SAML is actually a message format for sending secure assertions. To be successful, SAML had to ensure a lot of optionality that depended on “profile” specifications to clearly define how and when assertions could be used. A core to its success has been clear definition of MUST understand vs. MUST ignore. In many cases, if you don’t understand an assertion value, you are free to ignore it. This opens the door to extensibility. On the other hand, if as a relying party you understand an attribute assertion, then it must conform to its specification (schema).

In our industry, we tend to write security protocols in strict forms in order to assure security. Yet we've often achieved brittleness and lack of usability. Because information relationships around identity and the attributes consumed are constantly variable, history appears to show that identity protocols that have robust features are incrementally more successful. I think SCIM as a REST protocol, moves the ball forward by embracing a specified robust schema model, bringing significant usability features over the traditional use of LDAP.

Post-note: I mentioned in my last blog post that SCIM had reached 'last call'. The working group has felt that this issue is worth more attention and is currently discussing clarifications to the specifications as I have discussed above.

Standards Corner: IETF SCIM Working Group Reaches Consensus

On the Oracle Fusion blog, I blog about the recent SCIM working group consensus, SCIM 2's advantages, and its position relative to LDAP.

Standards Corner: Preventing Pervasive Monitoring

On Wednesday night, I watched NBC’s interview of Edward Snowden. The past year has been tumultuous one in the IT security industry. There has been some amazing revelations about the activities of governments around the world; and, we have had several instances of major security bugs in key security libraries: Apple's ‘gotofail’ bug  the OpenSSL Heartbleed bug, not to mention Java’s zero day bug, and others. Snowden’s information showed the IT industry has been underestimating the need for security, and highlighted a general trend of lax use of TLS and poorly implemented security on the Internet. This did not go unnoticed in the standards community and in particular the IETF.
Last November, the IETF (Internet Engineering Task Force) met in Vancouver Canada, where the issue of “Internet Hardening” was discussed in a plenary session. Presentations were given by Bruce Schneier, Brian Carpenter,  and Stephen Farrell describing the problem, the work done so far, and potential IETF activities to address the problem pervasive monitoring. At the end of the presentation, the IETF called for consensus on the issue. If you know engineers, you know that it takes a while for a large group to arrive at a consensus and this group numbered approximately 3000. When asked if the IETF should respond to pervasive surveillance attacks? There was an overwhelming response for ‘Yes'. When it came to 'No', the room echoed in silence. This was just the first of several consensus questions that were each overwhelmingly in favour of response. This is the equivalent of a unanimous opinion for the IETF.

Since the meeting, the IETF has followed through with the recent publication of a new “best practices” document on Pervasive Monitoring (RFC 7258). This document is extremely sensitive in its approach and separates the politics of monitoring from the technical ones.

Pervasive Monitoring (PM) is widespread (and often covert) surveillance through intrusive gathering of protocol artefacts, including application content, or protocol metadata such as headers. Active or passive wiretaps and traffic analysis, (e.g., correlation, timing or measuring packet sizes), or subverting the cryptographic keys used to secure protocols can also be used as part of pervasive monitoring. PM is distinguished by being indiscriminate and very large scale, rather than by introducing new types of technical compromise.

The IETF community's technical assessment is that PM is an attack on the privacy of Internet users and organisations. The IETF community has expressed strong agreement that PM is an attack that needs to be mitigated where possible, via the design of protocols that make PM significantly more expensive or infeasible. Pervasive monitoring was discussed at the technical plenary of the November 2013 IETF meeting [IETF88Plenary] and then through extensive exchanges on IETF mailing lists. This document records the IETF community's consensus and establishes the technical nature of PM.

The draft goes on to further qualify what it means by “attack”, clarifying that

The term is used here to refer to behavior that subverts the intent of communicating parties without the agreement of those parties. An attack may change the content of the communication, record the content or external characteristics of the communication, or through correlation with other communication events, reveal information the parties did not intend to be revealed. It may also have other effects that similarly subvert the intent of a communicator.

The past year has shown that Internet specification authors need to put more emphasis into information security and integrity. The year also showed that specifications are not good enough. The implementations of security and protocol specifications have to be of high quality and superior testing. I’m proud to say Oracle has been a strong proponent of this, having already established its own secure coding practices.

Cross-posted from Oracle Fusion Blog.

New IETF SCIM drafts - Revision 03 Details

Yesterday, the IETF SCIM (System for Cross Domain Identity Management) Working Group published new draft specification revisions:

• draft-ietf-scim-api-03
• draft-ietf-scim-core-schema-03

This draft was essentially a clean-up of the specification text into IETF format as well as a series of clarifications and fixes that will greatly improve the maturity and interoperability of the SCIM drafts. SCIM has had a number of outstanding issues to resolve and in this draft, we managed to knock off a whole bunch of outstanding issues - 27 in all! More change log details are also available in the appendix of each draft.

Key updates include:

• New attribute characteristics: 
• returned - When are attributes returned in response to queries
• mutability - Are attributes readOnly, immutable, readWrite, or writeOnly
• readOnly - this boolean has been replaced by mutability
• Filters
• A new "not" negation operator added
• A missing ends with (ew) filter was added
• Filters can now handle complex attributes allowing multiple conditions to be applied to the same value in a multi-valued complex attributes. For example:
• filter=userType eq "Employee" and emails[type eq "work" and value co "@example.com"]
• HTTP
• Clarified the response to an HTTP DELETE
• Clarified support for HTTP Redirects
• Clarified impact of attribute mutability on HTTP PUT requests
• General
• Made server root level queries optional
• Updated examples to use '/v2' paths rather than '/v1'
• Added complete JSON Schema representation for Users, Groups, and EnterpriseUser.
• Reformatting of documents to fit normal IETF editorial practice

Thanks to everyone in the working group for their help in getting this one out!

Standards Corner: OAuth WG Client Registration Problem

Update: Cross-Posted on the Oracle Fusion Middleware blog.

This afternoon, the OAuth Working Group will meet at IETF88 in Vancouver to discuss some important topics important to the maturation of OAuth. One of them is the OAuth client registration problem.

OAuth (RFC6749) was initially developed with a simple deployment model where there is only monopoly or singleton cloud instance of a web API (e.g. there is one Facebook, one Google, on LinkedIn, and so on). When the API publisher and API deployer are the same monolithic entity, it easy for developers to contact the provider and register their app to obtain a client_id and credential.

But what happens when the API is for an open source project where there may be 1000s of deployed copies of the API (e.g. such as wordpress).  In these cases, the authors of the API are not the people running the API. In these scenarios, how does the developer obtain a client_id?

An example of an "open deployed" API is OpenID Connect. Connect defines an OAuth protected resource API that can provide personal information about an authenticated user -- in effect creating a potentially common API for potential identity providers like Facebook, Google, Microsoft, Salesforce, or Oracle.  In Oracle's case, Fusion applications will soon have RESTful APIs that are deployed in many different ways in many different environments. How will developers write apps that can work against an openly deployed API with whom the developer can have no prior relationship?

At present, the OAuth Working Group has two proposals two consider:

Dynamic Registration

Dynamic Registration was originally developed for OpenID Connect and UMA. It defines a RESTful API in which a prospective client application with no client_id creates a new client registration record with a service provider and is issued a client_id and credential along with a registration token that can be used to update registration over time.

As proof of success, the OIDC community has done substantial implementation of this spec and feels committed to its use.  Why not approve?

Well, the answer is that some of us had some concerns, namely:

1. Recognizing instances of software - dynamic registration treats all clients as unique. It has no defined way to recognize that multiple copies of the same client are being registered other then assuming if the registration parameters are similar it might be the same client.
2. Versioning and Policy Approval of open APIs and clients - many service providers have to worry about change management. They expect to have approval cycles that approve versions of server and client software for use in their environment.  In some cases approval might be wide open, but in many cases, approval might be down to the specific class of software and version.
3. Registration updates - when does a client actually need to update its registration?  Shouldn't it be never?  Is there some characteristic of deployed code that would cause it to change?
4. Options lead to complexity - because each client is treated as unique, it becomes unclear how the clients and servers will agree on what credentials forms are acceptable and what OAuth features are allowed and disallowed.  Yet the reality is, developers will write their application to work in a limited number of ways. They can't implement all the permutations and combinations that potential service providers might choose.
5. Stateful registration - if the primary motivation for registration is to obtain a client_id and credential, why can't this be done in a stateless fashion using assertions?
6. Denial of service - With so much stateful registration and the need for multiple tokens to be issued, will this not lead to a denial of service attack / risk of resource depletion?  At the very least, because of the information gathered, it would difficult for service providers to clean up "failed" registrations and determine active from inactive or false clients.
7. There has yet to be much wide-scale "production" use of dynamic registration other than in small closed communities.

Client Association

A second proposal, Client Association, has been put forward by Tony Nadalin of Microsoft and myself. We took at look at existing use patterns to come up with a new proposal. At the Berlin meeting, we considered how WS-STS systems work.  More recently, I took a review of how mobile messaging clients work. I looked at how Apple, Google, and Microsoft each handle registration with APNS, GCM, and WNS, and a similar pattern emerges.  This pattern is to use an existing credential (mutual TLS auth), or client bearer assertion and swap for a device specific bearer assertion.

In the client association proposal, the developer's registration with the API publisher is handled by having the developer register with an API publisher (as opposed to the party deploying the API) and obtaining a software "statement". Or, if there is no "publisher" that can sign a statement, the developer may include their own self-asserted software statement.

A software statement is a special type of assertion that serves to lock application registration profile information in a signed assertion. The statement is included with the client application and can then be used by the client to swap for an instance specific client assertion as defined by section 4.2 of the OAuth Assertion draft and profiled in the Client Association draft. The software statement provides a way for service provider to recognize and configure policy to approve classes of software clients, and simplifies the actual registration to a simple assertion swap. Because the registration is an assertion swap, registration is no longer "stateful" - meaning the service provider does not need to store any information to support the client (unless it wants to).

Has this been implemented yet? Not directly. We've only delivered draft 00 as an alternate way of solving the problem using well-known patterns whose security characteristics and scale characteristics are well understood.

Dynamic Take II

At roughly the same time that Client Association and Software Statement were published, the authors of Dynamic Registration published a "split" version of the Dynamic Registration (draft-richer-oauth-dyn-reg-core and draft-richer-oauth-dyn-reg-management). While some of the concerns above are addressed, some differences remain. Registration is now a simple POST request. However it defines a new method for issuing client tokens where as Client Association uses RFC6749's existing extension point. The concern here is whether future client access token formats would be addressed properly.  Finally, Dyn-reg-core does not yet support software statements.

Conclusion

The WG has some interesting discussion to bring this back to a single set of specifications. Dynamic Registration has significant implementation, but Client Association could be a much improved way to simplify implementation of the overall OpenID Connect specification and improve adoption. In fairness, the existing editors have already come a long way. Yet there are those with significant investment in the current draft. There are many that have expressed they don't care. They just want a standard. There is lots of pressure on the working group to reach consensus quickly.

And that folks is how the sausage is made.

Note:  John Bradley and Justin Richer recently published draft-bradley-stateless-oauth-client-00 which on first look are getting closer. Some of the details seem less well defined, but the same could be said of client-assoc and software-statement. I hope we can merge these specs this week.

New Draft for Enabling OAuth2 To Be Used for Authentication

In my last blog post, I discussed the issue of OAuth2 and authentication:  Simple Authentication for OAuth 2? What is the Right Approach? As promised, I submitted a draft to the IETF for discussion in Berlin at the beginning of the month. While the working group didn't get a lot of time in the meeting to talk about the authentication issue (it wasn't formally on the charter), the submission did receive quite a bit of discussion in the hallways and on the IETF OAuth WG mailing list -- some of which I have already addressed in my last blog post.

Since the Berlin meeting, I have reviewed the feedback and have submitted an update. Draft 01 is now aligned to be compatible with OpenID Connect. In other words:

• If you are a web  developer, and the only problem you want to solve today is "how can I use OAuth to authenticate my users?", the new User Authentication and Consent for Clients draft is intended to solve just that problem. 
• But, if you decide you want to add an attribute provider (user profile) services to your requirements, you can upgrade to the OpenID Connect drafts as an extension to authentication without impacting existing code.

The new draft also allows clients to request a minimum Level of Assurance (per NIST-800-63 or ISO 29115) for the authentication -- a useful feature if the clients would like the service provider to do a higher assurance authentication (such as a multi-factor or biometric) than it might otherwise normally perform.

My thanks to Tony Nadalin and Mike Jones of Microsoft for their contributions to this draft.

Simple Authentication for OAuth 2? What is the Right Approach?

Over a year ago, several people, including myself, raised concerns about using OAuth (RFC6749) for authentication. By this I mean, that application developers are using OAuth enabled service providers as a way to authenticate their users (using Google, Facebook, LinkedIn, Twitter, or another major provider). They do this because they want to eliminate friction by forcing customers to create yet-another-user-id-and-password. John Bradley blogged about the problem, as did Vittorio Bertocci. Vittorio pointed out that authentication using OAuth is possible – it is just that authentication isn't formalized; authentication happens as a side-effect of authorizing a client to access a resource.

I agree with Vittorio, to fix this a simple specification is needed where by a service provider's authorization server shares with the client application (the one that wants to authenticate users), the user login information it knows about the user such as:

• Which user-id was authenticated?
• When did they login?
• How long is the login assertion good for?
• A possible (preferably directed) URI for User profile information?
• And, potentially to what assertion level were they authenticated? 

Many, including myself, suggested that the solution to the problem is to use OpenID Connect (OIDC).  OIDC solves the authentication standardization problem and further, it specifies a way to gain access to user profile information. In a sense, it turns an OAuth2 Service Provider into what we used to call an Identity Provider or IDP in many federation systems.

Despite these strong recommendations, I continue to see implementations and customer requests that require doing exactly what we warned was not standardized and not a good practice. Part of the complaint is that service providers have been slow to adopt except for a notable exceptions (namely Google). I also heard from last weeks CIS Nape conference that SFDC is planning to include OIDC in its platform.

I have asked many of the OIDF membership about this, and they claim there is a minimum profile. Yet, the "minimum" profile exists for the clients, not for the service providers. In a conversation only yesterday with Brian Campbell of PingIdentity (some tweets removed for clarity), we quickly got to the crux of the issue:

@leastprivilege @independentid @paulmadsen @vibronet there already is. You just have to find it in the mountain of specs.
— Brian Campbell (@__b_c) July 17, 2013

@leastprivilege @independentid @paulmadsen @vibronet response_type=id_token and scope=openid+whatever
— Brian Campbell (@__b_c) July 17, 2013

@__b_c @leastprivilege @paulmadsen @vibronet right but as can't implement just that flow.
— Phil Hunt (@independentid) July 17, 2013

@independentid @leastprivilege @paulmadsen @vibronet they could if ignore MTI, which will happen I'm sure
— Brian Campbell (@__b_c) July 17, 2013

Brian went on to point out some other important concerns, such as will another spec cause more confusion than it prevents. He is right.

So, while it is possible for OIDC to do authentication only, it wasn't intended for this purpose. Further, OIDC requires that the scope parameter which is intended to refer to the resource being requested, is compounded with an additional parameter "openid".

OIDC has many features, including discovery, that are incredibly useful.  Loosely speaking it turns OAuth2 Service Providers into the older federation Identity Provider model. It imagines an ecosystem of OIDC providers where profile information can be obtained in a standard way. Yet, many client developers aren't interested in user profile attributes – they just want to eliminate the need for users to create yet another user-id and password. They just want the login session information and the ability to force re-authentication.

From the service provider's (e.g. the social networks) perspective, there are also concerns. They know that client application developers are using OAuth2 to leverage their authentication services. Yet, their business priorities aren't such that the service providers want to consider becoming a standard compliant provider of user profile information. What service providers would like is a way to support standardized authentication, without standardizing their own RESTful profile APIs or adding another API. Implementing the OIDC Profile API may be in their future, but they aren't ready to commit today.

One of the problems we have in the standards industry is we tend to want mark the number of "implementations" as a sign of success. We tend to ignore those who are not implementing or are not putting implementations into production. These silent participants often do not voice their concerns.

It's with these concerns, that I am writing a proposal to respond to the authenticate only need. The plan is to make it short and easy to implement. I plan to submit it when the next IETF submission window opens on July 29. Yet I hesitate to submit it. Should it go to the IETF?  After, all, that is where the security concern lies. Or is it something the OIDC designers should look at?  I'd like to open some discussion on this. What should be done about supporting authentication directly within OAuth2 as described above? Where should that work be take place?

If anyone is interested, please make a comment or send me an email. I'd like to get your input, concerns, and support.

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.

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.

OAuth: New Chain Grant Type

I posted a new Internet Draft, the "Chain" grant draft [now expired] today for the consideration of the OAuth2 working group. The specification defines a new grant type that enables an OAuth protected service to in turn act as an OAuth client to another OAuth protected service. The grant type allows the first server to exchange the current oauth access token for a new token valid on the target service. This grant type makes it possible for multiple connected services to interact in a message bus or chain.

Introduction

The use case for this proposal springs from inter-service communication or messaging scenarios. Currently many applications use SOAP based services, such as in WS-SecureConversation which have ways to handle authorization and identity propagation between service end-points.

Now, that REST is becoming popular, the question arises as to how to properly propagate identity without heavier SOAP messages. Since REST relies solely on HTTP, how do you pass identity assertions?

Aside: Note that I'm not saying REST is better or worse than SOAP, merely that REST needs a way to propagate identity just like SOAP.

OAuth seems to have some answers to this question by allowing services to use tokens to access protected resources. It also allows for SAML Assertions to be exchanged for OAuth bearer tokens. But what happens if multiple services are chained together in a bus? What happens when the next pairwise exchange that needs to occurs? The original user and/or SAML bearer assertion is no longer available.

As currently specified, the OAuth framework handles only one client-service pair relationship, it cannot handle multiple 'chained' service calls.

Let's take a look at the following scenario:

In the above picture, we see a user, accessing a web site that offers banking statement aggregation. The user, having previously authenticated to "Bank Svc" (the Bank), indicates to the Aggregator that they would like to include information from the Bank. The Aggregator site accesses the token service for the Bank. The Bank Auth/Token Service, takes into account the user context (UC), the client credentials (C1C), and a requested scope and if successful, returns an access token (AT1).

Note: for those paying attention, there is often a 3-legged flow involving the end-user, but I am simplifying for brevity.

Once the access token AT1 is returned, the Aggregator is free to access the Bank as authorized by the user and the Bank's Authorization Service.

So far, we have demonstrated a successful capability to access a REST based service using a token that embodies both a user context, a client context, and a scope. But what happens, as is common in messaging systems, if the Bank in turn wants to access another service provider (e.g. Trader). Since there is no longer any direct user involvement, can the Bank obtain an access token for the Trader service?

The Chain Grant Profile

In this scenario, the Bank is acting under some high level of trust with the Trader service. E.g. the Bank owns the Trader service. In this case, the Trader is willing to trust the Bank application to indicate that it has the authorization to work on behalf of a user. In this flow, the Bank application contacts the authorization service for the Trader, and requests an access token using a new grant_type called "chain". In the "chain" grant type, instead of passing a user context, or an authorization code, the client instead passes an access token received from the Aggregator.

In this flow, the Bank provides its own client context (C2C) for its application (now acting as an OAuth client), and the access token (AT1) that it received from the aggregator is included in a POST to the Trader authorization/token service. This allows the Trader's authorization/token service to either parse AT1 or contact the Bank's authorization service for more information. In this case, AT1 embodies both the original user context (UC) plus the Aggregator (C1C). After successful processing, the Trader authorization service issues AT2, which combines C2C and AT1 as shown below.

In multi-node scenarios, this process could be repeated indefinitely leaving a traceable security path to the originating user along a pair-wise trust path between services.

Token Issues

One thing the draft specification does not address is how the trader's OAuth authorization/token service is able to parse the bank's authorization token (AT1). This likely will be handled in upcoming OAuth token specifications standardizing formats and claims included in tokens.

As always...comments and feedback are appreciated.

**Update**
Unfortunately due to IETF policy, the chain draft has now expired. If anyone is still interested in seeing the draft, please let me know by commenting.

Does OAuth Have Legs?

Some folks have been asking, "what's all this stuff about legs in OAuth?" and "I don't understand the difference between 1, 2, and 3 legged OAuth?"

I have put together a flow-chart to try and show, from a client app perspective, what constitutes a 1, 2, or 3 legged authorization (click on image to enlarge).

Basically the rule of thumb is, each time you make a request response within the OAuth protocol, that is one leg. Note that in the diagram the [4.xx] numbers represent the relevant paragraph from the draft 13 specification.

[Update: Corrected diagram decision box,authorization box]

OAuth: Emergence of Network Centric Identity

For 5 or more years now, there has been a push by many in the identity management industry to rally around the idea of user-centric identity. Why not give users complete control over information being shared between web sites? From a web service provider it should make sense. Why retain data if it could be provided easily by the user? It made a lot of sense. Thus user-centric identity was born. There was a lot of interest, but user-centricity has remained esoteric and hasn't really taken off...

At the recent IIW 11 meeting, Dick Hardt led a discussion on the decline of user-centric identity. The conclusion was predictable. Lack of big players with significant financial incentives, too many negative financial incentives, and finally launching with immature technology not able to meet security, functionality or usability requirements. But I'm not so sure that fully explains the issue.

Both InfoCards and OpenID had some great new thinking. They both evolved around the idea of either a single user-agent or a single identity provider. User-control was key to both offerings putting the user at the centre. Neither approach was accepted by the market except in limited ways. I think that a big part of the problem was a design that focuses on a single point of control or distribution - a centricity. Both of these approaches ended up creating functional "silos" that limit the ability to embrace the Internet. Though with good intent, I think they fell into the same trap that applications fall into when they manage their own security and identity management. The application works, but it is a limited use silo with potential elevated risk and management costs. Further as application silos get big, the pressure to bridge the silos has increased. As evidence of this look at social networking application today and the Google/Facebook API sharing debate.

A new option has emerged that may serve to rejuvenate user-centric protocols by adding a new capability - open authorization or OAuth. OAuth enables applications and service providers to access data with the permission of users. Instead of trying to solve data transfer and user authentication at the same time, the requirements are separated. Yes, data can still be transferred as part of authentication, but now, many more use cases are handled without needing the users to be present. Instead of just applying to typical data points about users (first name, last name, etc), OAuth enables access to services that are controlled by users. Much more powerful. OAuth in combination with OpenID, SAML, or InfoCards enables new network cases like photo printing services, game boxes, cell-phone applications.

OAuth brings forward the notion that too me is a multi-agent or network-centric approach that enables controlled sharing of personal information by parties with some level of independence. For example, a user can give a game-box a one-time token that enables it to access his online game profile automatically. No longer does the user need to perform complex authentication in a device that doesn't have a keyboard. Instead, the user enables the device to act as an "agent" on his or her behalf. In fact there are many use-cases now envisioned (see the Zeltsan use cases draft).

OAuth enables applications to have independent relationships with data providers by using tokens as proof they are working on a user's behalf. With OAuth, applications access each other's services while allowing access control systems to handle authentication and authorization and more importantly, as I outlined in my last blog post, it allows the authorization system to distinguish between an OAuth client and a user. The OAuth concept is important because it enables network-centric identity.

I am glossing over a lot of issues (like the security of tokens, which I'll address in later posts), but the essential point, is that OAuth enables users to authorize applications, devices, or web services to perform actions on their behalf. This can be done with the user present (browser based), and with the user absent from ongoing exchanges of information. This is done with tokens (bearer, holder-of-key, etc). The OAuth 2.0 draft describe several scenarios in which users can enable a "client" application to obtain an access token to access user-controlled information on their behalf. Example, a service like Mint.com can aggregate financial information from investment services or banking service; a photo printing service can obtain photos from flickr for 24 hours to allow it to print a set of photos. A Twitter client on an smart phone can have a long-lived token to allow a user to easily post and read updates from services like twitter.

In short, network-centricity allows users to form a web of relationships between service clients and service providers. In this approach, emphasis on private 'silos' are minimized and authorized shared access to authoritative information is emphasized. Because applications have easy access to authorized, quality data, the need to copy and retain information is reduced as network services are embraced and adoption is more likely.

IIW OAUTH Enterprise BOF: Session Management

Continuing the summary of the OAuth Enterprise BOF, I want to call attention to a discussion on session management and OAuth. While we didn't start off talking about it, we soon came to realize a key potential benefit–session management.

The group was looking at the issue of UI complexity and features like "Share" buttons–a user clicks on a "Share" button and passes a token on to friends and family members to share content such as photos. Is this an appropriate use of OAuth? Are there complex token handling and UI issues to resolve?

The conversation took a rather interesting turn when Chuck Mortimore (Salesforce.com) commented that there are some technical SSO and session management issues to be concerned about. Bob Blakley (Gartner) responded by saying, OAuth is being used to establish CORBA-like "associations" to handle the absence of session management. The idea being that OAuth enables a different form of re-authentication for token holders than would normally happen for a typical user.

Bob asked: Are we overloading session management on to OAuth?

Because OAuth gives applications an idea of a separate identity from the user, access control systems can make different access control decisions about an authorized agent (token holder) distinct from the user that authorized agent (token holder). The implication is that a OAuth agent application could have a different session life than the end user. In contrast to OpenID and other SSO approaches, activity can take place without the presence of the user.

In my personal opinion, whether intended or not, enabling authorized agent session management independent of user session management is OAuth's most powerful feature! It allows for agent specific access policies and independent session lifetimes that will work in far more use-case scenarios then currently offered in current Web SSO protocols where the focus is on solving user-present in the browser scenarios.

But there is some caution here. Bob quite correctly pointed out that the fact that people are doing this without it being intentionally designed may be good reason to be worried. The group agreed that though implementations seem to be handling it well, there is good motivation to work further on some good guidance on refresh and re-authentication issues within OAuth.

IIW OAuth Enterprise BOF: Scenarios Discussion

As I blogged earlier, it seems like it is time explore the idea of enterprise use of OAuth. Many folks chimed in via email and blog comments that they were interested in a group discussion. So, at IIW 11, folks from Gartner, Google, HP, Paypal, PingIdentity, Salesforce.com, VMWare, Oracle, and others got together for a series of sessions on OAuth at IIW.

Please note, the opinions here are my own and represent my impression of the discussion that took place. Hopefully I have not misrepresented anyones view here, if I have, please let me know. This post is not meant to represent minutes for the discussion but rather a summary. Minutes can be obtained here.

Nishant Kaushik (Oracle) started off by talking about the case of a personal banking/financial services aggregator site and the quandary that services like it present to the financial service industry and their customers. While a great idea, these types of sites currently require customers to provide their banking user ids and passwords to access financial information. Obviously there is a lot of risk for potential customers to share this information. But, it seems the biggest risk is that there is no way to differentiate the customer from the aggregator. The aggregator accesses banking information with the same rights as the customer. This forces the customer to take an undue risk and likely compromises the aggregators ability to gather a broad set of customers. For banks being accessed by the aggregator, the sharing of uid/passwords by their customers also brings a certain amount of risk.

OAuth provides a new way to handle this scenario that would enable these types of aggregators to avoid using private user-ids and passwords, and instead obtain OAuth "authorization" tokens with the permission of their customers, to access financial service information. The advantage? Well, for one, no re-use of passwords. But for Banks, a key advantage. The ability to to differentiate usage capabilities of individual 3rd-party applications as distinct from and approved by their customers.

Patrick Harding (PingIdentity) covered another scenario that actually may be even more familiar. Patrick described how web companies (such as banks, or retailers) often offer 3rd-party services to their customers. To-date, that has been done successfully using web single-sign-on (SSO) technology. When a web retailer hands off to a 3rd-party, a SSO token is used to transfer session information. However, that need is evolving to where the 3rd-party service provider needs to have access to services from the retailer on some ongoing basis, or beyond the current session with the user. OAuth presents an opportunity for the 3rd party site to obtain access rights, with the customer permission, to access retailer information about the customer on an as-needed basis.

Patrick also pointed out that for the enterprise, the OAuth token avoids having to give broad access to 3rd parties systems. Enterprises will prefer a delegated access model as could be offered with OAuth. While eliminating the uid/password anti-pattern is key, differentiated access management of 3rd parties acting on behalf of users is an even more important benefit of OAuth.

There was a general discussion that there are many cases where OAuth tokens are a useful way to obtain user consent for sharing of information between service providers (organizations). As usual, Bob Blakley (Gartner) made the point, more important here is the idea that the holders of valuable data, will retain their ability to ascent to particular clients service providers access data on behalf of users. This makes natural sense, since the above scenarios demonstrate the need by enterprises to be able to have access policy that differentiates capabilities of users/customers from those of 3rd party service providers acting on their behalf.

There was a lot more discussion that took place. Some of it very detailed, some on topics which I plan to blog on shortly. Stay tuned!

Enterprise OAUTH and ChangeNotify at IIW #11

For those considering attending the Internet Identity Workshop 11 in Mountain View, California, here a couple of session proposals that may be of interest:

• Enterprise OAuth BOF - this is looking like it may be an all day session on Wednesday as lot of topics have already been proposed (email me or comment if you want the list). If you are interested in adding topics, please let me know by commenting below.
• ChangeNotify - an introduction and update on the SAML ChangeNotify specification. This proposal has proved to be an interesting way to handle updates between federated providers particularly for cloud services. We'll discuss why it is different and what the advantages are. While ChangeNotify is currently profiled for SAML, there has been a proposal to develop a notification protocol variant that is non-SAML specific. Your participation and input is greatly appreciated! If you have a preference for a specific day on this, let me know!

See you there!

The Case for OAuth and Enterprise Software

I've been spending some time lately on OAuth and exploring its applicability for enterprise software and the cloud. To date, OAuth's use cases have been focused primarily on social networking. Yet customers are asking, will OAuth be useful? The answer, I believe, is YES!

But first, some background for those new to OAuth...

What is OAuth?

OAuth is an open authorization protocol used to allow 3rd-party desktop, mobile phone and web applications to access Internet services that are often accessed with a user-id and password or federated sign-on such as OpenID or SAML. The objective, is to get rid of the anti-pattern of asking users to provide their user-id and password to obtain data from a web site or service.

Why should web site owners care about OAuth?

To answer this, I'll suggest an excellent article by Eric Sachs, Product Manager, Google Security, on OAuth Practices. Eric lays out the case for why social networking apps need OAuth. Eric answers key questions like:

• What does [your company] get out of [OAuth]?
• What if startups are already pulling data from [your company] without [your] permission?
• What can [your] company do?
• What data should we make available via OAuth?
• and many more.

How did OAuth Originate?

According to Dave Recordon, OAuth was derived from several existing API authorization protocols originating from AOL, Flickr, Google, Microsft, and Yahoo!. Paraphrasing Dave, "The thinking was that building a unified approach to authorization it would reduce burden of implementing any one of these protocols and provide third party applications a more convenient and secure was to access user controlled data."

Work moved quickly and the 1.0 implementation was very successful. But, there was a problem. On the way to a formal IETF specification, a bug appeared that resulted in 1.0a revised specification to fix a threat. Eran Hammer-Lahav tells the story here about the "session fixation attack". The problem was corrected and was subsequently included in the IETF OAuth 1.0 draft (RFC 5849).

OAuth 2.0 - Under Construction

After OAuth 1.0, a new specification emerged called "Simple OAuth" or WRAP. The objective was to take the OAuth concept and apply it to a broader set of use cases. Very quickly both the 1.1 OAuth work and the WRAP work were merged into a combined draft as the IETF OAuth Working Group achieved agreement to work on a new 2.0 protocol. This work introduces many new use cases and protocol flows and is suggestive of a highly useful solution in a broad range of use cases.

OAuth and the Traditional Enterprise Software Market

At the start of this post, I mentioned that YES, I feel that OAuth will be important to the Enterprise Software Market. As with large social media sites, vendors of large enterprise software systems such as ERP, CRM, HCM, also have a community of third-party tools developers that want to integrate with enterprise applications.

At Oracle, I have already noticed the emergence of iPhone and Blackberry apps and the related discussions around the use of passwords in mobile apps. The password anti-pattern is everywhere in enterprise systems and it has to go! Mobile applications are just the first example of enterprise software demanding an OAuth type solution.

Emergence of Cloud Services

As you'll no-doubt have heard, Oracle made a number of announcements recently regarding supporting cloud computing. This has profound implications. As we talk about enterprise software deployed in the cloud, perceptions of risk change because in part, corporate firewalls can't be counted on as the first line of defence. Because the Cloud computing paradigm will put enterprise computing "in the cloud", the demand for 3rd-party application integration with enterprise systems is set to balloon!

Oracle and its competitors now have the same requirements faced earlier by the social networking communities supported by AOL, Flickr, Google, LinkedIn, Twitter, and Yahoo that pitched in their early support for OAuth.

Perfect Storm

The combination of steadily increasing enterprise security requirements, the evolution of user-controlled content, and the emergence of cloud computing represent a perfect storm of demand for OAuth in enterprise software. If OAuth 2 is successful, enterprise support won't be far behind - if not leading the way.

Next Steps

The Oracle Identity Standards team is beginning a phase of increased engagement in the IETF OAuth Workgroup to review and expand coverage of the spec to meet enterprise requirements. The OAuth 2.0 draft specification is definitely headed in the right direction. It seems clear it is time to help support the development of OAuth 2.

In light of this, I am recommending an OAuth Enterprise BOF meeting at the next IIW in Mountain View, California, on November 2-4. The objective will be to talk about whether there are any use-case/technical requirements that need to be addressed in the current 2.0 planned specification. Enterprise feedback needs to happen quickly if we are to make the 2.0 specification timeline.

Here's hoping you can make it!

Phil

Pulling For Change

This past spring, several organizations began a discussion on the SAML TC about the possibility of adding subject and attribute management functions to SAML. The proposal was the subject of a some debate. Why was this an important requirement? Why not use SPML or other protocols? After considering several possibilities, a new concept emerged called "Change Notify" which suggests converting identity management operations from state-based explicit adds/modifies/deletes to pull based operations that could enable identity changes to be exchanged between partners in federated scenarios.

Before we talk about the new proposal, let's cover some of the discussion about why the state-basedm, push solutions wouldn't work.

Yes, Updates Happen

There was agreement that there are lots of scenarios where updates of some kind are needed. A web retailer, after completing a sales process with a user, might want to have some method to update a shipping address at a customer's IDP after the user indicated the address was out-of-date. An Identity Provider might want to notify relying parties with retained data of important changes. An enterprise might want to notify a cloud service provider that the employee has changed roles or has been retired.

Some of you may be asking, but why is this an issue? Shouldn't applications avoid retaining data from Identity Providers? There is often a need for some data to be retained. Applications may need to retain data because of complexity with other integrated systems. It might be needed for offline processing (where backend calls to the identity provider aren't practical or possible). Consider that business applications often generate application specific data that is tied to individuals (purchase history, reputation, to name a few) and is not associate with data originating at an identity provider. Because of this, even in a so-called "zero data" scenario where applications retain no federated data about users, there is still one key update that cloud applications often need: the de-provisioning update. How does an enterprise, acting as an Identity Provider, notify a web service provider that an employee has retired?

Why Traditional IDM Protocols Won't Work

We realized that traditional "push" approaches of adds/modifies/deletes would probably not function well because traditional enterprise approaches assume an updater has full knowledge of the target identity to be updated. Yet, by design, federated systems work at arms reach. Identity Providers have many relying parties and thus support many federated relationships.

Conversely a service provider can have many organizations, each with their own identity provider as clients. Or, even more complex, individuals may have a relationship with a service provider having nothing to do with their employer. Cell phones come to mind as an industry where there is often both an employee and personal relationship with a telephone company. Because of this, the state of an personal information and relationships in a federated system are not assured, and thus they cannot be assumed to be fact. Traditional "state" based approaches will run into issues such as adds of entries that already exist, or modify operations failing because an entity no longer exists.

Are we saying that state based protocols aren't useful? Quite the contrary. State-based protocols work very well inside the enterprise environments. They can also work in some federated scenarios where there is tight agreement between business partners. But assumptions about "state" begin to break down when you consider that federated business entities are working independently of each other.

Pulling For Change

It was interesting timing that Bob Blakley, Gerry Gebel, and my colleague Nishant Kaushik blogged recently on Pull vs. Push. While our requirements were focused on how to share ongoing updates to federated entities, there seems to be some natural alignment in thinking going on. For it was a "pull" oriented solution proposed to the SAML TC in July just prior to the Catalyst conference. The Change Notify specification allows one party to notify another about a change without actually pushing raw data. Rather then "push" a transaction, the initiating party simply pushes a notification. The receiver can then simply "pull" data using a protocol of its choosing. A few important observations:

1. There is no rigid assumption of state between parties
2. The modify operation is converted into a simple "read" by the pulling entity.
3. The change notification is relatively lightweight and doesn't need to carry data values other then references to the entity being modified.
4. The technique can be applied to almost any federation protocol.
5. There is flexibility to switch protocols.

The initial Change Notify proposal can be found here.

Since publication to the SAML TC there has been some broader interest in building a lighter weight profile supporting a simple HTTP binding, REST, or JSON. While SAML adds a lot of messaging security, there is argument to be made that Change Notify can run in lighter weight implementations. These comments seem reasonable. I'm looking for your thoughts on how we can broaden this proposal in a multi-protocol way. Would people like to discuss the proposal at the next west coast IIW? Feel free to comment!