The Identity Cookbook

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 function

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 rol

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 si