Blockchain for Identity: Access Request Management

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

Embedded/Local Assertion Managment

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. 

Externalised Identity & ACL 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.  

Federated Identities

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.

A Blockchained Enabled Access Requestment Mgmt Workflow

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.

Delegated RBAC CRUD Via Workflow

OpenIDM provides a powerful delegated administration model, for both REST endpoint access and workflow process access.

A simple way to provide scoped access into the IDM functions, is to simply wrap a workflow process around it and then delegate access to that workflow to a certain of group of users.

A basic example could be that of role based access control administration.  The basic create, read, update and delete tasks often associated with object management.  So RBAC-CRUD to save a few letters.

Each CRUD function can be wrapped into a workflow, with access to those workflows then given members of the rbac-admins internal authorization role.

I created 5 workflows, four for the role-admins and 1 for the end user:

role-admins: createRole.bar

A simple wrapper that takes two arguments and runs an openidm.create() to create the role.

role-admins: deleteRole.bar

Opposite of create...and does a lookahead using some JS stored within the form HTML to get a list of roles that can be deleted.  Before the openidm.delete() function is called, it clears down the members list first.

role-admins: addRoleToUserTemporal.bar

So we have a role, now we want to add some users.  Again, does a lookahead to create a dynamic select drop down, then free text to add a username.  You could add some checking logic here I guess to make sure the user exists before submission, but I wrap a conditional check in the workflow before I patch the role anyway.

The other attribute is a timer - this is just based on the Activiti Timer element and I've set it to take just a time.  In reality you would accept a date, but for demo's a time is much easier.  So, after the time has been passed, the initial role to user association is reversed, taking the role away.

role-admins: removeRoleFromUser.bar

Simple manual process to remove a role from a user.  Note all the patches in the workflows work against managed/role.  Whilst you can add and remove roles from the managed/user/_id, by using managed/role endpoint, I can restrict the access the role-admins get via access.js more accurately.

openidm-authorized:requestRole.bar

We then have one workflow left - that is available to any user.  Eg it's a standard end user workflow, and this time for an access request.

This again does a look ahead and performs an approval step before provisioning the role to the user. The default manager approval is in the workflow and remmed out alongside the ability to use any member of the role-admins authorization role.  So you can flip between the two approval journeys.

The use of role-admins leverages the Activiti:Candidate users attribute - eg role-admins could contain 10 users - the approval goes to all 10 and the first one to claim the task can approve.

A couple of points on access.  The workflow access is governed by the ../conf/process-access.json file.  In there add in the pattern of the role _id along with the internal authorization roles that should have access - note internal role and not just managed/role.

The access.js file in the ../script directory also needs updating to allow full control to the managed/role endpoint to the role-admins users.

Code for this set is available here.

Note, thanks should also go to Marek Detko and some code crib from his role collection example.

Workflow Approval Via Encrypted Email Links

A common workflow process is often the access request scenario - a user requires access to something, and that something requires an approval before the provisioning can be completed. Typically this is done via notifications, a dashboard and perhaps an email notifying the approver that they have a task that requires their attention.

However, what if the approver doesn't want to, or cannot, access their dashboard to approve the request?  An alternative is to embed workflow approval questions into an email, with fully self-contained links that contain encrypted payloads to approve or reject the request. (NB a further extension to this is to be able to respond to workflow requests directly via email / SMTP).

A way to do this is to simply send an email during the workflow instantiation that contains links to approve or reject the request.  But how can those links be securely created to avoid tampering, replay and misuse?  There a few neat steps in the ForgeRock platform that can simply come to the rescue. (NB this assumes that the email traffic / account is secure, which might not be the case...!).

My use case will look like something like this:

1. Helpdesk operator requests access to impersonate an end user for a set period of time - say 5 minutes
2. The end user will receive an email notification with two links - Approve or Reject
3. Each link will go to two specific OpenIDM custom endpoints - ../endpoint/approveImpersonation or ../endpoint/rejectImpersonation
4. Each endpoint will take a ?payload= argument that will contain an encrypted value
5. That encrypted value will be contain the end user's Id and a unique reference to their workflow task instance
6. As every request into OpenIDM needs to be authenticated, we'll route the request via OpenIG to add in an authentication header
7. The custom endpoints will verify the payload, decrypt, find the appropriate workflow task instance and complete the workflow request task
8. If approved...the workflow will provision the end users Id into the helpdesk operators account under an attribute called impersonationId
9. The workflow will then suspend and return n-minutes later, based on the time selected in step 1 and deprovision the attribute in step 8.

The architecture at a high level looks something like this:

The main element of this is the workflow.  This is a simple access request style workflow with two interesting components. First is the sending of an email with the two links - both of which are encrypted using the openidm.encrypt function. The second is a time boundary that removes any changes the workflow makes after a selected time window.  The encrypted email payload contains a unique reference that is attached to the task instance.  The unique reference is created using the openidm.hash function, that takes the requester Id, requestee Id and the current time in ms.


To trigger the workflow, the enduser and a time element are entered.

This triggers the sending of the notification email with the two links.

The end user simply selects the appropriate link.  The link automatically redirects via IG to snowball the appropriate authentication headers and completes against the OpenIDM endpoint.

The endpoint verifies the payload argument exists, that the encrypted value is in tact, decrypts, finds the appropriate workflow task, compares the two hashed verification codes and completes the appropriate approve or reject action.

The workflow then contains an intermediate timer event that is used to act as a stop watch - to basically reverse any changes that are made, acting like a temporal condition.

        <intermediateCatchEvent id="timer">
  <timerEventDefinition>
    <timeDuration>PT${lengthOfImpersonation}M</timeDuration>
  </timerEventDefinition>
</intermediateCatchEvent>

The length variable is taken from the submitted workflow form.  After the timeDuration has completed a simple patch removes any values provisioned to the user.

        <scriptTask name="Cleanup User" id="cleanupRequestingUser" >
            <script>
                
                queryParams = ["_queryFilter": '/userName eq "'+startUserId+'"']
                userToPatch = openidm.query("managed/user", queryParams)

                patchParams = [[operation:'replace', field: 'idToImpersonate', value : ""]]
                openidm.patch('managed/user/'+userToPatch.result[0]._id, null, patchParams)
            </script>
        </scriptTask>

The code for the above sample is available here.