Deploying #OpenAM instances in #Docker

Deploying services with Docker has become pretty popular in the DevOps world (understatement).

I want to demonstrate how to deploy an instance of ForgeRock’s OpenAM and OpenDJ using Docker.

Essentially this is my ForgeRock Docker Cheat Sheet

I am running this on a virtual Ubuntu instance in Virtualbox on my laptop. You can run Docker on both Windows and OS X too … I just personally prefer Linux.

Step 1: Install Docker:

Step 2: Clone ForgeRock Docker Files:

cd /home/brad/Dev/

Use git to clone from:

This will create a directory called “docker” in the above path.

Step 3: Build Files:

cd /home/brad/Dev/docker
make clean

At this point a few images are created on your local host, to view Images:

docker images


OpenDJ Instance:
Note: the first time you run an instance you need to create the “dj” directory first (persistent storage)

cd /home/brad
mkdir dj // <— just run this once; the first time you launch an instance on this host
docker run -d -p 1389:389 -v `pwd`/dj:/opt/opendj/instances/instance1 -t 9f332a0fbb88

To enable a persistent store you can use docker’s volume capability. From the above command, “-v `pwd`/dj:/opt/opendj/instances/instance1” this tells docker to cp “/opt/opendj/instances/instance1” from the running instance to `pwd`/dj on the docker host. You can then kill this instance and then launch a new one, referring to the same volume.

To view the running docker instances:

docker ps

Now when we launch OpenAM, we’ll want to allow it to access the OpenDJ container. By default Docker does not setup this networking but we can create a link (see run command below). Using the link parameter, Docker will edit the /etc/hosts file on the OpenAM container and create a “link” to the OpenDJ serverOpenAM:

cd /home/brad
mkdir am // <— just run this once; the first time you launch an instance on this host
docker run -d -p 8080:8080 -v `pwd`/am:/root/openam –link dreamy_hypatia:opendj -t c02f00f42e18

As we did with OpenDJ we tell Docker to create a volume, on the Docker host, and copy the OpenAM configurations to this location. This allows us to launch a new instance without having to reconfigure OpenAM.

Next Steps:
There are a lot of things that I did not cover in this post, specifically running multiple instances for scalability. OpenDJ would need to be configured for replication and OpenAM would need to be configured to join a Site. I plan on covering these things in a future post.

Also, I didn’t cover Docker best practices (specifically security). In your environment, treat your container ids as you would passwords.

Lastly, I plan on exploring other options for persistent storage, in future posts. I am pretty sure there are better alternatives than storing this data on the Docker host’s filesystem. Possibly looking at creating another Docker container specifically for storage.

Warren Strange (ForgeRock) … he’s constantly producing awesome and developed a lot (probably most) of the capability around the ForgeRock docker instances

My friends at GoodDogLabs for mentoring me on all things Docker

Also, I have been gleaning a lot of Docker tips from @frazelledazzell … she drops a ton of Docker knowledge via Twitter and her blog.


This blog post was first published @, included here with permission.

OpenAM v.13 – REST STS OpenAM Token Translation

A quick demo of OpenAM’s Token Translation Service

According to Wikipedia:

In a typical usage scenario, a client requests access to a secure software application, often called a relying party. Instead of the application authenticating the client, the client is redirected to an STS. The STS authenticates the client and issues a security token. Finally, the client is redirected back to the relying party where it presents the security token. The token is the data record in which claims are packed, and is protected from manipulation with strong cryptography. The software application verifies that the token originated from an STS trusted by it, and then makes authorization decisions accordingly. The token is creating a chain of trust between the STS and the software application consuming the claims. This process is illustrated in the Security Assertion Markup Language (SAML) use case, demonstrating how single sign-on can be used to access web services.

Here is a quick video (w/o audio) demonstrating how to create an STS instance in OpenAM v.13 and then using Postman (REST client) to translate the tokenid of an authenticated user.

Caveat: There are obviously more configuration requirements for an actual deployment, the ACS URL would be key, for example. Refer to the STS documentation linked below the video.




REST Requests:


 POST /openam/json/authenticate HTTP/1.1
 X-OpenAM-Username: username
 X-OpenAM-Password: password
 Content-Type: application/json
 Cache-Control: no-cache


 POST /openam/rest-sts/sts-test?_action=translate HTTP/1.1
 Content-Type: application/json
 Cache-Control: no-cache
 “input_token_state”: {
 “token_type”: “OPENAM”,
 “session_id”: “AQIC5wM2LY4SfczD8y5-kVgiXY7rxxxxxxxxx8k0o8.*AAJTSQACMDEAAlNLABQtNjY4MzQxNjkzMDg2ODI1MjIzOQACUzEAAA..*”
 “output_token_state”: {
 “token_type”: “SAML2”,
 “subject_confirmation”: “BEARER”

Next Steps?
We implement solutions like this for our clients nearly every day. Are you looking for assistance on a current project? Maybe you have a future project and you just want to keep in touch. Awesome! Head on over to our contact page and drop us a line. We’re looking forward to hearing from you.