While setting up a Tomcat that would be handling authentication in the container with an OpenAM instance, I had a hard time finding documentation on where the user’s session attributes would go after they were redirected back to the site. I found this mailing list entry which allowed me to figure the rest out. It was also confusing why it was giving me a 403 when I logged into OpenAM. I will address both of the problems with the solutions I found. For clarity, I am using OpenAM installed from openam_snapshot_952.zip. I say this because I have noticed that the menu items tend to vary wildly between versions.

To get the user attributes, you have to go through the following menu items:

Access Control >> Click on the Realm to use >> Agents >> J2EE >> Click the Agent name.

Now you will be treated to another root level menu. Follow these menus:

Application >> Profile Attributes Processing

Finally this is where you configure what properties of the OpenAM profile are sent to the application server when the redirect login succeeds. First, make sure you pick HTTP_HEADER in the Profile Attribute Fetch Mode. This is basically a map between the parameter you want in the request header and the property on the OpenAM backing store’s user profile. Examples for these values may be “cn=cn” or “uid=uid”. Yours may have different properties, and you can map them to different names rather than using the same one as I have. Any fields you are storing in your OpenAM directory will be accessible on that user.

At this point, you can write some simple code in a filter or whatever mechanism you prefer to extract those fields out for your application. In my Grails application I use the following code:

1
2
3
4

def requestHeaders = request.getHeaderNames()
requestHeaders.each {
    println("[${it}]:[${request.getHeader(it)}]")
}

If everything works correctly, you should see your attributes and their values.

Lastly, if you get the 403 error when you try to login, you don’t have any policies that allow users to access your system. Why do you have to set up policies to even test logging in? I have no idea, but there is a way to get around this until you’ve implemented policies in your OpenAM instance (if you ever need to).

Go to the Global tab under Agents and go to the General options. When I first logged in, I saw the value ALL there, which did not seem to work. After some research online, I found that SSO_ONLY was what I needed in this case. As the image shows, you do not need a Map key here, just the Map Value which is very odd. I have no idea what the expected key is, but either way it seems this was the configuration that worked for me.