Top 5 Digital Identity Predictions for 2017

2016 is drawing to an end, the goose is getting fat, the lights and decorations are adorning many a fire place and other such cold weather cliches.  However, the attention must turn back to identity management and what the future may or may not hold.

Digital identity or consumer based identity and access management (CIAM) has taken a few big steps forward in the last 2 years.  Numerous industry analysts, aka Gartner, Forrester and Kuppinger Cole, have carved out CIAM as a new sub topic of IAM, that requires its own market and vendor analysis.  I think this is a valuable process, as CIAM projects tend to have very different requirements and implementation steps to traditional internal or employee based IAM.

From a predictions perspective, I see the following top 5 topics becoming key components of any digital identity platform for the next 12-18 months.


1 - Device Pairing Becomes a Base Requirement for IoT


Everyone knows about IoT.  It's going to save the planet.  Increase personalisation. Create loads of data and bring most CISO and network security managers to their knees.  Other than that, "smart devices", aka devices that can talk at least HTTP (hopefully HTTPS) will be much more powerful and useful, when tied and paired to a physical personal identity.  The classic "pin and pair" style use case. Take for example a smart-TV or a healthcare wearable.  By tying the device to an individual, the device can not only access cloud services and API's on the owners behalf, but can then in turn receive information to make the user experience more personalised.

A simple way to achieve this is via a draft IETF standard that leverages the popular authorization protocol OAuth2.  This allows the device to receive a scoped OAuth2 access token that can be used to represent the real person to other services.  More importantly the token can be revoked just like any other OAuth2 access token when the the device is sold or lost.


2 - OAuth2 Token Protection Becomes Mainstream


So what does this mean?  OAuth2 and OpenId Connect are the now defacto method for application owners to integrate 3rd party authorization, identity assertions and other authX style use cases. 
OAuth2 generates an access_token and refresh_token pair that are used to gain access to profile data or API's for example.  OpenId Connect extends this concept slightly, by also issuing an id_token that can basically act like a SAML2 identity assertion.

However...the access tokens, are bearer tokens.  What does that mean? Well if you are in possession of the token, you basically have access.  Assuming the token is valid of course.  This opens up the possibility that tokens can be stolen (thinking insecure communications channels, MITM, man-in-the-middle) and then reused maliciously.  The resource servers, by design only really check that the access token is valid and has the correct scopes/permissions - they don't check that the person, application or device that is presenting the token is the correct owner of the token.  Bad times.

Another draft IETF standard focuses on generating tokens that basically can't be reused if stolen. Each issued token contains a little piece of the requester - aka their public key.  This allows the resource server to extract the public key from the access token and generate a challenge response dance with the requester, to see if they are in fact the correct holder of the corresponding private key pair.  If they are, great, access granted.  If not, well access is not granted as they are not the original token owner.

3 - Social Signup Default


Social signup and sign in (aka Sign in with Facebook..) is so omnipresent in the applications and consumer services world, that enterprise service providers, be it in the public sector deliverying government services or the private sector deliverying banking, insurance or retail services, can not ignore the end user benefits it can bring.

Not only does it speed it the user registration process, it also reduces the over head for the service provider, in that they no longer need to handle password storage.  The user is authenticating with a 3rd party, so it allows the service provider to out source the password storage to Google, Facebook, Microsoft or whomever.

The flip side of using a 3rd party, is that you have to trust their vetting, registration and data storage capabilities.  Social networks are notorious for the having fake accounts, or accounts that no longer map into the correct owner.  If you are a service provider leveraging social sign in, your applications and data assurance standards need to align and add extra levels of assurance or verification as necessary.


4 - Push Authentication Default


What is push authentication? I thought one-time-passwords (OTP) were going to save the world? Well OTP's are certainly not going away any time soon, but many consumer facing sites and indeed social networks, are now introducing push authentication.  This basically occurs via a mobile app that creates notifications during login time.  The device and app and previously registered to the user.  During login time, the end user performs a simple action (generally a finger-print scan or a swipe) to confirm they are the user logging in.  Push is certainly becoming the standard mechanism amongst the under 30's and no doubt will replace OTP for enterprise multi-factor-authentication soon.


5 - Stateless Tokens & Micro-services a Match Made in Heaven


Microservice architectures seem to be everywhere.  Out with monolithic apps that often have long delivery cycles and lots of fragility and in with tiny, often single function applications, that are loosely coupled, that can be delivered and updated continuously.

However, that then introduces new challenges and requirements surrounding authentication and authorization in a microservices world. Here, OAuth2 again tends to come to the rescue, as many microservice or single function systems, are generally just exposed API's, sitting behind a routing and throttling mechanism.  Add in to that mix the ability to have stateless access tokens (that is, an access token that is a JSON Web Token, that carries all of the access, validity and permissions data with it in one place) and you can start to support multi-million transaction style infrastructures.

Microservice infrastructures tend to get hit hard.  Very hard.  Multi-million requests per day, performing GET's to retrieve data, or POST's to update, with each transaction perhaps hitting 10, 20 or 100 tiny independent services.  By being to pass down an access token within an HTTP authorization header is powerful and flexible and couple with that a token that is stateless provides the necessary scaling back bone.  

But why is stateless so interesting here? A stateless access token allows local introspection before access is given. That allows a microservice API to verify and look inside the presented JWT (which will appear in the Authorization header) without making a call back to the authorization service that issued the token. This reduction in hops can be pretty useful in high volume ecosystems - albeit the microservice will need the public key of the authorization service to verify the tokens and some extra code to verify and then introspect attributes like the exp, aud, scopes etc.

Interesting to see where we are come this time 2017...

Top 5 Digital Identity Predictions for 2017

2016 is drawing to an end, the goose is getting fat, the lights and decorations are adorning many a fire place and other such cold weather cliches.  However, the attention must turn back to identity management and what the future may or may not hold. Digital identity or consumer based identity and access management (CIAM) has taken a few big […]

ForgeRock OpenAM and Social Authentication (Facebook) using OAuth2

This blog post was first published @ www.fedji.com, included here with permission.

The video demonstration embedded below this write-up is dangerously similar to the video here , published more than three months ago. I’ve had challenges making this one though, which is when my colleagues Jon Knight and Albert Ayoub stepped forward to lend a helping hand. So if you ready, let’s see how ForgeRock OpenAM lets a user authenticate against his/her Facebook account to gain access to OpenAM (read applications protected by OpenAM).

Enjoy!

There is a very useful article around this right here.

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

Forget Firewalls, Identity Is The Perimeter

"It is pointless having a bullet proof double-locked front door, if you have no glass in your windows".  I'm not sure who actually said that (if anyone..), but the analogy is pretty accurate.  Many organisations have relied heavily in the past, on perimeter based security.  That could be the network perimeter or the individual PC or server perimeter.  As long as the private network was segregated from the public via a firewall, the information security manager's job was done.  Roll on 15 years and things are somewhat more complex.

"Identity as the perimeter" has been discussed a few times over the last year or so and I'm not claiming it as a strap line - albeit it is a good one at that.  But why is it suddenly becoming more important?



The Extended Enterprise - Mobile, BYOD, Consumer

Organizations of all sizes are no longer central places of work, with siloed business units, headed up by managers in glass-walled offices.  Remote working is no longer limited to cool startups or the creative industries.  Desktop PC's are now in decline, with tablets and smartphones able to do the majority of work related use cases.  Many organisations now have complex supply chains, leveraging partners, sub-partners, clients and consumers.  Outsourced services and applications now make up a large percentage of an organization's delivery management process, with these services often allowing authentication and user management controls outside of the standard corporate LDAP.

The increased use of BYOD, mobile workforces and increased outsourced and consumer lead service interaction, requires a much more integrated and agile view of an identity, but also requires CISO's, to view data protection and segregation in a much more user centric approach.

There Is No Network Separation - Everything is Connected

Everything is connected.  You can receive corporate email on your smartphone over a network carrier paid for privately.  Remote backup and file sync solutions allow sensitive files to be stored off site without the knowledge of a DLP solution.  There is no longer a 'corporate' network with strong demarcation lines.  Whilst this has obvious user benefits and efficiency gains, it has opened up new areas for security management.  The one thing which is staying relatively static is the that of the identity driving this change.  I don't mean the role and concept of identity is static.  Quite the opposite, but identities are still the driving force between application interactions, network traffic analysis, DLP techniques, firewall management and so on.  Each transaction should be linked in some way to an identity.  This identity could be well masked through alias upon alias, but there are fewer and fewer chances for a truly anonymous computer interaction.

Extend the Enterprise or the Stretch The Cloud?

These identities are developing in multiple directions.  The traditional corporate view of an identity originating from an authoritative source such as HR and flowing via provisioning systems to a target directory or database is still present.  Complex workflows and RBAC projects will keep many a consultant in work for years to come.  But with the onset of the extended enterprise, the increased use of social and cloud based identity brokers and platforms (Google, Facebook et al), there is a need for fusion.  The ability for organisations to extend to the 'cloud' and the for the internet based services and brokers to able to reach out to traditionally standalone organizations with their new apps and services securely, whilst still making the user experience convenient.  But where to start?  Traditional enterprise identity and access management solutions are often too static and unable to scale to internet style proportions.  Internet focused identity has been about single sign on, federation and authentication via social platforms. Organizations need to be able to manage interactions with 3rd party service providers from a centralised, potentially policy driven, authentication and authorization perspective.  It's pointless disabling a contractor's internal LDAP account if they still have an active Saleforce or Dropbox account when they've left.

Compliance doesn't just fade away in cloud and internet based scenarios.  There are still stringent controls that need to be adhered to, in order for an organization's identity management platform to be both convenient and effective.

By Simon Moffatt