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:
urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
urn:oasis:names:tc:SAML:2.0:nameid-format:transient
urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName
urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName
urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos
urn:oasis:names:tc:SAML:2.0:nameid-format:entity
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 :
http://social.technet.microsoft.com/wiki/contents/articles/4038.aspx
Assertion Processing
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:
https://idp.mydomain.com/openam/saml2/jsp/exportmetadata.jsp
Click past the skipped federation metadata warning.
Give your Claims Provider a name. ***
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.
*** Note that this will be the name used on the Home Realm Discovery page and the user will need to select between the local AD FS 2.0 realm or the OpenAM IdP realm (assuming that local AD FS authentication hasn’t been disabled (a la https://blog.auth360.net/2011/02/20/disable-local-authentication-in-ad-fs-2-0/)
Configure a Windows Identity Foundation (WIF) test application
This is a well documented process by Microsoft, so I’m not going to spend much time on this section 
To get your WIF application running I’d suggest reading this article
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.
Hint: Look at using the ClaimsAwareWebApplicationWithManagedSTS
Once you’ve configured your Claims aware web application via FEDUTIL, it’s time to configure the Relying Party (RP) on the AD FS 2.0 side. Now this could be another SAML 2.0 Service Provider, but in the .NET world (at the moment) this is not released yet (CTP). So, in the above example, we’re using a relying party that has a WS-Federation Passive endpoint of https://contoso.auth360.net/sts with metadata at: https://contoso.auth360.net/sts/FederationMetadata/2007-06/FederationMetadata.xml
Create Test User in OpenAM
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)
- Pass thru Custom Claims Description for AM UID (which is the uid attribute from OpenAM)
- Pass thru Custom Claims Description for AM UID (which is the mail attribute)
The transient rule looks like this:
[Pass thru Incoming Claim Type of Name ID and Incoming Name Format Transient Identifier – Pass All Claims Values]
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] == "urn:oasis:names:tc:SAML:2.0:nameid-format:transient"]
=> issue(claim = c);
[Pass thru Incoming Custom Claim for UID – Pass All Claim Values]
c:[Type == "http://schemas.auth360.net/2012/01/requestcontext/claims/x-am-uid"]
=> issue(claim = c);
[Pass thru Incoming Custom Claim for Mail – Pass All Claim Value]
c:[Type == "http://schemas.auth360.net/2012/01/requestcontext/claims/x-am-mail"]
=> issue(claim = c);
Relying Party
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.
[Transform Custom Claim for Mail – UPN]
c:[Type == "http://schemas.auth360.net/2012/01/requestcontext/claims/x-am-mail"]
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);
Summary
With all the parts coming together, here is the abridged version of the logon process, starting at the relying party.
- User in Organization A accesses https://contoso.auth360.net/sts (Relying Party) in Organization B.
- User does not have a valid authentication cookie and so is redirected to Organization A https://sts.mydomain.com/adfs/ls (FP-STS) . for logon
- AD FS performs Home Realm Discovery
- User selects their Organization A home realm (OpenAM IdP) for logon
- User is redirected to Organization A https://idp.mydomain.com/openam/SSORedirect/metaAlias/idp?SAMLRequest
- User logs on to OpenAM realm with local user account and is authenticated
- User is redirected back to AD FS (FP-STS) for further processing
- AD FS processes (Claims) Acceptance Transform Rules on Claims Provider
- AD FS processes (Claims) Acceptance Transform Rules on Relying Party
- User is redirected to relying party web application https://contoso.auth360.net/sts.
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……
The Access Onion 