Identity & Access Management: Give Me a REST

Give me a REST (or two weeks stay in a villa in Portugal if you're asking...).  RESTful architectures have been the general buzz of websites for the last few years.  The simplicity, scalability and statelessness of this approach to client-server communications has been adopted by many of the top social sites such as Twitter and Facebook.  Why?  Well, in their specific cases, developer adoption is a huge priority.  Getting as many Twitter clients or Facebook apps released, increases the overall attractiveness of those services and in a world where website and service competition is as high as ever, that is a key position to sustain.


Why REST?

Cute picture of RESTing lion [1]
The evolution and move to REST is quite a clear one from a benefits and adoption perspective.  REST re-uses many of the standard HTTP protocol verbs such as GET, POST and DELETE,  when constructing URL's.  These verbs are well understood and well used, so there's no new syntactic sugar to swallow.  Each component of the service owners database is abstracted into neatly described resources that can be accessed using the appropriate URI.  Requests can then be made to return, say, a JSON or XML representation of the underlying database object.



The client, permission granted, can then in turn update or create a new object in the same way, by sending a new JSON object via a PUT or POST request.

What's This Got To Do With IAM?

Identity management has often been thought of as an enterprise or organizational problem, focussing on the the creation and management of company email, mainframe and ERP system accounts.  This process then brought all the complexity of business workflow definition, compliance, audit, system integration and so on.  Access management on the other hand, has often been focused on single-sign-on, basic authorization and web protection.  IAM today is a much more complex and far reaching beast.  

Organizations are reaching out into the cloud for services, API's and applications.  Service providers and applications are becoming identity providers in their own right, reaching back out to consumers and businesses alike.  For once, identity management is on the tip of the tongue of the most tech-avoiding consumers, concerned with privacy, their online-identities and how they can be managed and consumed.

A RESTful Future

These new approaches to identity and access management require rapid integration, developer adoption and engine-like API's that can perform in an agile, scalable and secure fashion.  Identity and access management services for consumers, such as being able to login with their Facebook or Twitter account using OAuth or OAuth2 without having to create and manage multiple passwords for the other sites they interact with, not only increases user convenience.  It also puts pressure on business security strategies as they can struggle to cope with the ability for employees to bring-their-own-identity to many of the now popular business services such as Webex, Dropbox, Salesforce and the like.

As identity management is no longer solely concerned with siloed, business unit or organisational boundaries and looking more to being fully connected, integrated and focused on consumerization, developer adoption has never been more important.  Security in general, has never been a high priority for application builders, who are more centred on features and end usability.

Identity and access management is making a big change to that area with many access management systems being easy to externalize from application logic using RESTful integration.


By Simon Moffatt

[1] - Image attribute Stock.Xchng http://www.sxc.hu/profile.big_foot

BYOID: An Identity Frontier?

[bee-oi]. [b-yoy]. [be-yo-eye]. [bee-oy-ed].  Whichever way you pronounce it, the concept of bringing your own identity to the party is becoming a popular one.  Just this week Amazon jumped on the identity provider bandwagon, by introducing it's 'Login With Amazon' API.  What's all the fuss?  Isn't that just the same as the likes of Twitter and Facebook, exposing their identity repositories so that 3rd party application and service developers can leverage their authentication framework without having to store usernames and passwords?



Well in a word yes.  With the continual threat of hacking and cracking of consumer and business user account repositories, why wouldn't you as a developer, simply take advantage of someone else storing the password details on your behalf?  No need to worry about whether to use encryption or hashing, which algorithm to use, how to handle password reset management and so on.  Simply perform a call out during authentication time, probably using your favourite language, using a simple web standard and a way you go.  Simples.



Why It's Cool To Be An Identity Provider

So why have all of these identity providers sprung up?  Well in essence they haven't.  The Security Assertion Markup Language (SAML) has been around for the best part of 12 years and in the last 8 or so, has been implemented at numerous federation related projects both in the education, public and private sectors.  SAML has the concept of an identity provider, but that has been expanded in recent years to be more consumer orientated.  With the rise of social networking sites that house millions of user records and newer protocols such as OAuth(1 and 2), the use and consumption of these vast repositories is simpler.  From a social platform perspective (Facebook) or from a  consumer outreach perspective (Amazon) it makes pretty good business sense to get more applications, services and in turn users, using the sites and services they manage.  If you make cricket bats, you want to help those who make the balls.  It's the same with being an identity provider.  The consumer has a familiar (and to an extend trusted) account they use to log in with.  It's signal sign on, without all the password hiding and syncing stuff.

If The Consumer's Happy The Orgs Are Happy Right?

Well, if you're an identity provider, I'd imagine you are pretty ecstatic.  You have had to manage the user's password and account details in the past anyway.  So in theory they should be only a marginal cost to expose that information via an API to your apps developers or associated service providers.  Consumers are content as they don't have to create multiple accounts or remember lots of passwords each time they sign up to a new service or application.  But what about the non-consumer side of things?  Perhaps these users are also employees using their newly found identity freedom to access services and applications that are being used for business purposes.  Perhaps CRM systems, hosting providers, calendars, software repositories, syncing apps and so on.  How can that be managed and controlled?

Business Evolution Now Revolves Around Identity Management

I wrote recently about how modern enterprises now face significant challenges, as they expand into new business partnerships, with complex supply lines and an ever evolving mobile and now identity aware workforce.  For many organizations, their continual evolution into new areas of revenue, especially within the business to consumer space, will rely heavily on being able to manage both internal employee access to cloud based services, as well as managing their own consumers' access to their own resources.  Both can be complex, requiring unprecedented scalability and web enablement.

The 'consumer is king', now really translates to 'identity is king'.

By Simon Moffatt