The Road to APIness in Customer Identity
Using some conservatism in the timescale, I’d say in the last 5 years the Identity Access Management (IAM) scene has seen some major changes. We have gone from the closed Directory type environments, which were (fairly) straightforward when on-boarding users, to mass adopted open consumer systems, with the type of demographic, UX designers dread. It has all happened a bit quickly. The result has been somewhat of a lag in recognition of the complexity of such systems. In has only been in the two years or so that analysts, normally at the forefront of technological advances, have started to look at customer identity as an entity in its own right. That is not to say that the murmurings of market movement have not been felt in the IAM space. Identity-as-a-Service (IDaaS) is crossing the security barrier, with Gartner predicting implementations to reach 40% by 2019 – IDaaS having a more flexible model for external access requirements. The new direction of an outward looking, all encompassing IAM infrastructure, is now opening its doors to the customer or consumer. This is creating a sub-set of IAM known as Customer Identity Access Management or CIAM.
CIAM is a fruition of a multitude of changes: from Internet uptake to broadband availability to consumer expectations. It has meant that enterprises, SME’s, not-for-profits, governments, and so on, all have the same problem – how to service myriad identity use cases with high degrees of security and assurance, whilst making the user experience wonderful.
Enter, the Universal Identity API.
The Answer to CIAM: AN API Approach?
CIAM is the mothership of all identity types. It has to potentially cope with demographics, as wide as a country, whilst at the same time having robust web security. It’s a hard balance to get right. To make matters worse, CIAM platforms, often need to be used in a multitude of service types and customer expectations. Let me give you an example that is based on a real-world scenario. An identity system was to be built on the premise of a variant of SAML 2.0 that was non-standard. An out-of-the-box IdP would struggle with this and would require a back-end change to handle the SAML response expectation. This would mean that the development team behind the IdP would have to essentially hard-code the solution. This in itself would be fine, if annoying, but this is only one of potentially many bespoke changes an IdP would need to make to fit complex customer based identity. This means that to get something ‘right’ you would be in almost perpetual development mode. This benefits no-one in the long term.
To manage the many faces of customer and citizen identity, vendors have looked to adding in API capability to their solutions. The problem is that in doing so, they have not been ambitious enough in their architecture and design. They have effectively created point solutions, albeit API-based, but all the same, they only address certain areas of the overall CIAM ecosystem.
CIAM – The Recipe For Success – Ditch the Platform
An API approach is the right answer to the question of servicing myriad use cases. However, it isn’t the API that is at fault here, it is how that API functions. Let me use an analogy. If you are making a cake, you have certain ingredients you need to make a Victoria sponge, and you add in certain others to turn it into a chocolate cake. If you don’t have any cocoa powder or chocolate, then you won’t be able to make anything other than a plain Victoria sponge – no matter how wonderful the sugar, eggs, and flour are. It is the same with an API. If you restrict your API functionality, to say, authentication, then that will restrict the flexibility around the use cases your platform has to accommodate.
In fact, let’s go crazy and ditch the platform altogether! Hang on I hear you shout, don’t go mad! There is method in this madness and it is called an ‘API Recipe’ using a ‘Universal Identity API’.
If you move away from the closed mindset of having a static platform you open up new possibilities for CIAM. If, instead of constraining your API approach to point API functions, you turn your platform into an API, then you have the ability to add in some cocoa powder, or even a touch of cinnamon to the mix. This new approach to identity is called an API Recipe. Using a recipe based approach to mix and match identity-based functions, gives you much more flexibility in handling a variety of customer based use cases.
How To Bake An IdP
Here’s a recipe for an IdP:
1 cup of OpenID Connect
½ cup of authentication
½ cup of verification services
Add a sprinkle of account manager
Mix together, add in a few endpoints and some rules, and bake inside a decoupled user interface for 2 hours.
And another for a Personal Data Store:
1 and ½ cups of data store functionality (secure data sharing)
1 cup of account manager
¾ cup of authentication
⅓ cup of blockchain based consent receipts
¼ cup of external services such as document capture
Mix together with rules on a low user interface setting for 4 hours
Flexible Requirements, Need Flexible Approaches
The above may seem like a silly way of developing an IDP for a consumer system. But this is what is needed to give us the level of flexibility and functionality needed to address the ever-changing consumer identity needs of a modern CIAM solution.