Building a Password Checkout Service in OpenIDM

A common use case within the identity life cycle management world, is what to do with shared and privileged accounts.  Common accounts such as administrator, root, backup operator accounts and other delegated administration accounts, lead to a significant anti-pattern approach when it comes to password management.  For example, many shared service or administration accounts....are just that: shared.  Sharing a password is a very insecure method of account administration.

This generally brings out several security issues:

• The password is generally none-complex in order for many users to remember it
• The sharing of the password is not tracked - people who shouldn't know the password generally do
• It's difficult to track who is actually using an account at any moment in time

Whilst these issues are well known...they are still prevalent, and hence an entire sub industry focused on privileged account management (PAM).

Whilst OpenIDM isn't a PAM product, some basic password checkout service use cases can easily be coded out using the custom endpoint component, in a few lines (say 150!) of JavaScript.

The above flow was implemented via a single custom endpoint - the Password Checkout Service. This service basically leverages some of the core functionality of OpenIDM, such as the scheduler, OpenICF connectors, policy engine and role based access control model.

The PCS is a few JavaScript files that basically does a few things.  Firstly it applies an RBAC constraint on who can use the service - simply driven by a role called passwordCheckoutService. 

Only members of the role can use the service.  The PCS then checks a white list for accounts the PCS can work against - we don't want to be resetting the password of a normal user! This white list exists in a a CSV called pcsValidAccounts. The PCS then checks it's request store - pcsRequests.  This store contains records of the following format: 

• requestId - unique reference for that particular request
• requestTime - time stamp 
• account - userid of the account being checked out
• accountPath - the OpenIDM reference to where the account sits
• checkoutActive - is the current checkout still alive (boolean)
• checkedOutBy - userid of the user performing the check out
• resetTime - time in the future then the account will be reset

This demo stores the above in a CSV file using the out of the box connector, but a SQL connector could equally be used in production pretty easily.

Configuration is available for the following items:

• duration an account can be checked out for (minutes and hours)
• the length of the password to be issued
• number of upper case chars in the issued password
• number of numbers in the issued password
• number of special chars in the issued password

The checked out passwords are notified to the calling user in the JSON payload, but could easily be sent via the OpenIDM email service, to a pre-registered email address to add a little more security.

The PoC-level source code is available here.

People, Data & Devices

This week I was at the Gartner IAM Conference in London and I had several conversations regarding the different components in the IoT space.  The obvious consistent components are the devices themselves, the people (who either own or operate the device) as well as the data those devices either collector, process or generate.

That isn't a particularly insightful observation.  It does however, have some significant implications. Many existing identity and access management frameworks, products and implementations focus on the P - people.  As the IoT landscape develops, the IAM framework needs to be significantly expanded to accommodate life cycle, authentication and authorization services across a multitude of components, especially data.

For example, device registration and authentication is well understood, but what about the security regarding the data integrity, delivery and correlation of that data?

Do the new identity frameworks now need to accommodate use cases like the following:

• Authorization checks at the broker collection level when a device delivers it's data payload
• Tagging of data to allow a full supply chain to exist when data exists in it's final cloud storage
• Ability for clients to register and apply claims to the services that sit on top of the correlated data
• Ability for services to register against the final big data persistence store
• Ability for users to grant access to clients, services and applications to the data they tagged
• Ability for devices to represent a user or service in a transaction

There are clearly a lot more use cases that exist in the new IoT world, that have can't be fulfilled in the current identity landscapes.  Will be interesting to see how they develop.

Building Hierarchical Relationships with OpenIDM

One of the common use cases I've seen recently, is the ability to link statically provisioned objects to one another.  Commonly known as linking or hierarchical linking, this provides a basic parent to child relationship, in an "1-to-many" style relationship.  For example, a literal parent, may have several children in his family, which needs to represented in a permanent or solid format.

If you apply that concept to identity, this could be required for things like production lines (parents) to sensors (children), bill payer (parent) to content subscriber (child) in the media world or perhaps floor manager (parent) and operator (child) in a retail setting.

The main idea being, is that the parent may have different characteristics (different schema, different policy validation, delegated administration rights) from the child, but still has a very permanent relationship with the other object.

OpenIDM has the ability to very quickly create different object types.  This feature is popular in the
complex and relationship device driven world of internet of things.  The concept of types, allows your identity framework to accommodate objects with different characteristics, such as those requiring different administrators or have different data syntax and policy validators.

Within the OpenIDM admin UI (http://openidm-server:port/admin) you can simply create a new vanilla object type.

This simple task, opens up the OpenIDM API to now accomodate the basic CRUDPAQ operations against your new object.  For example I could now do a GET on ../openidm/managed/parent/_id to retrieve a JSON of a parent.

In this case, I also created a child entry too.  Now, the interesting bit comes with a basic example of how we link these two together.  Each managed object has a number of hooks that come with OpenIDM, that allow us to apply logic via our scripting framework.  An interesting one with respect to linking is the onRetrieve hook.  This basically gets called on a GET or read of the object in question.  As a little food for thought, I can do the following to link my parents to their children using this hook.

When I create a child (perhaps via delegated admin as a parent), I add in a parent_id attribute, that simply contains the parent object _id.

We can use the child's parent attribute in the linking process.

To do so, simply add in a few lines of script within the parent managed object's onRetrieve hook.

The onRetrieve script (which can be JavaScript or Groovy), does a few things.  Firstly it finds and stores the parent _id as a variable.  That parent _id is then used to do a query against the managed/child objects list, using a default out of the box query: the get-by-field-value query.  This is basically a catch all search that allows me to filter the list of all managed children, for those with a specific criteria.  Basically, those that have a parent attribute as my parent _id.

The script can either be inline or saved to an external file.  In general I save as an external file as it makes it easier to manage in large deployments and allows for greater portability - but that's just my preference.

Once the query has completed, the results (which will be an array []) are simply dumped in to the parent object as a children attribute.

The end result is super simple - when you do a GET on a parent, there is a children attribute that contains an array of all the children objects that have the same parent _id!  You could probably cut that attribute down, to simply full out only the children _ids for example to make it cleaner, but that is for design.

The full onRetrieve example script is here:

//Save the current parent object _id
var parentId = object._id;

//Search all children for those with specific parent_id
foundChildren = openidm.query("managed/child", {"_queryId": "get-by-field-value", "field": "parent", "value": parentId } );

//All children [] - note this is full object
children = foundChildren.result;

//Populate against the parents children attribute
object.children = children;