Following up from the last post where we integrated OpenAM as an identity platform with Active Directory Federation Services (AD FS) 2.0, we’re going to flip roles and products this time. In this post, we’ll look at using a Juniper SA SSL-VPN gateway and plugging this into AD FS 2.0  Since Release 7.1R1 of the SA firmware, SAML 2.0 support has been available with the platform, with the SSL-VPN being deployable in the guise of a SAML Service Provider, Identity Provider or as a Policy Enforcement Point (PEP).

In Part One of this article, we’ll examine the role of the Juniper SA as a SAML 2.0 Service Provider (SP) and AD FS 2.0 as the SAML 2.0 Identity Provider (IP).

In Part 2we’ll reverse roles, using the Juniper as an Identity Provider (IdP) and AD FS 2.0 as the Service Provider (SP). Note that at the time of writing, the IdP capability in the 7.1Rx release, as I understand it, is not yet fully feature complete (The J-SA release used in this particular post is 7.1R6.0), with the full feature set available in the 7.2 release: expected Q2 2012.

Before we begin configuring our Juniper as a SAML 2.0 Service Provider, there are a number of steps that we need to perform on the Juniper side first. First, the prerequisites:

• you have a running Juniper SA and AD FS 2.0 configuration ..
• you have the necessary SSL certificates for your appliance/application (e.g. gateway.mydomain.com, sts.mydomain.com etc.) and installed them
• you have a token signing certificate on the Juniper (e.g. self-signed certificate).
• you have set time correctly on all devices are using a reliable time source (e.g. NTP)

Juniper SA Service Provider

Login to the Administrator Sign-In page of the Junos Pulse Secure Access Service.

From a federation standpoint, the SA will use the hostname, defined in System | Configuration | Networks, in entity IDs and names for SAML Endpoints, unless the appliance is part of a cluster, in which case the Cluster FQDN should be used.

Begin by creating a New Metadata Provider.  Go to System|Configuration|SAML and click the New Metadata Provider button.

Give the metadata provider a name, e.g. AD FS Identity Provider. The administrator is then given the option of uploading the metadata file from the identity provider or connecting to the remote IdP to obtain metadata. I elected to go with the file route, as trying to obtain the remote metadata produced errors (Extract metadata info failed : Metadata file does not have a valid saml entity). I assumed this was down to the federation metadata not being interpreted correctly as it contains WS-Trust metadata.

Download the federation metadata from your local AD FS 2.0 instance, e.g.  https://sts.mydomain.com/FederationMetadata/2007-06/FederationMetadata.xml and save the XML file to disk. The file needs sections of metadata WS-* protocols removed from it as well as Service Provider metadata. Remove the following sections.

• ds:Signature
• Role Descriptor
• SPSSODescriptor

You should be left with a metadata file that looks something like this:

Upload the metadata file.

If the file is formatted correctly, it will be accepted when the configuration is saved.

In the Metadata Provider Verification Configuration section, we need to import the AD FS Token Signing Certificate. This certificate can be exported from the AD FS 2.0 Management snap-in by clicking on the AD FS 2.0|Service|Certificates section, double clicking on the certificate, highlighting the Details tab and then pressing the Copy to File button. Select Base64 in order to use a format supported by the Juniper, save to file and then upload the certificate on the Juniper configuration. In the example below Certificate Status Checking is also enabled.

Save the configuration.

From the main Junos Pulse Secure Access menu select Authentication|Auth Servers. From the dropdown selection choose SAML Server and click on the New Server button.

Give the new configuration a name, e.g. AD FS ..

Change the SAML Radio button to 2.0. As soon as this is done the service provider entity ID of the Juniper SA will be populated. The SA entity ID defined here for this SAML Server is unique to this SP-IDP pairing.

What I mean by this is, is that if I have two SAML servers in the Authentication Servers section on the Juniper, with each one pointing to a different Identity Provider, the SA Entity ID for each entry will change. For example, the service endpoint may be:

https://gateway.mydomain.com/dana-na/auth/saml-endpoint.cgi?p=sp7 for Service Provider A and Identity Provider A pairing
https://gateway.mydomain.com/dana-na/auth/saml-endpoint.cgi?p=sp10 for Service Provider B and Identity Provider B pairing.

Make a note of the endpoint/entity ID information at this point so we can cut and paste this into AD FS later.

In the next section we need to specify the remote partner that the SA will be paired to for this SAML Server entry. Since we’ve already defined AD FS 2.0  as a potential identity partner in System|Configuration|SAML, the entity ID and Single Sign On Service URL is automatically populated when we click on the Metadata radio button.

We can always configure the settings manually, but we’ll then need to enter SSO URLs and Entity IDs manually for AD FS.

Change the configuration mode to manual so that:

• SSO Method is set to Post
• the Signing Certificate can be specified.

I’ve also selected a Device Certificate for Signing the metadata.

A self-signed certificate can be created using OpenSSL, IIS7.x, Portecle (see previous posts) and then the .P12/.PFX file imported into Configuration|Certificates|Device Certificates section of the Juniper.

In the Service Provider Metadata settings section of the SAML Server there is an option to not Publish SA metadata. If this checkbox is enabled, AD FS 2.0 will not be able to connect to the SAML endpoint of the Juniper to service metadata. In which case the Service Provider metadata will need to be exported to file from the Juniper via the Download Metadata button and then import it manually into AD FS. In this post, we’re using published endpoints.

Click on Save Changes when you’ve finished entering the SAML Server information

As a final step, we can create a separate User Authentication Realm in the SA Configuration or associate the authentication server with the default Users realm. In the example below, a realm called AD FS IdP is created and the AD FS authentication (SAML) server specified.

On the default sign-in pages, the AD FS IdP realm has been chosen to use for logon.

AD FS 2.0 Identity Provider

In AD FS 2.0, we’ll need to create a Relying Party via Relying Party Trusts |  Add Relying Party Trust option.

Enter the URL of the Juniper SA endpoint (this is the SA Entity ID information from earlier)

Click on Next and give the Relying Party/Service Provider entry a name.

Click on Next

With the Relying Party information entered we can then enter the necessary claims rules to pass to the RP.

We’ll do this by:

1. Creating a rule that extracts the e-mail address from AD
2. Create a transform rule that transforms the incoming claim type: e-mail address to the Outgoing claim type: NameID with the Email format

Under Issuance Transform Rules, Click on the Add Rule button and select the Send LDAP Attributes as Claims template.

From the AD Attribute Store, we’re going to map the LDAP attribute E-Mail-Addresses to an outgoing claim of e-mail address. Click on Finish when done.

Add a second rule. Create a Transform an Incoming Claim rule and in this rule, we’ll map the incoming E-Mail Address claim to an outgoing claim type of Name ID using the format Email. *

Click Finish when done.

If you attempt to access the Juniper gateway, https://gateway.mydomain.com an get the following error:

Double-check that the claims values you’ve entered are set correctly.

If you get an error such as the following:

This may occur because the signature value on the relying party in AD FS is set to SHA-256 instead of SHA-1. Additionally, the error can occur because of issues with the relying party URI. When we have a look in the AD FS 2.0 admin log, we see an Event ID 184:

A token request was received for a relying party identified by the key ‘https://sa-gw.mylos.net/dana-na/auth/saml-endpoint.cgi’, but the request could not be fulfilled because the key does not identify any known relying party trust.
Key: https://sa.mydomain.com/dana-na/auth/saml-endpoint.cgi

This request failed.

User Action
If this key represents a URI for which a token should be issued, verify that its prefix matches the relying party trust that is configured in the AD FS configuration database.

Looking at the Service Provider metadata from the Juniper service through its URL (https://sa.mydomain.com/dana-na/auth/saml-endpoint.cgi?p=sp7), the entity ID https://sa.mydomain.com/dana-na/auth/saml-endpoint.cgi?p=sp7 does not match the expected identifier reported in the event log error (https://sa.mydomain.com/dana-na/auth/saml-endpoint.cgi). When setting up the Service Provider, the identifier is set to https://sa.mydomain.com/dana-na/auth/saml-endpoint.cgi?p=sp7.

Go into the relying party settings for the Juniper and on the Identifiers tab add an additional identifier for https://sa.mydomain.com/dana-na/auth/saml-endpoint.cgi.

Go to the Sign-In page configured

You should be able to logon successfully to the Juniper portal using your AD credentials.

As ever, test extensively before trying to put this into any production level environment.

* NameID mappings from the Juniper Service Provider metadata