Identity Workflow with AM using Zeebe and Cloud Functions

**** Please note that this is only a sample. The statements, examples or code in this post are not supported by ForgeRock. ****

Functions as a Service

Serverless computing has emerged as a new and compelling paradigm for the deployment of cloud applications. Offering a true “utility” model for software, developers do not need to worry about low-level details of server management and scaling, and only pay for when processing requests or events.

The most natural way to use serverless computing is to provide a piece of code (function) to be executed by the serverless computing platform. This is where Functions-as-a-Service (FaaS) come in to the picture, allowing small pieces of code to run for limited amount of time (minutes) with executions triggered by events (or HTTP requests) and not allowed to keep persistent state.

From a cost perspective, the benefits of a serverless architecture are most apparent for bursty workloads, because the developer offloads the elasticity of the function to the platform.

Zeebe: Workflow as a Service

Zeebe is a cloud-native workflow engine for BPMN style process automation. It is also Camunda’s open source workflow orchestration engine. With Zeebe, you can define workflows graphically in BPMN 2.0 with the Zeebe Modeler.

Workflows built in Zeebe can react to events from messaging platforms. Zeebe can scale horizontally to handle very high throughput, and provides fault tolerance. There is state representation or state persistence in Zeebe.

Zeebe architecture, taken from their documentation site, is shown below:

The gateway, which proxies requests to brokers, serves as a single entry point to a Zeebe cluster. It is stateless and session-less. Zeebe cloud adds gateways as necessary for load balancing and high availability, thereby removing the burden from the developer of scaling the workflow engine.

The Zeebe broker is the distributed workflow engine that keeps state of active workflow instances. No application business logic lives in the broker. It is responsible for storing and managing the state of active workflow instances.

Zeebe uses BPMN 2.0 for representing workflows. BPMN is an industry standard which is widely supported by different vendors and implementations. Using BPMN ensures that workflows can be interchanged between Zeebe and other workflow systems.

Zeebe Basics

Sequences – In Zeebe, the simplest kind of BPMN workflow is an ordered sequence of tasks. Whenever workflow execution reaches a task, Zeebe creates a job that can be requested and completed by a job worker.

State Machine – Zeebe’s workflow orchestration operates like a state machine. A workflow instance reaches a task, and Zeebe creates a job that can be requested by a worker. Zeebe then waits for the worker to request a job and complete the work. Once the work is completed, the flow continues to the next step. If the worker fails to complete the work, the workflow remains at the current step, and the job could be retried until it’s successfully completed.

Data Flow – As Zeebe progresses from one task to the next in a workflow, it can move custom data in the form of variables. Variables are key-value-pairs and part of the workflow instance.

Parallel Gateway – With Zeebe, you can use the Fork / Join concurrency available with parallel gateways to perform multiple tasks in parallel.

Enforcing Gateway – For implementing data-based Conditions, you can have some workflow nodes choose between different tasks based on variables and conditions. The diamond shape with the “X” in the middle is an element indicating that the workflow decides to take one of many paths.

Onboarding Workflow

For reference, the BPMN workflow used in the example is shown below:

Sample Integration with ForgeRock

This blog post demonstrates invoking an on-boarding BPMN workflow from ForgeRock AM.

Google Cloud Functions

I used the serverless framework to setup my cloud functions in GCP. Each cloud function implements a discrete piece of business logic without storing any state whatsoever. Each cloud function is invoked separately by a specific BPMN workflow node from the Zeebe Cluster (discussed next).

A snippet from the serverless.yml file shows the definition of the create-account cloud function with a handler “createAccount”. My GCP project will host this cloud function at the specific handler.

Running serverless deploy will create the cloud function from the index.js file, from which a quick sample is pasted below:

const body = req.body;
let responseBody;
responseBody = JSON.stringify({
success: true,
cMessage: 'Create successful'
res.status(200).send( responseBody );

Here I am simply returning success from the cloud function. As such, the workflow node should receive a body.success parameter, which it could map to an output parameter, say success to pass along to the next workflow node.

To complete the API composer pattern, we will also create a cloud function that serves to initiate the workflow. This way the initiator of the workflow does not need to know the specifics of the root workflow node.

const ZB = require('zeebe-node')
module.exports.customerOnboarding = async (req, res) => {
const body = req.body;
const zbc = new ZB.ZBClient({
camundaCloud: {
clientId: "yXtccn6lWclShJGUQ1aRSfrhJZikYang",
clientSecret: "<bleeped>",
clusterId: "0263777a-114c-4d2f-9445-47a2290b0320",
cacheOnDisk: false
const result = await zbc.createWorkflowInstanceWithResult('CustomerOnboarding', body);
const responseBody = JSON.stringify({
message: 'onboarding started',
data: result
res.status(200).send( responseBody );

The initiator cloud function is able to instantiate the workflow in one of two modes: async, or await. I chose to use the latter in order to receive a workflow processing outcome.

Deployed in GCP:

customerOnboarding will be invoked by our Authentication Tree from AM. createAccount will be invoked by the service task of the same name from inside our BPMN workflow running on a Zeebe workflow cluster. Read on!

Zeebe Cluster

I also created a free Zeebe cluster on the public Camunda cloud, and set it up for HTTP access:

The Zeebe cluster can be invoked over HTTP as depicted by the HTTP worker “job type”. I also defined a worker variable that will serve as the web address for the cloud functions used by the worker nodes to invoke relevant business logic.

The BPMN workflow was modeled using the Zeebe Modeler. The picture below is from Camunda Operate, which offers a cool dashboard to visualize in-flight, completed and failed workflow instances.:

Each “service task”, or worker node must be configured for input/output parameters and headers that must be supplied to it by the root node. The workflow operates like a state machine, with each successive node using the context of the operation to make decisions. In the configuration settings for each node, things that can be passed under “Input parameters” include the request body and those under “Output parameters” can include information needed for successor nodes to correctly operate. An example for input and output parameters, and headers is shown using the createAccount node:

The success output parameter is also the state of the workflow if set by the last worker node! You will see later that this workflow outcome is used by the Authentication Tree to decide whether to authenticate a user or not.

The headers passed into the worker node will be used by the worker node to invoke the cloud function responsible for executing the node’s business logic. In this case, it would be the google cloud function createAccount specified in the serverless.yml file in the previous section. Also, notice the body.success being mapped to a workflow variable, called success. The success variable is used by the “certified?” Enforcing Gateway to determine whether manual review is needed, or if it is okay to finish on-boarding the customer.

Let’s look at the configuration for one of the SequenceFlows, the outbound connectors from the “certified?” Enforcing Gateway:

The SequenceFlow connector labelled Yes only triggers if the workflow variable success evaluates to true, otherwise the alternate flow is triggered resulting in a manual review.

AM Integration

First. I created a workflow script, which is responsible for building out the request body with user and context data. It calls our workflow-initiator cloud function:

Next, I set up a really simple authentication tree called WorkflowLogin to use the workflow script. This is just to demonstrate use. The use case is that the user must be on-boarded before they can be authenticated and given a session by AM. As mentioned earlier, the Zeebe workflow is able to return a workflow outcome in the form of result.get("variables").get("status"), which can be checked for by in the scripted decision node.

A simple dry run from the CLI directly invoking the customerOnboarding initiator cloud function shows how to manually send an HTTPS request to the workflow initiator cloud function:

curl -H "Content-Type: application/json" -X PUT -d @request-zeebe.json https://<bleeped> | jq

  "message": "onboarding started",
"result": {
   "workflowKey": "2251799813746599",
   "bpmnProcessId": "CustomerOnboarding",
  "version": 1,
   "workflowInstanceKey": "2251799813757247",
   "variables": {
     "body": {
       "success": true,
       "cMessage": "welcome email successful"
     "success": true,
     "statusCode": 200,
     "attributeValues": "joe, black, 999881"

Similarly, invoking the authentication tree directly from the CLI presents a similar response:

curl --request POST --header "Accept-API-Version: resource=2.0, protocol=1.0" --header "Content-Type: application/json" --header "X-OpenAM-Username: demo" --header "X-OpenAM-Password: <>" '' | jq'


This completes the demonstration of invoking a powerful cloud workflow engine, Zeebe from an authentication tree in AM via Google Cloud Functions. Leave your thoughts and comments below..

Thanks for reading!

ForgeRock Identity Microservices with Consul on OpenShift


Openshift, a Kubernetes-as-a-Paas service, is increasingly being considered as an alternative to managed kubernetes platforms such as those from Tectonic, Rancher, etc and vanilla native kubernetes implementations such as those provided by Google, Amazon and even Azure. RedHat’s OpenShift is a PaaS that provides a complete platform which includes features such as source-2-image build and test management, managing images with built-in change detection, and deploying to staging / production.

In this blog, I demonstrate how ForgeRock Identity Microservices could be deployed into OpenShift Origin (community project).

OpenShift Origin Overview

OpenShift Origin is a distribution of Kubernetes optimized for continuous application development and multi-tenant deployment. OpenShift adds developer and operations-centric tools on top of Kubernetes to enable rapid application development, easy deployment and scaling, and long-term lifecycle maintenance for small and large teams.

OpenShift embeds Kubernetes and extends it with security and other integrated concepts. An OpenShift Origin release corresponds to the Kubernetes distribution – for example, OpenShift 1.7 includes Kubernetes 1.7

Docker Images

I described in this blog post how I built the envconsul layer on top of the image for the Authentication microservice, and similarly for the token-validation and token-exchange micro services. Back then I took the easy route and used the vbox (host) IP for exposing the Consul IP address externally to the rest of the microservices pods.

This time however, I rebuilt the docker images using a modified version of the script which is of course, used as the ENTRYPOINT as seen in my github repo. I use an environment variable called CONSUL_ADDRESS in the script instead of a hard coded virtualbox adapter IP. The latter works nicely for minikube deployments, but of course, is not production friendly. However, with the env variable we move much closer to a production grade deployment.

How does OpenShift Origin resolve the environment variable on container startup? Read on!

OpenShift Origin Configuration

I have used minishift for this demonstration. More info about minishift can be found here. I started up Openshift Origin using these settings:
minishift start --openshift-version=v3.10.0-rc.0
eval $(minishift oc-env)
eval $(minishift docker-env)
minishift enable addon anyuid

The anyuid addon is only necessary when you have containers that must be run as root. Consul is not one of those, but most docker images rely on root, including the microservices, so I decided to set it as such anyway.

Apps can be deployed to OC in a number of ways, using the web console or the oc CLI. The main method I used is to use an existing container image hosted on the Bintray ForgeRock repository as well as the Consul image on Docker Hub.

The following command creates a new project:

$oc new-project consul-microservices --display-name="Consul based MS" --description="consul powered env vars"

At this point we have a project container for all our OC artifacts, such as deployments, image streams, pods, services and routes.

The new-app command can be used to deploy any image hosted on an external public or private registry. Using this command, OC will create a deployment configuration with a rolling strategy for updatesz. The command shown here will deploy the Hashicorp Consul image from docker hub (the default repository OC looks for). OC will download the image and store it into an internal image registry. The image is then copied from there to each node in an OC cluster where the app is run.

$oc new-app consul --name=consul-ms

With the deployment configuration created, two triggers are added by default: a ConfigChange and ImageChange which means that each deployment configuration change, or image update on the external repository will automatically trigger a new deployment. A replication controller is created automatically by OC soon after the deployment itself.

Make sure to add a route for the Consul UI running at port 8500 as follows:

I have described the Consul configuration needed for ForgeRock Identity Microservices in my earlier blog post on using envconsul for sourcing environment configuration at runtime. For details on how to get the microservices configuration into Consul as Key-Value pairs please refer to that post. A few snapshots of the UI showing the namespaces for the configuration are presented here:


A sample key value used for token exchange is shown here:

Next, we move to deploying the microservices. And in order for envconsul to read the configuration from Consul at runtime, we have the option of passing an --env switch to the oc new-app command indicating what the value for the CONSUL_ADDRESS should be, or we could also include the environment variable and a value for it in the deployment definition as shown in the next section.

OpenShift Deployment Artifacts

If bundling more than one object for import, such as pod and service definitions, via a yaml file, OC expects strongly typed template  configuration, as shown here, for the ms-authn microservice. Note the extra metadata for template identification, and use of the objects syntax:


This template, once stored in OC, can be reused to create new deployments of the ms-authn microservice. Notice the use of the environment variable indicating the Consul IP. This informs the script of the location of Consul and envconsul is able to pull the configuration key-value pairs before spawning the microservice.

I used the oc new-app command in this demonstration insteed.

As described in the other blog, copy the configuration export (could be automated using GIT as well) into the Consul docker container:

$docker cp consul-export.json 5a2e414e548a:/consul-export.json

And then import the configuration using the consul kv command:

$consul kv import @consul-export.json
Imported: ms-authn/INFO_ACCOUNT_PASSWORD
Imported: ms-authn/ISSUER_JWK_STORE
Imported: ms-authn/TOKEN_AUDIENCE
Imported: ms-authn/TOKEN_ISSUER
Imported: ms-authn/TOKEN_SIGNATURE_JWK_BASE64
Imported: token-exchange/
Imported: token-exchange/EXCHANGE_JWT_INTROSPECT_URL
Imported: token-exchange/EXCHANGE_OPENAM_AUTH_SUBJECT_ID
Imported: token-exchange/EXCHANGE_OPENAM_AUTH_URL
Imported: token-exchange/EXCHANGE_OPENAM_POLICY_SET_ID
Imported: token-exchange/EXCHANGE_OPENAM_POLICY_URL
Imported: token-exchange/INFO_ACCOUNT_PASSWORD
Imported: token-exchange/ISSUER_JWK_JSON_ISSUER_URI
Imported: token-exchange/ISSUER_JWK_JSON_JWK_BASE64
Imported: token-exchange/ISSUER_JWK_OPENID_URL
Imported: token-exchange/ISSUER_JWK_STORE
Imported: token-exchange/METRICS_ACCOUNT_PASSWORD
Imported: token-exchange/TOKEN_EXCHANGE_POLICIES
Imported: token-exchange/TOKEN_EXCHANGE_REQUIRED_SCOPE
Imported: token-exchange/TOKEN_ISSUER
Imported: token-exchange/TOKEN_SIGNATURE_JWK_BASE64
Imported: token-validation/
Imported: token-validation/INFO_ACCOUNT_PASSWORD
Imported: token-validation/INTROSPECTION_OPENAM_CLIENT_ID
Imported: token-validation/INTROSPECTION_OPENAM_URL
Imported: token-validation/INTROSPECTION_REQUIRED_SCOPE
Imported: token-validation/INTROSPECTION_SERVICES
Imported: token-validation/ISSUER_JWK_JSON_ISSUER_URI
Imported: token-validation/ISSUER_JWK_JSON_JWK_BASE64
Imported: token-validation/ISSUER_JWK_STORE
Imported: token-validation/METRICS_ACCOUNT_PASSWORD

The oc new-app command used to create a deployment:
$oc new-app --env

This creates a new deployment for the authn microservice, and as described in detail in this blog, envconsul is able to reach the Consul server, extract configuration and set up the environment required by the auth microservice.


Commands for the token validation microservice are shown here:
$oc new-app --env

$oc expose svc/token-validation
route "token-validation" exposed

Token Exchange Microservice is setup as follows

$oc new-app --env

$oc expose svc/token-exchange
route "token-validation" exposed

Image Streams

OpenShift has a neat CI/CD trigger for docker images built in to help you manage your pipeline. Whenever the image is updated in the remote public or private repository, the deployment is restarted.

Details about the token exchange micro service image stream are shown here:

More elaborate Jenkins based pipelines can be built and will be demonstrated in a later blog!


Setup the env variables in Postman like so:

I have several tests in this github repo. An example of getting a new access token using client credentials from the authn microservice is shown here:


This was an introduction to using OpenShift with our micro services, and there is much more to come!

Runtime configuration for ForgeRock Identity Microservices using Consul

The ForgeRock Identity Microservices are able to read all runtime configuration from environment variables. These could be statically provided as hard coded key-value pairs in a Kubernetes manifest or shell script, but a better solution is to manage the configuration in a centralized configuration store such as Hashicorp Consul.

Managing configuration outside the code as such has been routinely adopted as a practice by modern service providers such as Google, Azure and AWS and business that use both cloud as well as on-premise software.

In this post, I shall walk you through how Consul can be used to set configuration values, envconsul can be used to read these key-values from different namespaces and supply them as environment variables to a subprocess. Envconsul can even be used to trigger automatic restarts on configuration changes without any modifications needed to the ForgeRock Identity Microservices.

Perhaps even more significantly, this post shows how it is possible to use Docker to layer on top of a base microservice docker image from the Forgerock Bintray repo and then use a pre-built go binary for envconsul to spawn the microservice as a subprocess.

This repo has all the docker and kubernetes artifacts needed to run this integration. I used a single cluster minikube setup.


Starting a Pod in Minikube

We must start with setting up consul as a docker container and this is just a simple docker pull consul followed by a kubectl create -f kube-consul.yaml that sets up a pod running consul in our minikube environment. Consul creates a volume called /consul/data on to which you can store configuration key-value pairs in JSON format that could be directly imported using consul kv import @file.json. consul kv export > file.json can be used to export all stored configuration separated into JSON blobs by namespace.

The consul commands can be run from inside the Consul container by starting  a shell in it using docker exec -ti <consul-container-name> /bin/sh

Configuration setup using Key Value pairs

The namespaces for each microservice are defined either manually in the UI or via REST calls such as:
consul kv put my-app/my-key may-value


Expanding the ms-authn namespace yields the following screen:

A sample configuration set for all three microservices is available in the repo for this integration here. Use consul kv import @consul-export.json to import them into your consul server.

Docker Builds

Base Builds

First, I built base images for each of the ForgeRock Identity microservices without using an ENTRYPOINT instruction. These images are built using the openjdk:8-jre-alpine base image which are the smallest alpine-based openjdk image one can possibly find. The openjdk7 and openjdk9 images are larger. Alpine itself is a great choice for a minimalistic docker base image and provides packaging capabilities using apk. It is a great choice for a base image especially if these are to be layered on top of like in this demonstration.

An example for the Authentication microservice is:
FROM openjdk:8-jre-alpine
WORKDIR /opt/authn-microservice
ADD . /opt/authn-microservice

The command docker build -t authn:BASE-ONLY builds the base image but does not start the authentication listener since no CMD or ENTRYPOINT instruction was specified in the Dockerfile.

The graphic below shows the layers the microservices docker build added on top of the openjdk:8-jre-alpine base image:

Next, we need to define a launcher script that uses a pre-built envconsul go binary to setup communication with the Consul server and use the key-value namespace for the authentication microservice.

/usr/bin/envconsul -log-level debug -consul= -pristine -prefix=ms-authn /bin/sh -c "$SERVICE_HOME"/bin/

A lot just happened there!

We instructed the launcher script to start envconsul with an address for the Consul server and nodePort defined in the kube-consul.yaml previously. The switch -pristine tells envconsul to not merge extant environment variables with the ones read from the Consul server. The -prefix switch identifies the application namespace we want to retrieve configuration for and the shell spawns a new process for the script which is an ENTRYPOINT instruction for the authentication microservice tagged as 1.0.0-SNAPSHOT. Note that this is not used in our demonstration, but instead we built a BASE-ONLY tagged image and layer the envconsul binary and launcher script (shown next) on top of it. The -c switch enables tracking of changes to configuration values in Consul and if detected the subprocess is restarted automatically!

Envconsul Build

With the script ready as shown above, it is time to build a new image using the base-only tagged microservice image in the FROM instruction as shown below:

MAINTAINER Javed Shah <>
COPY envconsul /usr/bin/
ADD /usr/bin/
RUN chmod +x /usr/bin/
ENTRYPOINT ["/usr/bin/"]

This Dockerfile includes the COPY instruction to add our pre-built envconsul go-binary that can run standalone to our new image and also adds the script shown above to the /usr/bin/ directory. It also sets the +x permission on the script and makes it the ENTRYPOINT for the container.

At this time we used the docker build -t authn:ENVCONSUL . command to tag the new image correctly. This is available at the ForgeRock Bintray docker repo as well.

This graphic shows the layers we just added using our Dockerfile instruction set above to the new ENVCONSUL tagged image:

These two images are available for use as needed by the repo.

Kubernetes Manifest

It is a matter of pulling down the correctly tagged image and specifying one key item, the hostAliases instruction to point to the OpenAM server running on the host. This server could be anywhere, just update the hostAliases accordingly. Manifests for the three microservices are available in the repo.

Start the pod with kubectl create -f kube-authn-envconsul.yaml will cause the following things to happen, as seen in the logs using kubectl logs ms-authn-env.

This shows that envonsul started up with the address of the Consul server. We deliberately used the older -consul flag for more “haptic” feedback from the pod if you will. Now that envconsul started up, it will immediately reach out to the Consul server unless a Consul agent was provided in the startup configuration. It will fetch the key-value pairs for the namespace ms-authn and make them available as environment variables to the child process!

The configuration has been received from the server and at this time envconsul is ready to spawn the child process with these key-value pairs available as environment variables:

The Authentication microservice is able to startup and read its configuration from the environment provided to it by envconsul.

Change Detection

Lets change a value in the Consul UI for one of our keys, CLIENT_CREDENTIALS_STORE from json to ldap:

This change is immediately detected by envconsul in all running pods:

envconsul then wastes no time in restarting the subprocess microservice:

Pretty cool way to maintain a 12-factor app!


A quick test for the OAuth2 client credential grant reveals our endeavor has been successful. We receive a bearer access token from the newly started authn-microservice.

The token validation and token exchange microservices were also spun up using the procedures defined above.

Here is an example of validating a stateful access_token generated using the Authorization Code grant flow using OpenAM:

And finally the postman call to the token-exchange service for exchanging a user’s id_token with an access token granting delegation for an “actor” whose id_token is also supplied as input is shown here:

The resulting token is:

This particular use case is described in its own blog.

Whats coming next?

Watch this space for secrets integration with Vault and envconsul!

Token Exchange and Delegation using the ForgeRock Identity Microservices

In 2017 ForgeRock introduced an Early Access program (aka beta) for the ForgeRock Identity Microservices. In summary the capabilities offered include token issuance using the OAuth2 client credentials grant, token validations of OAuth2/OIDC tokens (and even ssotokens) and token exchange based on the draft OAuth2 token exchange spec. I wrote a press release here and an introductory community blog post here.

In this article we will discuss how to implement delegation as per the OAuth2 Token Exchange  draft specification. An overview of the process is worth discussing at this point.

We basically first want to grab hold of an OAuth2 token for our client to use in an Authorization header when calling the Token Exchange service. Next, we need our Authorization Server such as ForgeRock Access Management in our example, to issue our friendly neighbors Alice and Bob their respective OIDC id_tokens. Note that Alice wants to delegate authority to Bob. While we shall show the REST calls to acquire those, the details of setting up the OAuth2 Provider will be left out. We shall however discuss the custom OIDC Claims Script for setting up the delegation framework for authenticated users, as well as the Policy that sets up allowed actors who may be chosen for delegation.

But first things first, so we start with acquiring a bearer authentication token for our client who will make calls into the Token Exchange service. This can be accomplished by having the Authentication microservice issue an OAuth2 access token with the exchange scope using the client-credentials grant_type. For the example we shall just use a JSON backend as our client repository, although the Authentication microservice supports using Cassandra, MongoDB, any LDAP v3 directory including ForgeRock Directory Services.

The repository holds the following data for the client:

 "clientId" : "client",
 "clientSecret" : "client",
 "scopes" : [ "exchange", "introspect" ],
 "attributes" : {}

The authentication request is:

POST /service/access_token?grant_type=client_credentials HTTP/1.1
Host: localhost:18080
Content-Type: multipart/form-data
Authorization: Basic ****
Cache-Control: no-cache

After client authenticates, the Authentication microservice issues a token that when decoded looks like this:

 "sub": "client",
 "scp": [
 "auditTrackingId": "237cf708-1bde-4800-9bcd-5db5b5f1ca12",
 "iss": "",
 "tokenName": "access_token",
 "token_type": "Bearer",
 "authGrantId": "a55f2bad-cda5-459e-8620-3e826bad9095",
 "aud": "client",
 "nbf": 1523058711,
 "scope": [
 "auth_time": 1523058711,
 "exp": 1523062311,
 "iat": 1523058711,
 "expires_in": 3600,
 "jti": "39b72a84-112d-46f3-a7cb-84ce7513e5bc",
 "cid": "client"

Bob, the actor, authenticates with AM and receives id_token:

 "at_hash": "Hgjw0D49EfYM6dmB9_K6kg",
 "sub": "user.1",
 "auditTrackingId": "079fda18-c96f-4c78-90f2-fc9be0545b32-111930",
 "iss": "http://localhost:8080/openam/oauth2",
 "tokenName": "id_token",
 "aud": "oidcclient",
 "azp": "oidcclient",
 "auth_time": 1523058714,
 "realm": "/",
 "may_act": {},
 "exp": 1523062314,
 "tokenType": "JWTToken",
 "iat": 1523058714

Alice, the user also authenticates with AM and receives a special id_token:

 "at_hash": "nT_tDxXhcee7zZHdwladcQ",
 "sub": "user.0",
 "auditTrackingId": "079fda18-c96f-4c78-90f2-fc9be0545b32-111989",
 "iss": "http://localhost:8080/openam/oauth2",
 "tokenName": "id_token",
 "aud": "myuserclient1",
 "azp": "myuserclient1",
 "auth_time": 1523058716,
 "realm": "/",
 "may_act": {
     "sub": "Bob"
 "exp": 1523062316,
 "tokenType": "JWTToken",
 "iat": 1523058716

Why does Alice receive a may_act claim but Bob does not? This has to do with Alice’s group membership in DS. The OIDC Claims script attached to the OAuth2 Provider in AM checks for membership to this group, and if found retrieves a value for the assigned “actor” or delegate. In this case Alice’s has designed actor status to Bob (via some out of band method, such as on a user portal, for example). The script retrieves the actor and sets a special claim with its value: may_act. The claims script is shown here in part:

def isAdmin = identity.getMemberships(IdType.GROUP)
.inject(false) { found, group ->
found ||
group.getName() == “policyEval”

//…search for actor.. not shown

def mayact = [:]
if (isAdmin) {

Next, we must define a Policy in AM. This policy could be based on OAuth2 scopes or URI, whatever you choose. I chose to setup an OAuth2 Scopes policy but whatever scope you choose must match the resource you pass into the TE service. Rest of the policy is pretty standard, for example, here is a summary of the Subject tab of the policy:

  "type": "JwtClaim",
  "claimName": "iss",
  "claimValue": "http://localhost:8080/openam/oauth2"

I am checking for an acceptable issuer, and thats it. This could be replaced with a subject condition for Authenticated users as well although the client would then have to send in Alice’s “ssotoken” as the subject_token instead of her id_token when invoking the TE service.

This also implies that delegation is “limited” to the case where you are using a JWT for Alice, preferably an OIDC id_token. We cannot do delegation without a JWT because the TE depends on the presence of a “may_act” claim in Alice’s subject_token. When using only an ssotoken or an access_token for Alice we cannot pass in this claim to the TE service. Hopefully thats clear as mud now (laughter).

Anyway.. back to the policy setup in AM. Keep in mind that the TE service expects certain response attributes: “aud” and “scp” are mandatory. “allowedActors” is optional but needed for our discussion of course. It contains a list of allowed actors and this list could be computed based on who the subject is. One subject attribute must also be returned. A simple example of response attributes could be:

scp: read,write
allowedActors: Bob
allowedActors: HelpDeskAdministrator
allowedActors: James

The subject must also be returned from the policy and one way to do that is to parse the id_token and return the sub claim as a response attribute. A scripted policy condition attached to the Policy Environment extracts the sub claim and returns it in the response.

This policy script is attached as an environment condition as follows:

The extracted sub claim is then included as a response attribute.

At this point we are ready to setup the Token Exchange microservice to invoke the Policy REST endpoint in AM for resource-match, allowed actions and subject evaluation. Keep in mind that the TE service supports pluggable policy backends – a really powerful feature – using which one could have specific “pods” of microservices running local JSON-backed policies, other “pods” could have Open Policy Agent (OPA)-powered regex policies and yet another set of “pods” could have the TE service calling out to AM’s policy engine for evaluation.

The setup for when the TE is configured for using AM as the token exchange policy backend  looks like this:

 // Credentials for an OpenAM "subject" account with permission to access the OpenAM policy endpoint
 "authSubjectId" : "&{EXCHANGE_OPENAM_AUTH_SUBJECT_ID|service-account}",
 "authSubjectPassword" : "&{EXCHANGE_OPENAM_AUTH_SUBJECT_PASSWORD|****}",

// URL for the OpenAM authentication endpoint, without query parameters
 "authUrl" : "&{EXCHANGE_OPENAM_AUTH_URL|http://localhost:8080/openam/json/authenticate}",

// URL for the OpenAM policy-endpoint, without query parameters
 "policyUrl" : "&{EXCHANGE_OPENAM_POLICY_URL|http://localhost:8080/openam/json/realms/root/policies}",

// OpenAM Policy-Set ID
 "policySetId" : "&{EXCHANGE_OPENAM_POLICY_SET_ID|resource_policies}",

// OpenAM policy-endpoint response-attribute field-name containing "audience" values
 "audienceAttribute" : "&{EXCHANGE_OPENAM_POLICY_AUDIENCE_ATTR|aud}",

// OpenAM policy-endpoint response-attribute field-name containing "scope" values
 "scopeAttribute" : "&{EXCHANGE_OPENAM_POLICY_SCOPE_ATTR|scp}",

// OpenAM policy-endpoint response-attribute field-name containing the token's "subject" value
 "subjectAttribute" : "&{EXCHANGE_OPENAM_POLICY_SUBJECT_ATTR|uid}",

// OpenAM policy-endpoint response-attribute field-name containing the allowedActors
 "allowedActorsAttribute" : "&{EXCHANGE_OPENAM_POLICY_ALLOWED_ACTORS_ATTR|may_act}",

// (optional) OpenAM policy-endpoint response-attribute field-name containing "expires-in-seconds" values
 "expiresInSecondsAttribute" : "&{EXCHANGE_OPENAM_POLICY_EXPIRES_IN_SEC_ATTR|}",

// Set to "true" to copy additional OpenAM policy-endpoint response-attributes into generated token claims
 "copyAdditionalAttributes" : "&{EXCHANGE_OPENAM_POLICY_COPY_ADDITIONAL_ATTR|true}"

The TE services checks the response attributes shown above in the policy evaluation result in order to setup claims in the signed JWT it returns to the client.

The body of a sample REST Policy call from the TE service to an OAuth2 scope policy defined in AM looks like as follows:

 "subject" : {
     "jwt" : "{{AM_ALICE_ID_TOKEN}}"
 "application" : "resource_policies",
 "resources" : [ "delegate-scope" ]

Policy response returned to the TE service:

 "resource": "delegate-scope",
 "actions": {
     "GRANT": true
 "attributes": {
     "aud": [
     "scp": [
     "uid": [
     "allowedActors": [
 "advices": {},
 "ttl": 9223372036854775807

Again, whatever resource type you choose for the policy in AM, it must match the resource you pass into the TE service as shown above.

We have come far and if you are still with me, then it is time to invoke the TE service and get back a signed and exchanged JWT with the correct “act” claim to indicate delegation was successful. The decoded JWT claims set of the issued token is shown below. The new JWT is issued by the Token Exchange service and intended for consumption by a system entity known by the logical name “” any time before its expiration. The subject “sub” of the JWT is the same as the subject of the subject_token used to make the request.

 "sub": "Alice",
 "aud": "",
 "scp": [
 "act": {
     "sub": "Bob"
 "iss": "",
 "exp": 1523087727,
 "iat": 1523084127

The decoded claims set shows that the actor “act” of the JWT is the same as the subject of the “actor_token” used to make the request. This indicates delegation and identifies Bob as the current actor to whom authority has been delegated to act on behalf of Alice.

The OAuth2 ForgeRock Identity Microservices

ForgeRock Identity Microservices

ForgeRock released in Q4 2017, an Early Access (aka beta) program for three key Identity Microservices within a compact, single-purpose code set for consumer-scale deployments. For companies who are deploying stateless Microservices architectures, these microservices offer a micro-gateway enabled solution that enables service trust, policy-enforced identity propagation and even OAuth2-based delegation. The stateless architecture of FR Identity Microservices allows for implementing a sidecar-friendly microgateway deployment pattern.

I blogged about it here. The sign up form is here.

The Microservices

OAuth2 Token Issuance

Enables service to service authentication using client-credential grant type. These “bearer” tokens facilitate trust up and down the call chain.

We currently support RSA, EC, and HMAC signing, with the following algorithms:

  • HS256
  • HS384
  • HS512
  • RS256
  • ES256
  • ES384
  • ES512

Token Validation

Supports introspection of OAuth2 / OIDC tokens issued by an OAuth2 AS as well as native AM tokens. Token validations performed using either configured keys, or lookup via JWK URI for issuer and kid verification.

One or more Token Introspection API implementations can be configured by setting the value to a comma-separated list of implementation names. Each implementation is given a chance to handle the token, in given order, until an implementation successfully handles the token. An error response occurs if no implementation successfully introspects a given token.

The following implementations are provided:

  • json : Configured by a JSON file.
  • openam : Proxies introspect calls to ForgeRock Access Management.

Token Exchange

Supports exchanging stateless OAuth2 access tokens and native AM tokens for hybrid tokens that grant specific entitlements per resourceor audience requested. Implements the draft OAuth2 token-exchange specification. Offers no-fuss declarative (“local”) policy enforcement inside the pod without needing to “call home” for identity data. Also provides policy based entitlement decisions by calling out to ForgeRock Access Management.

The Token-Exchange Policy is a pluggable service which determines whether or not a given token exchange may proceed. The service also determines what audience, scope, and so forth the generated token will have. The following implementations are provided:

  • json (default) : Configured by a JSON file.
  • jwt : Simply returns a JWT for any token that can be introspected.
  • openam : Uses a ForgeRock Access Management Policy Set.

Cloud and Platform

Docker and Kubernetes

Dockerfile is bundled with the binary. Soon there will be a docker repository from where the images could be pulled by evaluators.

A Kubernetes manifest is also provided that demonstrates using environment variables to configure a simple demo instance.

Metrics and Prometheus Integration

The microservices are instrumented to publish basic request metrics and a Prometheus endpoint is also provided, which is convenient for monitoring published metrics.

Audit Tracking

Each incoming HTTP request is assigned a transaction ID, for audit logging purposes, which by default is a UUID. ForgeRock Microservices like other products support propagation of a transaction ID between point-to-point service calls.

Cloud Foundry

The standard binary in Zip format is also directly deploy-able to Cloud Foundry, and will get recognized by the Cloud Foundry Java build pack as a “dist zip” format.

Client Credential Repository

ForgeRock Identity Microservices support Cassandra, MongoDB, any LDAP v3 including ForgeRock Directory Services.

SiteMinder Policy conversion to OpenAM XACML

In this article I discuss migrating SiteMinder policies to OpenAM. I have laid out an approach and framework to make the conversion possible using XML parsing, XML codifying and custom metadata that is necessary to resolve embedded repository externalities in the SiteMinder policy definition. I have also written a Java-based program that uses the methodology discussed in this article to parse through the SiteMinder policy and resolve each policy construct to an OpenAM equivalent policy object. The program codifies the XACML output step-by-step and on completion, one is able to import the XACML policy set into OpenAM via the policy editor.

There are going to be some complications in your situation such as when converting whitelisted resource URI – that SiteMinder does not ‘trap’ in the policy definition- you will need to know which URI are not in your SM policy extract and allowed by default, and then go about creating or adding the same URI in a new or ‘converted’ OpenAM policy. You would then need to whitelist those URI by explicitly allowing access in OpenAM.

I begin by describing the general layout of an XPS domain export at a high level, and how different policy constructs in a SiteMinder policy map over to OpenAM.

Survey of SiteMinder Policy Objects

While there is not a one-to-one mapping for every policy construct, there is a logical mapping that is useful to achieve a first pass on the conversion. Some of the complications are elaborated on below.

CA.SM::Domain -> OpenAM Policy Set Definition

The CA.SM::Domain object is the parent object to several domain-specific properties such as Mode, Name and UserDirectoriesLink references. Nested directly under the Domain object are CA.SM::Realm,  CA.SM::Policy and CA.SM::Response objects.

CA.SM::Realm -> OpenAM Policy Resources

The Realm object includes properties that describe the AgentGroupLink and AuthScheme settings, session properties such as IdleTimeout, and among other things, the ResourceFilter that is the protected resource URI. Realm also contains a nested object, called the CA.SM::Rule with an associated XID that describes the Actions available for the ResourceFilter- such as GET, PUT and POST- and properties that describe regular expression matching, time restrictions, resource pattern and IsEnabled among other things.

CA.SM::Response -> OpenAM Response Attributes

Response object is a container for one or more name-value pairs, or ‘response attributes’ expected by the agent. These can be of type Web agent responses or RADIUS responses. This conversion article and the Java program are limited to handling only the Web agent responses currently.

The Response object has an associated XID, and includes properties that describe the authorization conditions when the response is applicable- such as AccessAccept and AccessChallenge- and properties for AgentTypeLink and Name.


Response also nests CA.SM::ResponseAttr objects, each with a unique XID, that each have properties for AgentTypeAttrLink- pointing to ReferenceObjects such as “WebAgent-HTTP-Header-Variable” indicating the means of transport for the response attributs- and also the Value of the response codified in the form of display-name=<%userattr=”profile-attribute-name”%>. Here it is assumed that the value is sourced from a user attribute, which is mostly the case, although several types of ResponseAttrs are possible, including user attribute as already mentioned, DN Attribute, Static values, Session Variable, etc.

CA.SM::Policy -> OpenAM Policy Definition

Nested under the Domain object, and at peer level to the Realm and Response objects is the CA.SM::Policy object that serves to tie together protected resource URI to the corresponding user audience, rules including actions, response objects and optionally, IP address restrictions and time restrictions for those URI.


The Policy object container has one or more CA.SM::PolicyLink objects that can be thought of as associations between the protected resources and the responses configured for each of them. The PolicyLink objects each have CA.SM::ResponseLink and CA.SM::RuleLink properties.

CA.SM::ResponseLink and CA.SM::RuleLink

The ResponseLink is a pointer to the Response object definition, and the RuleLink is a pointer to the Rule definition stored inside a CA.SM::Realm object. When invoked for a specific Realm, the policy enforces the Rule Actions as well as the Response attributes in case the policy evaluation is successful.


The Policy object also contains one or more CA.SM::UserPolicy objects that can be thought of as audience restriction conditions. The UserPolicy object has properties defining the FilterPath, which is a SQL query but one that could be used to locate a set of users this policy applies to. Another property is the UserDirectoryLink that is a pointer to the external repository that contains the user profile data, and specifically stores the XID of the ReferenceObject by the name CA.SM::UserDirectory.


Besides Domain objects, there are also reference objects at a peer level to Domain. The Reference object tree encapsulates all external information that the policy references.


The user repository information is stored under the CA.SM::UserDirectory ReferenceObject that includes a NameSpace attribute- such as “ODBC:”- and Server name. As mentioned previously the UserPolicy object stores a reference to the UserDirectory object using a UserDirectoryLink.

The program relies on these user directory references to be resolved using a metadata container in OpenDJ.


The AgentGroup object refers to the SiteMinder agent configurations that all protect the same resources. The attribute AgentTypeLink contains a value that is referenced from CA.SM::Response objects using the AgentTypeLink property tying the web agent to that particular response object. There could be one or more Agent Groups.


One or more of these Reference objects define in what form the agent expects the response objects to be returned. Two currently supported, and commonly used, values include “WebAgent-HTTP-Header-Variable” and “WebAgent-HTTP-Cookie-Variable”. These are available for use in accept or reject responses only in SiteMinder.

Some other Reference objects include CA.SM::AgentType, which describes the SM agent- basically a Web Agent. Another is the CA.SM::AuthScheme which includes details about the form of authentication such as Forms-based, Basic auth or API.

Conversion to OpenAM

Converting CA.SM::Domain and CA.SM::Realm objects

Simply parse out these objects from the SiteMinder policy extract and create OpenAM policy set XACML definitions.

A code sample to establish the proper order and parity between the XACML elements is shown here:

        Element target = doc.createElementNS("ns2", "ns2:Target");
 	Element anyOf_subject = getAnyOfSubjectTree(doc, xmlMap);

 	Element anyOf_resource = getAnyOfResourceTree(doc, xmlMap, resourceUri);
  	Element anyOf_application = getAnyOfApplicationTree(doc, xmlMap);
       	Element anyOf_action = getAnyOfActionTree(doc, xmlMap, actions);

A code sample for creating the Resource URI in XACML format is shown below:

private static Element getAnyOfResourceTree(Document doc, Map<String, String> xmlMap, List resourceUri) {
// many AnyOf elements to define subject, resources, actions, etc
  	Element anyOf = doc.createElementNS("ns2", "ns2:AnyOf");
  	for(String url : resourceUri) {
		Element allOf = doc.createElementNS("ns2", "ns2:AllOf");
		Element Match = doc.createElementNS("ns2", "ns2:Match");
		Match.setAttribute("MatchId", "urn:sun:opensso:entitlement:resource-match:application:"+xmlMap.get("PolicyId"));
	       	Element AttributeValue = doc.createElementNS("ns2", "ns2:AttributeValue");
                AttributeValue.setAttribute("DataType", "");
                AttributeValue.setTextContent("*://*:*" + url);
	       	Element AttributeDesignator = doc.createElementNS("ns2", "ns2:AttributeDesignator");
	       	AttributeDesignator.setAttribute("Category", "urn:oasis:names:tc:xacml:3.0:attribute-category:resource");
	       	AttributeDesignator.setAttribute("AttributeId", "urn:oasis:names:tc:xacml:1.0:resource:resource-id");
	       	AttributeDesignator.setAttribute("MustBePresent", "true");
	       	AttributeDesignator.setAttribute("DataType", "");
	return anyOf;

Converting the CA.SM::Rule.Actions objects

Here the challenge is to convert the ResourceFilters into ResourceURI objects in the XACML definition, and then add the relevant actions to those resource URI as defined in the CA.SM::Realm object definition. A sample method that adds basic actions to a policy is shown here:

private static Element getAnyOfActionTree(Document doc, Map<String, String> xmlMap, List actions) {
	// many AnyOf elements to define subject, resources, actions, etc
  		Element anyOf = doc.createElementNS("ns2", "ns2:AnyOf");
  		for(String action : actions) {
      		Element allOf = doc.createElementNS("ns2", "ns2:AllOf");
  		Element Match = doc.createElementNS("ns2", "ns2:Match");
  		Match.setAttribute("MatchId", "urn:sun:opensso:entitlement:action-match:application:"+xmlMap.get("PolicyId"));
	       	Element AttributeValue = doc.createElementNS("ns2", "ns2:AttributeValue");
	       	AttributeValue.setAttribute("DataType", "");
	       	Element AttributeDesignator = doc.createElementNS("ns2", "ns2:AttributeDesignator");
	       	AttributeDesignator.setAttribute("Category", "urn:oasis:names:tc:xacml:3.0:attribute-category:action");
	       	AttributeDesignator.setAttribute("AttributeId", "urn:oasis:names:tc:xacml:1.0:action:action-id");
	       	AttributeDesignator.setAttribute("MustBePresent", "true");
	       	AttributeDesignator.setAttribute("DataType", "");
  	return anyOf;

Converting Policy bindings for CA.SM::Real,  CA.SM::Response and CA.SM::UserPolicy objects

This portion is the most complex in the conversion because linkages have to be parsed out of the SiteMinder policy extract and rendered as separate OpenAM policies in XACML format. In order to convert a CA.SM::Policy object the program needs to follow the following algorithm at the very at least and in order:

  1. Establish the linkages between the CA.SM::Realm objects and the CA.SM::Response objects using the PolicyLink binder object
  2. Resolve the Response object, dynamic key-value pairs, by either directly reading the data from an external repository, or converting the references attributes to LDAP specific attributes
  3. Resolve the Subject Restrictions manifest in the PolicyLink.UserPolicy by converting the SQL Query to an LDAP search filter
  4. Create one OpenAM policy under the previously established Policy Set per Realm-Response-UserPolicy linkage

These steps are necessary in order to preserve the linkage of specific resource URI being accessible over the policy decision and returning specific response attributes.

Parsing out the bindings between CA.SM::Realm and CA.SM::Response objects

Since not all CA.SM::Realm objects in the SiteMinder policy extract refer to all the CA.SM::Response objects it becomes necessary to collect those objects that are bound together and dispatch them into one OpenAM policy. This is because OpenAM ties together a group of protected resource URI to a group of subject conditions, environment conditions and response attributes.

Resolving the Response object into static or dynamic OpenAM Response Attributes

A design decision here could be that the response attributes will be pulled from a user repository such as OpenDJ, making the CA.SM::ResponseAttr.Value definitions very easy to resolve. After parsing the definitions that usually are of the form:


One could construct the response objects one by one, with the display attribute (left of the “=” sign) as key and user profile attribute within quotes above, as the value. Simplistic string split and parsing techniques could be used to achieve this. The mapping of user profile attributes shown here could also be stored as key-value pairs in a metadata container in OpenDJ:



Here, the connection information is stored as an LDAP url in description, admin username in sn and password (hidden) in givenName. The mapping of the user attributes is stored in cn. Using this information the program resolves the key-value pairs from the source repository to that of the target repository schema and the resulting key-value pairs are codified as OpenAM Response objects into XACML, as shown:


Resolve the Subject Restrictions manifest in the PolicyLink.UserPolicy

Converting subject conditions derived from CA.SM::UserPolicy objects such as this one:


..would involve the same framework presented above, except this time we will create an LDAP search filter from the SQL Query- again assuming we are seeking data from an LDAP repository- to ensure the policy is only fired when the subject condition is satisfied.

The program can also provide support for directly retrieving user profile attributes – either for Subject Restrictions presented above in the form of LDAP filters, or for dynamically creating the Response key-value pairs in XACML. The metadata can have connection information stored as shown above that could be used to achieve this external lookup.


WS-Federation Custom SP Attribute Mapper in OpenAM

This solution article demonstrates how to setup a WS-Federation Identity Provider and Service Provider (also called Relying Party) in OpenAM with a custom attribute mapper specific to the SP. The objective is to demonstrate how to use an SP-specific attribute mapper using which you could add custom attributes to a set of claims sent over to a .NET app, or otherwise make those custom attributes available to the OpenAM Session.

WS-Federation IDP

Import the following metadata into OpenAM (instead of using the Wizard). The imported metadata would look like this:


IDP Metadata

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
 <Federation FederationID="wsfedIDP"
 <TokenSigningKeyInfo> <ns1:SecurityTokenReference ns1:Usage="" xmlns:ns1="">
 <TokenType Uri="urn:oasis:names:tc:SAML:1.1"/>
 <ClaimType Uri="">
 <DisplayName>User Principal Name</DisplayName>

Note the use of the default “test” certificate alias above. You can easily switch it out with your own certificate.

Side bar: If you have trouble importing the IDP metadata due to the TokenSigningKeyInfo element, then you must update the sunKeyValue attribute under ou=sunFMWSFederationMetaDataService manually in the configuration store. This is because the WSFederation requires the TokenSigningKeyInfo elements if you want assertions signed (good idea mate!). The following picture shows the metadata instance attribute that must be updated with the full TokenSigningKeyInfo manually:


IDP Extended Metadata

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
 <FederationConfig FederationID="wsfedIDP" hosted="true"
 <IDPSSOConfig metaAlias="/wsfedIDP">
 <Attribute name="displayName">
 <Value>/wsfedIDP </Value>
 <Attribute name="upnDomain">
 <Attribute name="signingCertAlias">
 <Attribute name="autofedEnabled">
 <Attribute name="autofedAttribute">
 <Attribute name="assertionNotBeforeTimeSkew">
 <Attribute name="assertionEffectiveTime">
 <Attribute name="idpAuthncontextMapper">
 <Attribute name="idpAccountMapper">
 <Attribute name="idpAttributeMapper">
 <Attribute name="attributeMap">

WS-Federation SP

You could create the SP simply by using the OpenAM wizard under Federation. Your SP would look like this (note the Custom SP attribute mapper):



Also import the SP remote and IDP remote metadata into different instances of OpenAM. That is left as an exercise to you!


SP Remote Metadata

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
 <Federation FederationID="wsfedSP"

Custom SP Attribute Mapper

We will not show the entire class but the pertinent code that builds a map of values to return is shown below:

        // build our own values
        Set<String> values1 = new HashSet();
        Set<String> values2 = new HashSet();
        Set<String> values3 = new HashSet();


        // build our own claims and assign the values
        map.put("claim1", values1);
        map.put("claim2", values2);
        map.put("claim3", values3);


The needs to be added to the com.sun.identity.wsfederation.plugins package under the OpenFM module and the module must be compiled into the OpenFM-13.0.0.jar for deployment.

Code Changes

There were a few changes necessary in my setup to the following classes for this to work. I suggest you *not* make these changes and test the WS-Federation login first. If it fails with a 403 Forbidden, or a Signature Element error, then proceed to make these following changes.


This class is located in the com.sun.identity.saml2.xmlsig package. In the verify method, alter the code to check for an AssertionID attribute in the assertion XML string, if the ID attribute is not found.

public boolean verify(String xmlString, String idValue, X509Certificate senderCert) 
    throws SAML2Exception { 
        // JSHAH, for WSFed assertions that are missing the ID attribute
        // but instead, contain the AssertionID attribute
        if ( signedId == null || signedId == "" ) {
            signedId = ((Element) sigElement.getParentNode()).getAttribute(SAMLConstants.TAG_ASSERTION_ID);
            doc.getDocumentElement().setIdAttribute(SAMLConstants.TAG_ASSERTION_ID, true);
        } else {
            doc.getDocumentElement().setIdAttribute(SAML2Constants.ID, true);


This class is located in the com.sun.identity.wsfederation.meta package. Rewrite the getAttribute method as follows:

public static String getAttribute(BaseConfigType config, String key)    {
        List list = config.getAttribute();
        for(Iterator iter = list.iterator(); iter.hasNext();) {
            AttributeType avp = (AttributeType);
            // JSHAH Handle empty array in the assertion XML string
            if ( avp.getName().equals(key) ) {
               if (!avp.getValue().isEmpty()) {
                   return (String)avp.getValue().get(0);
               } else {
                   return null;
        return null;


This class is activated on the SP and is responsible for handling the response from the IDP. Think of it as the last gate before successful sign-on and session creation on the SP. It is also responsible for instantiating the SP Account Mapper and SP Attribute Mapper classes. In the process method, comment the following line:

Map attrMap = null;
//JSHAH, Map attributes even if the RSTR does not contain an AttributeStatement
//if (attrs != null) { 
        attrMap = attrMapper.getAttributes(attrs, userName,
        spEntityId, idpEntityId, realm);

Please note that this final code change may not be necessary if you are building an Attribute map in the IDP and not require a custom SP attribute mapper. As you can see from the IDP picture above, I am not building an attribute map in the IDP and I do require a custom SP attribute mapper (check the title of this article!), so I preferred to make this change and force-invoke the custom SP attribute mapper. This should probably be a configuration setting!

Compile all these classes into the openam-federation-library module. Again, you might not need one or more of these code changes so please test incrementally, and only use the code change you actually need.

Disclaimer: None of the code changes are recommended for production use. This solution article and attached code samples are strictly intended for demonstration purposes only. Even with the suggested code and configuration in this article, your mileage may vary.



A Framework for Dynamic Roles and Assignments in OpenIDM

This solution article demonstrates how to add and delete users to ldap groups, statically and also dynamically using custom mappings in reconciliations. I attempt to present a framework in OpenIDM that can be used for setting up a simple entitlement framework where you can automatically attach roles to assignments, making RBAC easier to implement.
This blog article uses sample2b and is specifically referring to the following doc link:!/docs/openidm/4/samples-guide%23provrole-add-assignments
Let us begin by laying the groundwork first, and describe how to create roles and assignment manually in OpenIDM. This solution article assumes you have gone through the doc-link above and are familiar with sample2b.

Static Assignments

The key idea is to create an assignment, and add the group you want assigned under “Attributes” as shown below:
Inline image 1
And then of course, “attach” this assignment to the Provisioning Role you reconciled from DJ:
Inline image 2
Now, it is a matter of assigning the Provisioning Role to the user in order to have the LDAP group “cn=impersonation” assigned to the user in OpenDJ.
Inline image 3
DJ’s ldapsearch will validate the correct group was assigned:

./ldapsearch –port 1389 –hostname localhost –baseDN “dc=forgerock,dc=com” –bindDN “cn=directory manager” –bindPassword xxx –searchscope sub “(uid=user.10)” dn uid isMemberOf

dn: uid=user.10,ou=People,dc=forgerock,dc=com

uid: user.10

isMemberOf: cn=impersonation,ou=groups,dc=forgerock,dc=com

Once you remove the role, ldapsearch will validate that the group was deleted in DJ:

Inline image 4

./ldapsearch –port 1389 –hostname localhost –baseDN “dc=forgerock,dc=com” –bindDN “cn=directory manager” –bindPassword xxx –searchscope sub “(uid=user.10)” dn uid isMemberOf

dn: uid=user.10,ou=People,dc=forgerock,dc=com

uid: user.10


Note that, each one of these IDM UI steps can be performed over REST as well.

Dynamic Assignments

Creating assignments dynamically from incoming LDAP groups can also be performed by setting “managed/assignment” and “managed/role” as Recon targets with the help of some scripting involved in the attribute grid.
Begin by creating the following two mappings:
system/ldap/group to managed/assignment
Screen Shot 2016-05-25 at 5.15.43 PM
and, system/ldap/group to managed/role
Screen Shot 2016-05-25 at 5.17.15 PM
The idea here is to automatically create two managed entities from the LDAP Groups container in OpenDJ.
The first managed entity (“managed/role”) is created to hold the named LDAP group objects – deemed Provisioning Roles – in our use case. These LDAP groups you want the users to be automatically added to (or provisioned to in OpenDJ) whenever “same-named” provisioning roles are assigned to a user. These “same-named” provisioning roles happen to be attached to “same-named” assignment objects! (magically!.. not quite, but via transform-scripting as shown below).
The second managed entity (managed/assignment) is created to hold the “same-named” assignment object that you will setup in such a way that it references (internally) the “same-named” provisioning role!
This will become clearer, read on.

Mapping called sourceLdapGroup_managedRole

Screen Shot 2016-05-25 at 5.29.05 PM
This mapping is simple and aims to create “named” provisioning roles inside OpenIDM from the LDAP group objects in OpenDJ. Cannot get simpler than that in this use case- but keep your seat belts fastened, and read on!


Side bar for the advanced OpenIDM user: Under reconciliation behavior policies configuration, you want to set Missing condition to Unlink in order to “reset the state” if you will, in the case where you delete a provisioning role accidentally in OpenIDM, but want the next LDAP recon on managed/role to fix it. Just remember to run recon twice!

Mapping called sourceLdapGroup_managedAssignment

Screen Shot 2016-05-25 at 5.20.52 PM

The picture above shows which attributes to map for this particular mapping definition.

For the /attributes map, use the following transformation script:

([{assignmentOperation:'mergeWithTarget',unassignmentOperation:'removeFromTarget',name: 'ldapGroups',value: [ source.dn ]}])

This transformation script sets up the incoming group object as an OpenIDM assignment and also sets up the value of the “ldapGroups” attribute to the DN of the incoming group object.

For /roles, use this one:

([{_ref: 'managed/role/'+( openidm.query('managed/role',{'_queryFilter':'/name eq "' + + '"'}).result[0]._id)}])
This script queries the managed/role container in OpenIDM for a “named” provisioning role whose CN happens to equal the CN of the incoming group object. This assumes that you reconciled the managed/role objects first- and this is the only dependency for this use case. You cannot really search for a provisioning role’s CN value before you reconcile it from LDAP. After retrieving the correct role object, the script sets the _ref property of the assignment to that particular provisioning role. This is what you would do if you were manually “attaching” a provisioning role to an assignment as shown in the Static Assignments section above.


Now it is a matter of running reconciliation on sourceLdapGroup_managedRole first, followed by running a reconciliation on sourceLdapGroup_managedAssignment. You should see roles such as:

Screen Shot 2016-05-25 at 5.38.38 PM

And you should see assignments as well- these are basically “named” after the LDAP group objects that have an ldapGroup attribute setup and also an “attachment” setup to a provisioning role:

Screen Shot 2016-05-25 at 5.40.17 PM


For example, lets look at the impersonation assignment in detail.

This picture shows the mapping for this assignment object, and the description reconciled from the OpenDJ groups org unit.


Screen Shot 2016-05-25 at 5.40.59 PM


The picture below shows how the DN of the incoming LDAP group object was mapped to an attribute called “ldapGroups”.

Screen Shot 2016-05-25 at 5.41.05 PM


The picture below shows the provisioning role, with the same name of course, that is “attached” to this assignment object.

Screen Shot 2016-05-25 at 5.41.16 PM


Now we have an “entitlement” framework for automatically creating assignment and role objects in OpenIDM using single or multiple “source” LDAP group containers, and then attaching these provisioning role objects to assignments. We have simply demonstrated a one-provisioning-role to one-assignment mapping in this use case, but far more complex mappings such as many-to-many or many-to-one are possible. This framework can serve as the foundation for an RBAC type scenario in your deployments! Good luck.