Using OpenAM Realms for Large Scale Access Management

ForgeRock OpenAM provides a powerful Realms facility, enabling OpenAM to be used in internet scale deployment scenarios. Realms can be used to divide user populations and their associated configurations, with each realm treated as a discrete administrative unit.

For each Realm, an authentication process can be defined, stating the location of the authentication repository for users and groups, such as an Active Directory or LDAP directory, and the type of authentication required. Each Realm also has the ability to have policies defined to determine whether or not an authenticated user is allowed access to a resource protected by OpenAM. Realms allow for the separation of configuration data for the services used per realm as well as for federation purposes.

For administrative purposes, delegated administration enables user populations to be separated and sliced via realms, so that they can be managed in a distributed fashion. Delegated administration is a critical component in the deployment of large user populations, where central administration becomes unwieldy and too complex to be practical.

Service providers can use Realms to centralize authentication and authorization for multiple customers (often referred to as tenants) from different companies. Realms provide the boundaries, separating the tenants from each other and ensuring that they do not authenticate to each other or obtain authorization to access resources from each other. Delegated administration can therefore occur at the tenant level.

The ForgeRock IRM suite shares a common RESTful API, allowing Realms to be created, managed, and configured via REST and also through the CLI and the Administrative Console.

For example, you can create a REALM via REST simply by using an HTTP POST, as follows:

1 2 3 4 5

$ curl --request POST --header "iplanetDirectoryPro: AQIC5w...2NzEz*" --header "Content-Type: application/json" --data '{ "realm": "testRealm" }' https://openam.com:8443/openam/json/realms/?_action=create {"realmCreated":"/testRealm"}

The only required field is realm, however, the realm will not be active unless its status is set.

The caveat to the current Realms implementation in OpenAM, is that logs are not yet separated per Realm. This is something that is being addressed in future product enhancements, as ForgeRock moves towards a full blown multi-tenant architecture.

For the curious and the technically savvy, given the long history and maturity of OpenAM, it’s worth mentioning that Realms were previously called “organizations” (prior to OpenSSO). This is why the OpenAM SDK often refers to an “organization object”, rather than a “realm object”, for backward compatibility.

In summary, OpenAM Realms offer a convenient way to slice up a large scale user population into manageable chunks that can be separated from each other in how they are configured. Realms also enable delegated administration - critical in distributing the administration load and in addressing the challenges of consumer-facing identity and access management for the modern web.

Adaptive Risk Authentication and the IRM Pillar Dynamic Intelligence

The requirements and demands on Identity and Access Management solutions have shifted. With a fresh pair of eyes, the industry calls this Identity Relationship Management (IRM). One of the pillars defining IRM is Dynamic Intelligence rather than Static Intelligence. Static Intelligence covers what we already know about a user, whereas dynamic intelligence includes things that might be spontaneous, such as geographical login location.

In the past, access patterns have been predictable. Employees have logged in from their usual desktop PCs, and have accessed the applications required to perform their job tasks. As the modern world has changed user behavior, predictability is no longer the case. Enterprise users access applications and services from a wide variety of locations and devices, including laptops, smartphones and their traditional desktop PCs. Looking beyond the enterprise at consumers, these users can leverage any device, from their home TV to their car.

A modern IRM solution must be able to cater for these dynamic access patterns and must understand the myriad of circumstances in which a user accesses a particular service, in order to grant access. Ultimately, authorization must also be dynamic and must provide the appropriate content or entitlements “on the fly”. A concrete example is that of a user trying to access services when logged in from a different country. An adaptable IRM system will adjust to the particular circumstances and will potentially ask for additional authentication beyond simple credentials.

This use-case is something that can be addressed with the latest release of ForgeRock OpenAM (introduced in OpenAM 10), which provides an adaptive risk authentication module. Adaptive Risk Authentication is not an authentication mechanism but rather identifies potential risks (such as logging in from a different country in the sample above), assigns a risk score and then determines whether logging in should require additional means of authentication. The additional authentication requirement can be anything from requiring a one time password to using some type of hardware mechanism.

An authentication mechanism that adapts to specific circumstances is a perfect example of the IRM pillar of “Dynamic Intelligence” and adds additional assurance that a user really is who she claims to be.

Some of the risks that can be defined and dealt with dynamically include IP Ranges, IP History, known cookies (and values), time since last login, profile attributes and their values or geographical location.

Pioneering risk-based, adaptive authentication has always been the domain of the financial sector. However, as this technology has become mainstream, more and more organizations are deploying adaptive authentication to deal intelligently with the growing number of mobile users, to mitigate the risks of users who fraudulently claim to be someone else in order to potentially commit malicious actions.