2012: No Time To REST For The Holidays
By Tanu Sood on Jan 08, 2013
Author: Phil Hunt
past year has been one of the biggest years of change I've seen in a while. It
started off with the expected priority of delivering and using cloud based
services at the top of everyone's mind. However, it soon became apparent that
the usual way of delivering services (e.g. ones based on SOAP) was not
what was going to make that happen. It is now apparent that cloud hosted
services will be largely be based on REST and JSON. A monumental change in
service architecture being driven by the market…
Emergence of REST-based Cloud
Today's REST services are incredibly lightweight with the coupling of HTTP and JSON rather then on XML and SOAP. The powerful combination REST and JSON are seen as light weight, and particularly easy-to-use for the expanding universe of mobile devices (iPads, and smart phones) to support. Still, if you think this REST is flash in the pan, check out the growth in REST has had over the past couple of years. See Craig Burton's post on the API Economy here: http://prezi.com/pys_d3ysqbmb/api-economy-update/
The impact on service architecture will be quite substantial. REST changes how services architectures are delivered in many ways. Instead of being process oriented as often seen in SOAP based services, REST services are all "resource" oriented (set independentid's password to 'x'). Unlike SOAP, REST uses simple object state representations (resources) accessible via URLs. So, for example, a "ChangePassword" service now becomes a simple "set password attribute on resource abc123". While this is simple, for the client application, the implications are significant. What of password policy, what of workflow and validation? Somewhere behind that simple "set password attribute" command a lot still has to happen.
Fat Apps are now Phat!
Another major trend is to supplement browser based applications with fat applications running on desktops and mobile phones (remember "fat apps" in the 80s and 90s?). It is with some irony that Web 3 is not about the browser at all, but rather it is about the interconnection of applications (e.g. Facebook, Flickr) that are identity centric.
in the cloud are also acting as a kind of super-connected REST-based applications,
providing aggregation and interconnection of services owned by users. Starting
from social networks, new networks are forming such as loyalty networks (credit
card, air, banking), travel networks, and even financial networks are now
emerging linking personal data to provide value-added services.
Web 3 Drives Forward A New Authorization Model: OAuth2
With the emergence of Web 3 applications, there has been a corresponding need for many applications to ask users for their user-ids and passwords so that they can access user controlled resources from other companies. As more inter-connectial social network services (e.g. Google Docs, Flickr, Facebook, Twitter) started to emerge, it became clear over the past few years that the "password anti-pattern" would have to be eliminated. As a result, a new web authorization/delegation protocol emerged called OAuth2 (now standardized a IETF RFC 6749). OAuth2 provides a way to cleanly separate user-authentication, from user-authorization, allowing client applications to use authorization tokens to access web resources on a user's behalf.
OAuth2 has gone through quite a colorful evolution within the IETF. But I have to say a mark of its importance, has been the extremely broad collaborative development from participants that are web service providers as well as middleware vendors. As the protocol matured through extensive implementation, I had the honor of co-authoring the security considerations and producing an OAuth2 Threat Model document that will serve to give both implementers and deployers of OAuth2 an incredible amount of detail on how to secure and configure this protocol in the many different authorization scenarios it can support.
Is SAML Dead or Just Starting?
Craig Burton made headlines last summer with his declaration that "SAML is dead" at the Cloud Identity Summit in July (http://blogs.kuppingercole.com/kearns/2012/07/31/the-death-and-life-of-a-protocol/ ). Was he being controversial? Sure. But his point of view comes from the fact that while SAML is grows slowly along with SOAP, REST by contrast is taking off for the moon!
do I agree REST and OAuth eliminate the need for SAML? The answer is no.
In fact the opposite. While OAuth2 issues authorization tokens, OAuth2 still
depends on traditional federation, web SSO, and other classic methods of
authentication to take place before OAuth2 can issue tokens. Not only
is SAML needed to authenticate federated users, SAML is now also being
used to authenticate the new client applications. I blogged on this very topic
early on in 2011: http://www.independentid.com/2011/04/oauth-does-it-replace-federation.html
Provisioning to the Cloud
The final big development last year, was the emergence of SCIM for cloud provisioning. With all these new
business cloud providers emerging, it became critical to find a way to
easily provision 10s of thousands of users quickly. When you contract
for services with a cloud service provider, SCIM's goal is to help you get
your employees and customers provisioned.
Looking Forward - The Emergence of the Identity Cloud and the Interop language
Whether Oracle, Cisco, Facebook, Google, Microsoft, SFDC, or Yahoo, one thing that all service providers seem to be developing is some notion of a cloud directory (aka Graph API). Cloud directories are somewhat different than classic enterprise LDAP Directory in that they are currently custom built to support key major corporate applications first, and then evolve to support mergers of other acquired services over time. Some of these directories are based on SQL databases, some based on NOSQL, some based on other custom built data stores. While all support REST APIs, currently no two cloud directories support a standard access protocol at this time. Two possible candidates for RESTful standardization at this time are: SCIM and OpenID Connect. The choice of SCIM seems like a natural one as it supports create, read, update operations much like LDAP. While OpenID Connect gives access to user-authentication and session management data, it seems its identity profile duplicates the features found in SCIM. How this plays out depends on how much data applications will choose to store in cloud directories.
Yet to be sorted out in 2013 is what will be the key protocols and standards around cloud directories. Will they be built on the old LDAP model? Or will they support the more expressive SCIM schema? In the universe of inter-connected RESTful services, the role of standardized, interoperable schema is vital. Who needs to inter-operate with whom? Does a service provider adapt to each client, or do clients adapt to service providers. Or, like air traffic control systems that all standardized on English, will cloud directories adopt one standard schema that every one maps to?
About the Writer:
Phil Hunt joined Oracle as part of the November 2005 acquisition of OctetString Inc. where he headed software development for what is now Oracle Virtual Directory. Since joining Oracle, Phil works as CMTS in the Identity Standards group at Oracle where he developed the Kantara Identify Governance Framework and provided significant input to JSR 351. Phil participates in several standards development organizations such as IETF and OASIS working on federation, authorization (OAuth), and provisioning (SCIM) standards. Phil blogs at www.independentid.com and is active on Twitter (@independentid).