Leveraging AD Nested Groups With AM

This article comes from an issue raised by multiple customers, where ForgeRock Access Management (AM) was not able to retrieve a user’s group memberships when using Active Directory (AD) as a datastore with nested groups. I’ve read in different docs about the “embedded groups” expression, as well as the “transitive groups” or “recursive groups” or “indirect groups”, and finally, the “parent groups” expressions. I’m just quoting them all here for search engines.

As a consequence, it was not, for example, possible for AM agents or any policy engine client, such as a custom web application, to enforce access control rules based on these memberships. In the same manner, applications relying on the AM user session or profile, or custom OAUTH 2, or OpenID Connect tokens could not safely be used to retrieve the entire list of groups a user belonged to. In the best case scenario, only the “direct” groups were fetched from AD, and other errors could occur. Read more about it below:

Indeed, historically, AM has used the common memberOf or isMemberOf attribute by default, (depending on the type of LDAP user store), while AD had a different implementation that also evolved across time.

So, initially, when AM was issuing “(member=$userdn)” LDAP searches against an AD, if, for example, a user was member of the AD “Engineering” group, and that group was itself member of the “Staff” group, the above search was only returning the user’s direct group; in this case, the “Engineering” group.

A patch was written for AM to leverage a new feature of AD 2003 SP2 and above, providing the ability to retrieve the AD groups and nested groups a user belongs to, thanks to a search like this: (member:1.2.840.113556.1.4.1941:=$userdn).

See, for example, https://social.technet.microsoft.com/wiki/contents/articles/5392.active-directory-ldap-syntax-filters.aspxon this topic.

This worked in some deployments. But for some large ones, that search was slow and sometimes induced timeouts and failing requests; for example, when the AM agent was retrieving a user’s session. Thus, the agent com.sun.identity.agents.config.receive.timeout parameter had to be increased (by 4 seconds by default).

Fortunately, since AD 2012 R2, there’s a new feature available—a base search from the user’s DN (the LDAP DN of the user in AD) with a filter of
“(objectClass=user)”. Requesting the msds-memberoftransitive attribute will return the whole of the user’s groups, including the parent groups of the nested groups a user is member of. That search can be configured from the AM console.

You can find more information about that attribute here: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/c5c7d019-8d88-4bfa-b84d-4413bbf189b5

Also, our bug tracker holds a reference to that issue: https://bugster.forgerock.org/jira/browse/OPENAM-9674

But from now on, you should hopefully be able to leverage AD nested groups gracefully with AM.

Proof of Concept

This article is an overview of a proof of concept (PoC) we recently completed with one of our partners. The purpose was to demonstrate the ability to use the ForgeRock Identity platform to quickly provide rich authentication (such as biometric authentication by face recognition), and authorization capabilities to a custom mobile application, written from scratch.

Indeed, it took about two weeks to develop and integrate the mobile application with the ForgeRock Identity platform, thanks to the externalization of both the registration and the authentication code, and logic out the mobile application itself. The developers had to mostly use the ForgeRock REST API’s to implement these features.

Some important facts: 

  • While the authentication leveraged the ForgeRock REST API and authentication trees, the device registration was implemented using a mobile SDK provided by the biometric vendor. Another option could have been to use an existing ForgeRock authentication tree node for the registration, but it would have required the use of a browser. The ideal goal was to provide all the features using a single, custom mobile application for a better user experience.
  • It was decided to use Daon as the biometric authentication solution provider/vendor, even though the ForgeRock Identity platform can be integrated with other authentication solutions. The ForgeRock marketplace is a good place to figure out what’s available for whatever type of authentication you’re looking for.
  • Depending on the solution, we may or may not provide a node for user or device registration. When not available, it can be either developed, or the vendor will provide an SDK to implement registration directly with them.
  • Daon provides two different ways to manage user credentials; they can be left on the user’s device, leveraging the FIDO protocol, or they can be stored in a specific tenant on the Daon’s Identity X server. For that PoC, we chose to use the FIDO protocol, because we wanted to provide the best user experience. So, for example, with as little network latency as possible, and checking a face locally on a mobile device looked faster than having to send it (or a hash of it or so) to a server for verification.

The functional objectives of that PoC were to provide:

  • A way for the mobile application to dynamically discover the available authentication methods, rather than hardcoding or defining in the application configuration the list of methods. We did that using an authentication tree which included three authentication methods, and the ForgeRock Access Management REST API and callbacks to discover the available choices.
  • A way to provide different authentication choices based on some criteria, such as the domain of the user’s email address and the status of that user (already registered in the authentication platform or not).
  • The ability to deliver OTPs by either SMS or email, based on the user’s profile. A user profile including a mobile phone number had to trigger the OTP delivery by SMS, and by email without a filled mobile phone number.
  • Biometric authentication by face recognition, embedded in the custom mobile application, thus providing the best possible user experience, without the need to rely on an extra browser session or additional device.
  • Biometric-enabled device registration: Not only was the face recognition was at authentication time, it was also used for the device registration.
  • OAUTH 2 access tokens delivery, introspection, and usage to gain access to business APIs.
  • Protection of the APIs by authorization rules and the ForgeRock authorization engine.

The PoC logical architecture was as follows:

The authentication trees looked like this, with the first couple of screenshots showing the main tree, and the third screenshot showing the biometric authentication tree, embedded in the main tree:

In the main tree, we used a few custom JavaScript scripted nodes to implement the desired logic; for example, to expose different authentication choices based on the user’s email address domain:

Below, you can see the registration flow diagram:

  • The relying party app is the custom mobile application developed during the PoC.
  • The FIDO client in our case was the Daon’s mobile SDK running in the mobile app. That SDK is especially responsible for triggering the camera to take a picture of the user’s face.
  • The relying party server is ForgeRock Access Management.
  • The FIDO server is Daon’s Identity X server:

The depicted registration flow above is actually the one that occurs when using a browser and the ForgeRock registration node for Daon. When using a custom mobile app and the Daon mobile SDK, the registration request and responses go directly from the mobile application to the Daon’s Identity X server, so without going through ForgeRock Access Management.

On the contrary, the authentication flow always goes through ForgeRock Access Management, leveraging the nodes developed for that purpose:

Feel free to ask for questions for more details!

Overview of Options of Authentication By Face Recognition in ForgeRock Identity Platform

The following table provides solution designers and architects with a comparative overview of the different options available as of today to for authentication by face recognition to a ForgeRock Identity platform deployment.

The different columns represent some important criteria to consider when one searches for such a solution, some criteria is self-explanatory while the others are detailed below:

  • The Device agnostic column helps to figure out which type of device can be used (any vs a subset).
  • The Requires a 3rdparty solution column indicates whether or not other software is required in addition to the ForgeRock platform.
  • The Security column represents the relative level of security brought by the solution.
  • The ForgeRock supported column represents the level of effort required to integrate the solution.
  • Flows: That criteria gives an idea, from the user’s perspective (rather than from a purely technical perspective), of whether registration and/or authentication occurs with or without friction. As a rule of thumb, in band flows, it can be considered as frictionless (or so, since it involves use cases where a user needs a single device or uses a single browser session), while out of band flows can be seen as more secure (in some contexts at least), since different channels are involved. Some exceptions may exist, such as Face ID, which can be used in a purely mobile scenario (so, rather in band-like) or just as a means to register or authenticate on one side with a mobile device, while accessing a website or service from another device.