Skip to main content


Showing posts from 2015

Scripted OpenID Connect Claims and Custom JWT Contents

OpenID Connect  has been the cool cat on the JSON authorization cat walk for some time.  A powerful extension to the basic authorization flows in OAuth2, by adding in an id_token. The id_token is a JWT (JSON Web Token, pronounced 'jot' but you knew that) that is cryptographically signed and sometimes encrypted - depending on the contents. The id_token is basically separate to the traditional access_token, containing details such as which authorization service issued the token, when the user or entity authenticated and when the token will expire. OpenAM has supported implementations for OpenID Connect for a while, but a more recent feature is the ability to add scripting support to the returnable claims.  Adding scripting here, is a really powerful feature.  Scripts can be either Groovy or JavaScript based, with a default Groovy script coming with OpenAM 13 out of the box. The script is basically allowing us to creatively map scopes into attribute data, either held on the user&

Device Authorization using OAuth2 and OpenAM

IoT and smart device style use cases, often require the need to authorize a device to act on behalf of a user.  A common example is things like smart TV's, home appliances or wearables, that are powerful enough to communicate over HTTPS, and will often access services and APIs on the end user's behalf. How can that be done securely, without sharing credentials?  Well, OAuth2 can come to the rescue. Whilst not part of the ratified standard, many of the OAuth2 IETF drafts , describe how this could be acheived using what's known as the "Device Flow"  This flow leverages the same components of the other OAuth2 flows, with a few subtle differences. Firstly, the device is generally not known to have a great UI, that can handle decent human interaction - such as logging in or authorizing a consent request.  So, the consenting aspect, needs to be handled on a different device, that does have standard UI capabilities.  The concept, is to have the device trigger a request,

OpenIDM: Relationships as First Class Citizens

One of the most powerful concepts within OpenIDM, is the ability to create arbitrary managed objects on the fly, with hooks that can be triggered at various points of that managed objects life cycle.  A common use of managed objects is to separate logic, policy and operational control over a type of users.  However managed objects need not be just users, commonly they are devices, but they can also be used to manage relationship logic too - similar to how graph databases store relationship data separate to the entity being managed. For example, think of the basic relationship between a parent and child (read this article I wrote on basic parent and child relationships) . That article looked into the basic aspect of storing relationship data within the managed object itself - basically a pointer to some other object managed in OpenIDM. That in itself is powerful, but doesn't always cover more complex many-to-many style relationships. The above picture illustrates the concept of ex

Explain it Like I'm 5: OAuth2 & UMA

This entry is the first in a mini-series, where I will attempt to explain some relatively complex terms and flows in the identity and access management space, in a way a 5 year could understand. Hopefully... First up is OAuth2 and  User Managed Access or UMA , a powerful federated authorization flow that sits on top of OAuth2 . Explain it like I’m 5: OAuth2 OAuth2 allows people to share data and things with other services that can access that data on their behalf.  For example, an individual might want to allow a photo printing service access to a few pictures from an album stored on a picture hosting service. Explain it like I’m 5: Resource Server The resource server is the service or application that holds the data or object that needs sharing.  For example, this could be the picture hosting site that stores the taken pictures. Explain it like I’m 5: Resource Owner The resource owner is the person who has the say on who can retrieve data from the resource server.  For example, this c

UMA Part 2: Accessing Protected Resources

This second blog on UMA, follows on from part 1, where I looked at creating resource sets and policies on the authorization server. Once an authorization server understands what resources are being protected and who is able to access them, the authorization server is in a position to respond to access requests from requesting parties. A requesting party is simply an application that wants to access resources managed by the resource server. The above diagram looks complicated at first, but it really only contains a couple of main themes. The authorization server, responsible for the resource sets, policies and ultimately the policy decision point for evaluating the inbound request, the resource server, acting as the data custodian and the relying party - the application and end user wanting to gain access to the resources. There are a couple of relationships to think about.  Firstly, the relationship between the resource server and the authorization server.  Described in the first blog,

UMA Part 1: Creating Resource Sets & Policies

User Managed Access (UMA)  is a new standard, that defines how resource owners can control protected-resource access by clients operated by arbitrary requesting parties, where the resources reside on any number of resource servers, and where a centralized authorization server governs access based on resource owner policy.  So what does that mean? Basically in today's highly federated, cross platform, distributed world, data and information needs sharing to multiple 3rd parties, who all reside in different locations with different permission levels. UMA looks to solve that problem by introducing a powerful approach to transparent user centric consent and sharing. I'm going to take a look at the ForgeRock implementation of UMA , available in the nightly builds of OpenAM 13. Creating Resource Sets First up, what are resource sets?  Before someone can share anything, they basically need to define what it is they are going to share.  So this is concerned with defining object level c

API Throttling with OpenIG

A common requirement with regards to API access, is the ability to throttle the number of hits a user or service can have against a particular endpoint or set of endpoints - similar to a soft paywall style use case. The nightly build of OpenIG  contains a new filter - the ThrottlingFilter - which allows a simple way to limit and then time-out, a user who hits an endpoint x-number of times. To test, I created a simple node.js API that allows the read (GET) and write (POST) of widgets.  Each widget has a numerical id that is used as the identifier.  I also created a basic queryAll route within my node.js API to do a wildcard-esque search to return all ids. So now, I wanted to add OpenIG into the mix and do a little reverse-proxying.  I wanted to basically expose only the GET queries against my API, preventing POST requests entirely and only allowing GETs to specific endpoints.  To those endpoints I also wanted to limit the number of requests per user to 3 - if that threshold was hit I wo

Seamless User Profile Migration from MySQL to OpenDJ

Following on from my previous post on OpenDJ password schemes , a common requirement is often to migrate users into the OpenDJ profile store from an existing database. There are numerous ways to do this, such as LDIF file imports or using OpenIDM reconciliation and livesync . However, both methods only really do a like for like comparison – no data cleansing takes place - unless you start to configure some logic processing in there. This might be fine, but if your existing repositories contain millions of entries, some of which you don't know are live, a quick way to migrate across only active users, is to use OpenAM, with it's Dynamic Profile creation feature. The above describes the process at a high level. Basically there are 3 authentication modules in a chain, using the flexibility of sufficient and optional modules .  In this flow, there are basically 3 states. User in MySQL User in OpenDJ Authentication Works Against Password Captured 1st Run Yes

Password Storage in OpenDJ

A common use case, is the migration of user profile data to OpenDJ.  Especially in large scale consumer facing identity projects, most clients already have repo's that contain user profile data. Sometimes these stores also contain authentication data - that is the user name and password of the individuals.  Migrating data is relatively simple in this day and age regardless of whether that is identity data or not, but a common issue regarding login credentials, is how to migrate without impacting the login process.  For example, you don't necessarily want to get every user to reset their password for example, when they migrate to the new system. Within OpenDJ this fortunately isn't a big deal.  A reason users might have to reset their password, is often to do with how the password has been stored on the source system.  When it comes to passwords there are generally two main approaches - symmetric encryption and hashing.  Symmetric encryption (meaning the password can be decr

Stateless Tokens within OpenAM 13.0

The unstable  OpenAM nightly build of 13.0 , contains a great new feature: the ability to create stateless or client side tokens.  This brings a range of new use cases to the access management table, including increased scale (less server side storage, CTS replication and in memory storage) and the potential for "offline" token introspection for authorization.  Stateless does of course lack a lot of the key features of the stateful architecture. What is a stateless token? The stateless token is basically a JWT token, that is stored in the existing iPlanetDirectoryPro cookie (if accessing via a browser) or within the tokenId response if authenticating over REST.  The JWT contains all of the content that would stored on the server side in a stateful session - so things like uid, expiryTime and any other profile or session attributes you want to define. To quote my colleague Ashley Stevenson "Stateful is a phone call and Stateless is a text message". The token can als

Open Source, Binaries & Celebrity Chefs

Working for an open source software company, I am faced with questions surrounding the open source approach and model in most customer meetings.  Many customers understand what open source is, or they think they do, but still want to know more. Open source vendors are now everywhere - Github, the social code repo, claims to house over 22 million projects.   That is a staggering number.  Many public sector and government departments, now have a preference to use open source vendors in their selection processes.  Some of the biggest vendors on the planet, are now the top contributors to the Linux Kernel - including IBM, Samsung and Google. So I think it is fair to say, that Open Source Software (OSS) is here to stay.  However, there is often some confusion around how a commercial model around OSS materialises.  I use the following little flow to emphasis some of the differences between open source and compiled binaries and the subtle differences between customization and configuration.

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 checko

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 follow

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 featu