Author: Phil Hunt
This
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.
Web applications
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!
So,
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).