This is the first in a series of blogs, that will start to look at some use cases for leveraging block chain technology in the world of identity and access management. I don’t proclaim to be a BC expert and there are several blogs better equipped to tackle that subject, but a good introductory text is the O’Reilly published “Blockchain: Blueprint for a New Economy”.
I want to first look at access request management. An age old issue that has developed substaintially in the last 30 years, to several sub-industries within the IAM world, with specialist vendors, standards and methodologies.
In the Old Days
So this is a typical “standalone” model of access management. An application manages both users and access control list information within it’s own boundary. Each application needs a separate login and access control database. The subject is typically a person and the object an application with functions and processes.
Specialism & Economies of Scale
So whilst the first example is the starting point – and still exists in certain environments – specialism quickly occured, with separate processes for identity assertion management and access control list management.
So this could be a typical enterprise web access management paradigm. An identity provider generates a token or assertion, with a policy enforcement process acting as a gatekeeper down into the protected objects. This works perfectly well for single domain scenarios, where identity and resource data can be easily controlled. Scaling too is not really a major issue here, as traditionally, this approach would be within the same LAN for example.
So far so good. But today, we are starting to see a much more federated and broken landscape. Organisations have complex supply chains, with partners, sub-companies and external users all requiring access into once previously internal-only objects. Employees too, want to access resources in other domains and as-a-service providers.
This then creates a much more federated landscape. Protocols such as SAML2 and OAuth2/OIDC allow identity data from trusted 3rd parties, but not originating from the objects domain, to interact with those resource securely.
Again, from a scaling perspective this tends to work quite well. The main external interactions tend to be at the identity layer, with access control information still sitting within the object’s domain – albeit externalised from the resource itself.
The Mesh and Super-Federation
As the Internet of Things becomes normality, the increased volume of both subjects and objects creates numerous challenges. Firstly the definition of both changes. A subject will become not just a person, but also a thing and potentially another service. An object will become not just an application, but an autonomous piece of data, an API or even another subject. This then creates a multi-point set of interactions, with subjects accessing other subjects, API’s accessing API’s, things accessing API’s and so on.
Enter the Blockchain
So where does the block chain fit into all this? Well, the main characteristics that can be valueable in this sort of landscape, would be the decentralised, append-only, globally accessible nature of a blockchain. The blockchain technology could be used as an access request warehouse. This warehouse could contain the output from the access request workflow process such as this sample of psuedo code:
{“sub”:”1234-org2″, “obj”:”file.dat”, “access”:”granted”, “iss”:”tomorrow”, “exp”:”tomorrow+1″, “issuingAuth”:”org1″, “added”:”now”}
This is basic, but would be hashed and cryptographically made secure from a trusted access request manager. That manager would have the necessary circle of trust relationships with the necessary identity and access control managers.
After each access request, an entry would be made to the chain. Each object would then be able to make a query against the chain, to identify all corresponding entries that map to their object set, unionise all entries and work out the necessary access control result. For example, this would contain all access granted and access denied results.
So What?
So we now have another system and process to manage? Well possibly, but this could provide a much more scaleable and interoperable model with request to all the necessary access control decisions that would need to take place to allow an IoT and API enabled world.
Each object could have access to any BC enabled node – so there would be massive fault tolerance and elastic scaling. Each subject would simply present a self-contained assertion. Today that could be a JWT or a token within a proof-of-possession framework. They could collect that from any generator they choose. Things like authentication and identity validation would not be altered.
Access request workflow management would be abstracted – the same asychronous processes, approvals and trusted interactions would take place. The blockchain would simply be an externalised, distribued, secure storage mechanism.
From a technology perspective I don’t believe this framework exists, and I will be investigating a proof of concept in this area.