Forgerock OpenAM 9.5.3 and AD FS 2.0 Integration – Part 3

In the final part of this configuration, we’ll look at setting up both AD FS and OpenAM for federation.

Before we start, let’s quickly recap on the access scenario. OpenAM is an identity provider in another organization, with whom we are performing identity federation with.

We intend to provide users in Organization A with access to web resources in Organization B. This is accomplished by setting up a federation trust via the local AD FS 2.0 instance in Organization B. Communication is across an untrusted network; consequently, all traffic between parties is encrypted using HTTPS.

In Part 2, we created the identity provider on the OpenAM side and registered the remote AD FS SAML 2.0 service provider. A few tasks still remain though:

Finalize the OpenAM Identity Provider (IdP) Configuration

Configure the Remote AD FS 2.0 Service Provider (SP) in OpenAM

Configure the Identity (Claims) Provider in AD FS 2.0

Create test users in OpenAM

Configure a Windows Identity Foundation (WIF) test application

Configure AD FS 2.0 claims

Finalize the OpenAM Identity Provider (IdP) Configuration

There are a couple of changes that we need to make on the OpenAM IDP side. The IDP attribute mapper is used to specify which user attributes will be included in an assertion. The default attribute mapper (com.sun.identity.saml2.plugins.DefaultIDPAttributeMapper) retrieves attribute mappings from the (user) data store and sets that value as the attribute value of the specified SAMLV2 attribute.

Assertion Content

On this tab of the IdP configuration, we’re going to specifiy the NameID format that the Identity Provider will use and also the value mappings to map the Name ID to. A number of NameID formats are supported by OpenAM, according to the SAML 2.0 protocol:

In this example, we’ve set the Name ID format on the IdP to accept both a NameID format of Transient or Unspecified.

We want to create a mapping with the selected format to an attribute from the user’s profile. In our case, the defined Name ID format is used in the protocol, resulting in the profile attribute value being used as the NameID value for the user. In the example below we map the transient format to the user common name (cn) attribute and unspecified to the user ID (uid) attribute.

Note that the default NameID convention that AD FS will follow/submit as a SAML 2.0 Service Provider (unless told otherwise) is urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified . For more information, I’d suggest reading a great article from Adam Conkle on Technet :

In the Assertion Processing section of the IDP we map the configuration used by the attribute mapper. Using the convention of SAML v2-attribute=user-attribute convention, we map, in the above example, the user store userattribute of uid to the SAML attribute uid, the Common Name of the object and the mail address.

Configure the Remote AD FS 2.0 Service Provider (SP) in OpenAM

Under Entity Providers in OpenAM we need to configure settings for the SAML 2.0 Service Provider, AD FS 2.0.

Assertion Content

Under the Assertions Content tab, check that that the Assertions are Signed.

We’ll also inform the SAML 2.0 Service Provider of the NameID formats supported/expected. An identifier is used so that both parties can agree on third-party authentication of a user, using identifiers that are meaningful to both. Here we configure that the expected NameID format and the content presented by AD FS 2.0 is an identifier with transient semantics or one of unspecified.

We’ll set this also on the AD FS 2.0 claims provider shortly.

Assertion Processing

The assertion processing tab allows us to map attributes to submit to the relying party/Service Provider. This provides us with an opportunity to map through our custom claims descriptions as SAML attributes to the corresponding attributes in the OpenAM user directory.

You may recall that we created these custom claims descriptions earlier in Part 2 and we can now use these descriptors to map against their OpenAM LDAP counterparts.

Configure the Identity (Claims) Provider in AD FS 2.0

In AD FS 2.0 we need to register our OpenAM SAML 2.0 Identity Provider. Create a Claims Provider and point AD FS to the online OpenAM metadata address. In a lab/testing environment, using online metadata publishing is fine. Across untrusted networks, and in production environments, organizations may be reluctant to publish metadata online, in which case file exchange is an option.

We’re not using realms within OpenAM, so the default URL for the IdP under the root realm is used. Using the naming example of idp.mydomain.com from our previous posts, the IdP service endpoint, therefore, would be:

Validate that the selected URL and federation partner information is correct.

You can add the claims now (detailed below) for the IdP or uncheck the Open Edit Claim Rules dialog as I’ve done here, adding the claims later. I’ve chosen here to adjust the claims provider properties first before setting up the claims rules, but it’s ultimately down to personal preference…

On the IdP properties, click on the Advanced tab and change the hashing algorithm from SHA-256 to SHA-1 and click on Apply / OK when done.

Alternatively, you can use a Sharepoint 2010 Claims web part (if you happen to have Sharepoint floating around)… For the remainder of this document, I’m assuming that you’ve gone the WIF route and the assumption therefore is that this will be the relying party.

Here’s a screenshot of the FEDUTIL tool and setting up the Application URI.

Let’’s assume that we’re using the built-in datastore as the default authentication store for users.

If we go into Access Control, select the Top Level Realm and then click on Authentication, we’ll see that ldapservice (Datastore) is the organizational authentication scheme for our users (note there is a separate authentication scheme for realm admins) , so we’ll need to create a user with a password. From the Top Level Realm, select Access Control | Top Level Realm | Subjects | New

Fill out the mandatory fields (denoted by an asterisk) for the user. The ID field is the logon ID used for subsequent logon.

One item to check is the User Profile in the Authentication tab of the Top Level Realm. Click on All Core Settings and check that the User Profile is set to Required. I notice to my cost, that if this is set to Dynamic or Ignored then OpenAM will not pass any user SAML attributes to the AD FS service provider apart from NameID. I’ll be honest… I don’t know whether this is my testing, a bug or is by design, but it certainly proved to be a quirky stumbing block in my test setup

Configure AD FS 2.0 Claims

Back in AD FS world, we’ll need to setup claims on both the Claims Provider (OpenAM IdP) and Relying Party (WIF) side of things.

Claims Provider

In Claims Provider Trusts, right click on the OpenAM IdP and select Edit Claim Rules.

We’re going to create the following rules as seen in the screenshot below.

If you’ve followed the previous articles, then you should have two custom claims descriptions already for UID and Mail, so it should be relatively easy to creat the mappings thru the GUI using the above claims or below using custom rules based on:

NameID set to Transient (which is the Common Name attribute from OpenAM)

In the Relying Party Trust section within AD FS, we also need to create some pass thru rules on our WIF web application. We can use the same rules defined above. Follow the same process, albeit this time right-clicking on the relying party and editing the claims rules on the RP. I’ve also added a transform rule in testing to transform the x-am-mail claim to UPN (see the screenshot below). It’s not required, but is merely used to demonstrate how incoming values can be also be transformed/passed to other attributes.

I’m simplifying the logon process somewhat to give a more concise view of events, not to mention saving me typing… It’s important to note that since this is a passive web federation scenario, the browser and user are effectively bounced around from RP to FP-STS/SP to IdP and back during the logon process.

In the claims-aware web application, the resultant claims should be now visible.

That’s it on the configuration side of things! If you come unstuck, just post comments and I’ll try and get back to you ASAP. I hope this helps those who are looking at integrating OpenAM with AD FS. Meanwhile, as ever, this is all done in the hygienic and wonderful user free environment of a test lab, so don’t go all production grade on me without beating this first with the testing stick……