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  -

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 an

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 attrib

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 f

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 a

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=patch ALLOW Manager2, org=124 - http://app.example.com/orgs/123/user/456?action=patch DENY Manager2, org=123 - http://app.example.com/orgs/124/user/567?action=patch ALLOW Manager1, org=123 - http://app.example.com/orgs/124/user/567?action=pat

OpenAM has a powerful policy decision point functionality (PDP) that can be leveraged entirely over the REST endpoints provided out of the box.  These endpoints allow for nice decoupling between the PDP and authentication infrastructure and your app.  A few things to setup first... Policies - policies map to the resource URL's that you want to protect, along with additional data such as the subjects (users) the policy will affect, as well as conditions such as IP address, time, authentication level requirements and so on. Authentication Modules -  an obvious component, but the modules can also be configured with an authentication level (an arbitrary numeric value) that provides an assurance level once a user has used a particular chain / module.  The auth level can then be leveraged via the policy. Authentication Authenticating the user over REST in v11 has changed slightly.  There is now the use of JSON based callbacks that allow for more flexible authentication scenarios.  For ex

I created a few custom endpoint extensions for use with OpenIDM, that allows for the analysis of users and their entitlements.  I won't go into the virtues of roles and role based access control, but these endpoints are a simple way to quickly identify similarities between groups of users and then quickly find any differences or exceptions.  These exceptions would then be analysed either by a certification system or perhaps manually by the security admin teams. Peer Analysis Peer Analysis JSON The first endpoint simply groups users (generally managed users) together based on a functional similarity.  This is generally known as 'top down' mining in full blown role mining projects.  The endpoint returns a JSON object with role names and an array of users that are part of that functional grouping. Peer Entitlements Peer Entitlements JSON The role object on it's own it's much use.  What we're really interested in, is what entitlements should be associated with that