Juniper SA and AD FS 2.0 Integration – Part 1

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., 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. 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: for Service Provider A and Identity Provider A pairing 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, 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 ‘’, but the request could not be fulfilled because the key does not identify any known relying party trust.

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 (, the entity ID does not match the expected identifier reported in the event log error ( When setting up the Service Provider, the identifier is set to

Go into the relying party settings for the Juniper and on the Identifiers tab add an additional identifier for

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


13 thoughts on “Juniper SA and AD FS 2.0 Integration – Part 1

  1. Hi Mylo, great article! Were you able to use the SAML attributes released by AD FS in creating Role Mapping Rules under your AD FS IdP realm? I have followed the same steps, and additionally created another passthrough claim rule in AD FS to release the user department or groups, but it seems that Juniper SA is not able to consume the SAML attribute statement, only the Name ID.

    1. Hi John,

      That’s a great question. I’ve not looked at handling assertions, beyond what is passed via the NameID I used in the post. When I wrote Part 1 with the SA in an SP role, I was working with the 7.1Rx release, and with the 7.2 release, as described in the subsequent post, the emphasis was more on the SA in the IdP or “directed” SP-initiated role. Like you, I’m curious about what assertions can passed to the SA beyond the basic Name Identifier via an IdP such as AD FS. I don’t see anything in the UI at this moment that will support this, but then I’m in learning mode on the SA front too 🙂


      1. Hi Mylo and John,

        Any luck with creating Role Mapping Rules based on SAML attributes? Could custom expressions be used?


      2. Hi Karl,
        You can extract the appropriate claims from AD FS as the IdP assuming these correlate to the built-in mappings that the Juniper supports. I don’t have the 10.x firmware available to test sadly… what attributes are you specifically aiming to pass?


  2. I’ve been toying with the idea of using Smart Card (Client Certificate Authentication) to access a Juniper SSL VPN, and using SAML to translate the authentication to Active Directory authentication. Will that allow for a Constrained Delegation type authentication, and allow users to access Windows Domain resources? I assume it would work for SharePoint 2010 using Claims based authentication… what about things like file shares, or Exchange 2010 OWA?

    1. Hi Rob,

      I’ve not tried smart card authentication on the SSL VPN although the Pulse credential provider supports it.. the Junos Pulse client doesn’t natively support SAML 2.0… that may well change in the future.. the problem i’m referring to is described here

      You could (in theory) use constrained delegation to ADFS from the Juniper to animate federated logon, but that implies that the Juniper acts as a gateway and not in peer mode. You’ll need to think long and hard about what type of access scenarios you’re looking to support, both from a peer / gateway mode perspective.. File shares add an additional layer of complexity and it depends on how/where they are to be accessed. SharePoint 2010 and OWA are both possible in federated scenarios, SharePoint out-of-the-box via claims and OWA with some tinkering to support claims via Windows Identity Foundation (WIF) customization.

      Again, it’s hard to provide any sort of intelligent tips at this stage without further info 🙂


      1. No problem. I figured it out. I used a Certificate Server for Auth, an LDAP Directory Server that pointed to Active Directory, and setup SSO using Kerberos Constrained Delegation. That seemed to be pretty easy to setup, accept for the LDAP DN= syntax to AD. That took a couple of tries to get it working. I’m now able to signin to the SSL VPN with my smart card, and click my OWA link for access without additional logon prompts. I was surprised how easy it was.

  3. Great article, Milo. It was a great primer for my first run at ADFS(IdP) with Juniper(SP). Unfortunately I’m having an issue. I followed everything you did expect I allowed the Juniper SA to import the ADFS metadata automatically with the federation URL. I keep on getting the error: SAML Transfer failed. Please contact your system administrator.
    Detail: FAILURE: No valid assertion found in SAML response

    I looks like ADFS is successfully authenticating my user. When ADFS hands back the SAML 2.0 request back to the Juniper, it doesn’t like the request. I have turned on every bit of logging I can find on the Juniper SA, but I still get nothing in my logs. Do you know of any ideas about this? Any ideas of where to look? I’m currently running a Juniper SA 7.2R4 (build 21697).

    1. Hi Ben,
      Did you get this solved? Sorry for the late reply. The SAML Transfer failed is a generic message that the SA uses to say all is not well. What claims are you passing the back to the SA and do these match the NameID value expected on the SA?


  4. Hi just wanted to give you a brief heads up and let you know a few of the pictures aren’t loading properly. I’m not sure why
    but I think its a linking issue. I’ve tried it in two different internet browsers and both show the same outcome.

    1. Hi pdf,
      Thanks. I’ve noticed that from some of the other articles, that once they’ve “aged” between a certain time period, that the images fail to load correctly. I’ll try and get to the source of the problem. I’m a bit of a WordPress neophyte 🙂


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s