The Identity Cookbook

This week was the EMEA IRM Summit over in Dublin and whilst the Guinness was flowing there were a few things ticking over in my mind, especially after some of the great Internet of Things related talks and demo's we had.

The 'R' in Identity Relationship Management, is often now referring to the relationships between people and the things they either own, share or have access to: the IoT explosion.  People to people relationships are still a massive underpinning in the IoT world and the real person behind machine and device interaction is still a priority.  However, how can we start handling authentication and authorization services for devices?

I think there are several key high level points:

Identity Registration - the simple case of a person providing attribute values to a store.  The basic self-service form, or perhaps social media registration service.  A web service ultimately gets to know about a 'real' person.  Nothing too knew here.Device Registration - Ok, so…

OpenIG 3.0 was released a couple of weeks ago, with some significant enhancements.  One of which was the ability to protect applications through the use OAuth2 access tokens, with very little effort.

OAuth2 has been around for a while, and provides a lightweight and developer friendly way to leverage authorization services for web and native applications.  To utilise the features of OAuth2 such as access token validation, refresh token to access token exchange and then scope querying by the client application, generally requires code changes within both the client app and resource servers.  This isn't necessarily a bad thing nor particularly complex, but in some circumstances,  you may not have access to the underlying code, or perhaps the app is hosted by a 3rd party.

OpenIG, as it's a reverse proxy, can easily sit in between the user community and the underlying target application.  With a simple edit of a JSON file, OpenIG can be setup to act as both the resource server and c…

A common use case for both internal and consumer identity management, is that of scoped or delegated administration.  For example, your managed user repository may contain objects from different business areas, consumer types or locations, with each requiring a specialist administrator to perform creates and deletes.

The authorization and custom endpoint model in OpenIDM is very simple to extend, to allow for authorization rules across a number of different scenarios.  The most simple I've picked is that of an attribute called "type" - you could make this attribute anything you like - but type is easy to explain.

For example  - all I require is that all users of "type" == "staff" are only managed via administrators who are also of "type" == "staff".  Users who are administrators, but of say "type" == "consumer" can't manage staff, they can only manage consumers.  Obviously type could be altered for any attribu…

OpenAM v11 has a basic dashboard service, that can be used to provide SSO links to internal and cloud apps, in form of a personalised portal or dashboard.  It is pretty simple to setup out of the box.

A question I get asked quite often, is how to manage the apps a user gets?  Can we provision them just like say groups within AD?

The simple answer is yes.  Once the service is setup for a particular realm and an app is assigned to a user, an attribute called assignedDashboard is added and populated on the users profile.

The assignedDashboard attribute, is an array, that can be manipulated just like any other on the user object.  The items in the array, are the names of the app given within the config in OpenAM.

The setup of the apps within OpenAM is well documented, but each dashboard app contains the necessary SSO link and any associated federation classes.  The name is what can be 'provisioned' to the individual user and stored on their user profile.

Within OpenIDM it is then fairl…

Most online digitization programmes require new consumers, customers or potential customers to register to their service.  Nothing new here.  You are obviously going to have to register, give away some contact information, probably enter a username and certainly a password, before you can gain access to a service or website.  In the C2C world, the main objective is virality - ie spread like a virus and get as many people signed up to your app or site as soon as possible.

In the B2B and B2C worlds, there is a subtle difference - mainly verification or approval of the users attempting registration.  Many organisations, especially within the financial services arena (I'm thinking retail banking, insurance, asset management, share management etc) all require not only a strong level of authentication (OTP, biometric, MFA) but also a strong level of assurance or verification first.


The above is an example of a basic flow that occurs during a self-registration process.  (Note I documented …

The Internet of Things (IoT) is an exciting buzz, for the many collections of previously dumb devices that are now gaining 'smart' status and increased network connectivity.  Whilst there is an increasing rush to make everything connected, not all egres devices can be on line all the time.

Many IoT devices are small, even compared to the smallest of smart phones.  Many have limited memory, processing power and networking capability.  This can reduce the ability of the device, to interact with central authentication and authorization services over common approaches such as HTTP and REST.

Challenges

Without connectivity to a central source, how do devices authenticate users, services and other devices or perform policy enforcement point style use cases?  The requirement for offline capabilities forces many to look at cumbersome out of band syncing or caching approaches.

JSON Web Tokens

Asymmetric cryptographic solutions have been around for years and can provide many encryption and s…

For a PoC, the OAuth2 authorization code grant use case, needed to be stubbed out.  Whilst this can be done over Curl, I decided to build this out in NodeJS to replicate a client application more closely.

The OAuth2 authorization code grant is fully explained here - http://docs.forgerock.org/en/openam/11.0.0/admin-guide/index/chap-oauth2.html#oauth2-authz

Basically there is a decoupling between the resource owner, the requesting client and the authorization server.


My basic client, first of all authenticates the end user to get an OpenAM session token.  That token is used to generate an authorization code, which is in turn used by the client to request access and refresh tokens and ultimately the attribute scopes for the user.

The code is available on Github - https://github.com/smof/node_openam_oauth2_client

To perform conditional URL evaluation (where there are arguments in the URL that will change and impact the policy decision), a custom policy evaluation plugins needs implementing - http://docs.forgerock.org/en/openam/11.0.0/dev-guide/index/chap-policy-spi.html
Use Case
URL to contain all information required to make a policy decision, but components of the URL vary adding context.
Eg – http://app.example.com/orgs/*/users/*?action=patch
In this example an organisation number prefixs users, whilst the user number suffixes users. A condition should exist where only users who are managers AND managers of the same organisation of the user they're accessing should be allowed.
Manager1, org=123 – http://app.example.com/orgs/123/user/456?action=patchALLOW Manager2, org=124 - http://app.example.com/orgs/123/user/456?action=patchDENY Manager2, org=123 - http://app.example.com/orgs/124/user/567?action=patchALLOW Manager1, org=123 - http://app.example.com/orgs/124/user/567?action=patchDENY

Imple…