The recent release of the new 7.2 firmware for the Juniper SA and a timely nudge from colleagues, proved the perfect tonic to continue the second post about integrating the Juniper Secure Access service and AD FS 2.0. 

In Part 1, the article emphasized the use of the Juniper gateway as a SAML Service Provider, with AD FS acting as the Identity Provider. Login at the Juniper, via service provider initiated (single) sign-on, would take place via the AD FS identity provider.  What I neglected to mention in the previous post (silly me), is where this sort of setup can be used, so here are a few examples:

• as a rendition layer for Citrix Web Interface / StoreFront, for internal users  with Kerberos SSO enabled
• as a landing page/portal for internal users with Kerberos SSO enabled
• use of AD FS as an identity provider for single sign-on to MS applications
• use of AD FS for performing claims augmentation

In this post, we’ll look at the Juniper as an identity provider. In this role role it offers a number of capabilities

• as a policy enforcement point for managed and unmanaged clients of federation protocols
• as an authentication bridge between SAML and other protocols for federated SSO scenarios, e.g. RADIUS 2FA/OTP
• as an Identity Provider (gateway mode)
• as an Identity Provider (peer mode)
• as an Access Portal

On the AD FS 2.0 side, AD Federation Services occupies the role of  SAML Service Provider and Relying Party  Security Token Service (RP-STS) to Windows applications running behind it.

There are two operational modes for the Identity Provider, using SAML SSO, that are particularly interesting with the 7.2 release of the Secure Access gateway. These are:

• Gateway Mode
• Peer Mode

NB: SAML SSO scenarios described are using HTTP POST.

Gateway Mode

In Gateway Mode, access to web applications / SAML service providers and traffic flows are through the Juniper as a portal. In this mode, logon is initiated at the SA as the Identity Provider (IDP-initiated) and then access is provided to the web application.

In Gateway mode, if the application is on-premise, we can also place the relying party / web application directly behind the Juniper, with the application host [A] record resolving to the gateway address). This configuration is not described in this post.

Here’s a walk-thru of Gateway Mode logon.

1. The user access the URL for the SA gateway and is presented with a logon form.

2. From the portal landing page, the user selects the web application, e.g. Contoso Web, and the request is processed. The behaviour may change according to how the web application has been configured in the web resource profile.

3. The relying party web application redirects the request to AD FS . If a home discovery realm (HRD) cookie doesn’t exist, the user will be requested to do the realm selection in order to logon to their home realm. If smart links are being used for the bookmarked web application(s)  (see later in this post for a further explanation) , then HRD selection may be bypassed.  If smart links aren’t used and realm persistence is also disabled in the AD FS configuration, then the user will be prompted each time to select their home realm, otherwise a cookie of 30 days (default) will be written to disk, once authenticated.

4. The logon request will be submitted to the Identity Provider (IdP). If the user has a valid logon ticket then further logon processing will continue.

5. Once processed correctly, a SAML redirect back to the AD FS server is carried out for further logon and claims processing at the RP-STS.

6. Claims processing at the RP-STS is carried out and it and relying party claims are processed, the user obtains access to the web application.

Peer Mode

In Peer Mode, access to SAML service providers is not initiated via the Secure Access (SA) gateway.  The user accesses the resource directly and they are redirected to the Identity Provider for logon .

Normally speaking, the user is redirected from the service provider to the identity provider for sign-on.  In this configuration, however, behavior is different as AD FS is brokering authentication traffic for web applications that are WS-Federation based and acts an intermediary or Relying Party Security Token Service (RP-STS) between the application and the Juniper.

In Peer Mode, the user will begin RP or SP-initiated logon. Let’s look at the process of how a Windows Identity Foundation (WIF) application behind AD FS 2.0 would work:

1. The user accesses the Contoso web application URL

2. The user is redirected to the AD FS RP-STS

3. The home realms discovery process within AD FS service and user must select the Juniper SA claims provider.

4. The user is redirected to the Juniper Secure Access Service for logon processing

5. The user is presented with a logon form, within which their Juniper logon credentials must be entered. In the example above we’re doing a login against a primary authentication server (RADIUS using One-Time Passwords) and the local Active Directory as a secondary (uid/password).

6. Following a successful logon, the user is returned to the SAML 2.0 Service Provider, AD FS 2.0, for further processing of logon and claims.

7. The Relying party claims pipeline is processed and claims are harvested.

8. If authorized, the user has accessed to the web application.

URL Rewriting

On the Juniper configuration side, to allow successful processing of redirects to AD FS, we need to ensure that the URL of the AD FS is not rewritten at the Secure Access appliance. This is accomplished by the creation of a Web Resource Profile that includes an Autopolicy: Rewriting Options policy set to No rewriting.

We will use this facility later on when we create bookmarked applications and smart-link to our relying party web applications through the AD FS web resource profile.

Identity Provider Configuration

Let’s look at the Identity Provider (IdP) capability of the Secure Access Service. Under Configuration | SAML | Settings of the SA we need to configure our Identity Provider (IdP) with a Host FQDN for our SAML service.

(We’ll cover Pulse NC in a later post)

It is possible to set a different Host FQDN from the gateway or use the gateway name itself. Experience/testing so far suggests that both configurations work. For simplicity, I’ve aligned the FQDN for SAML with the Host FQDN for the Juniper gateway itself (gateway.mydomain.com). Once the FQDN are set, there’s also an option to update entity IDs that already exist with the new FQDN. While it won’t automatically update the metadata of partners, it is a handy way of automatically updating entity IDs on the Juniper side.

Next up, a menu option under Authentication | Signing-In | Sign-In SAML is new for 7.2. This provides two configuration tabs, one for the metadata provider and the other for the identity provider.

The Metadata provider Entity ID is automatically populated with the FQDN defined earlier.

On the Identity Provider tab, we configure the main settings for our IdP.

In the first area of the page, we define what bindings we intend on using, use of signing certificate, token decryption certificate etc.

In the second section, we define Service-Provider related settings for the Identity Provider

I want to spend a little time expanding on authentication scenarios and  what kind of logon scenarios are possible.  The Sign-in Policy value allows the administrator to select which policy is to be effective for the IdP. In the example above, I’ve elected to use */ which also happens to be the default sign-in policy for the gateway itself. However, I can customize the sign-in policy so that the IdP has its own authentication scheme independent of gateway mode settings.

In this test configuration, the default sign-on policy is using RADIUS (OTP) and AD authentication.  I’ve setup sign-In policies /idp1 and /idp2 just to illustrate that other sign-on options are available for choice.  Any service provider (including AD FS 2.0) configured with the Juniper as its Identity Provider will be redirected to the Juniper for sign-on, processing the /* policy.

On the IdP configuration screen above, I’ve highlighted the User Identity section. This is the SAML Name Identifier that the IdP will present to the service provider (SP) in the assertion. In this case, I’ve set the Subject Name Format to Other. This translates to NameID unspecified: urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified

On the AD FS 2.0 side (in Gateway and Peer configurations), the Juniper is configured as a claims provider. Using our mythical mydomain.com FQDN, let’s add a Claims Provider and enter the FQDN of the Juniper as the URL

https://gateway.mydomain.com/dana-na/auth/saml-endpoint.cgi

Walk thru the remainder of the wizard, give the IdP a name, skips claims rules configuration and from within the properties of the claims provider, switch the secure hash algorithm to SHA-1. Using the NameID Unspecified example above, we can add the following custom claims rule:

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:1.1:nameid-format:unspecified"]
=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

In the above rule we map NameID to Windows Account Name. On the Relying Party Contoso web application, we then pass thru Windows Account  Name to the claims-aware web application.

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
=> issue(claim = c);

Peer Service Provider Settings

Within the Identity Provider configuration screen within the Secure Access Service, we also define a list service providers  that make make use of the identity provider. This provides additional options concerning  the Service Provider configuration, and we can elect to override the default sign-on policy for the Identity Provider (IdP).

In overriding the default configuration, it is possible to assign a unique authentication scheme (sign-on policy) and assertion mapping  to a particular service provider. This is useful in scenarios where we wish to use a given authentication type for a particular service provider or web application.

Gateway Mode Configuration

For an IdP-initiated logon, users will typically logon to the FQDN for the gateway (e.g. gateway.mydomain.com) and the default sign-on policy (/*) will execute.  Using the example described earlier in Peer mode, this would mean the user logs on to authentication realm A using RADIUS (OTP) plus AD password for logon. Since the identity provider is associated with this sign-on policy (/*), this means a valid SAML token is generated at the gateway during login.

To test this, create a Web Resource Profile for the web application, using a custom resource profile for a claims-aware test web application. Click on Show ALL autopolicy types and ensure that AutoPolicy:rewriting options are set to No rewriting for the URL of the web application

As can be seen in the above example, the web application I’ve created is for a  sample WIF application https://contoso.mydomain.com/sts.

Add the default Users role to the Selected Roles (or roles of your choice).

A bookmark is automatically created for the web resource profile.

Let’s logout of the administration interface and logon to the gateway (e.g. https://gateway.mydomain.com).

The user must enter their user ID, AD password and PIN/OTP code.

In the web bookmarks, we see the Contoso Web application created earlier.

Clicking on the Contoso Web application will take us to the WIF application and initiate Steps 1-8 described in the Peer Mode Configuration, with the notable exception that Step 4 will now be removed as we already have a valid SAML token (and AD FS trusts the Juniper IdP as a Claims Provider).

All good, but when I hit the AD FS proxy, I hit that pesky home discovery dropdown and users must choose between AD FS or Juniper as their claims provider.

This process of having to select the home realm may be acceptable to your users, but if not, we need to look at alternatives that address this home realm issue.

Smart Links and IdP-Initiated Sign-On

Smart-links may be familiar to those who work with Office 365. They can be used in conjunction with applications such as Outlook Web App, to reduce hop count and speed up the login process.  A good article on them can be found here:

http://community.office365.com/en-us/w/sso/using-smart-links-or-idp-initiated-authentication-with-office-365.aspx

They potentially have a role to play with IdP-Initiated Sign-On scenarios with the Juniper where web application and single-sign on can be processed  with the minimum of fuss and limit user intervention in the sign-on process. More importantly, we can bypass home realm discovery for the Juniper IdP as a  claims provider. This can be accomplished by incorporating smart links into bookmarks.

For example, let’s say that the URL of AD FS 2.0 server is sts.mydomain.com. I can provide information in the query string about my relying party and the claims provider that needs to process the logon,  accomplished through the wtrealm (relying party) and whr (claims provider) values. This is particularly useful because the home realm discovery selection process in AD FS, where the user has to select the claims provider (e.g. AD or Juniper) can be confusing. By creating a web resource profile for  AD FS, we can exploit the use of smartlinks for bookmark / hot linking access web applications. Using the examples from earlier, I want to create a bookmark for my Contoso web application.

To accomplish this, on the Juniper, we can update the AD FS web resource profile and go to the bookmarks tab. We can then create a new bookmark, Contoso Web  (you’ll need to clean up the stale Contoso Web bookmark that was creating earlier in the post to avoid duplicates) and use the following URL:

https://sts.mydomain.com/adfs/ls/?wa=wsignin1.0&wtrealm=https://contoso.mydomain.com/sts/&whr=https://gateway.mydomain.com/dana-na/auth/saml-endpoint.cgi

This allows bypassing the home realm discovery dropdown and go directly to the IdP (Juniper) for sign-on.

Note that SP-initiated sign-on is still possible. If we do not wish to allow this or wish to handle it differently, there are a couple of further options. On the AD FS proxy instance we may choose to:

• automatically select a given realm by customizing the sign-in pages to hard-code the Juniper for selection.
• disable home realm discovery by forcing the use of the whr parameter as the only supported variable for accessing claims providers. Jon Torresdal talks about this in his blog article here: http://blog.torresdal.net/2010/04/19/HomeRealmDiscoveryInWIFAdADFS20ByQueryString.aspx

Home Realm Discovery Cookie Persistence

Under the <microsoft.identityServer.web> of the web.config on the AD FS proxy, we can disable persistence for the identity provider selection

<persistIdentityProviderInformation enabled="false”

This limits the validity of the identity/claims provider selection to the current browser session, meaning that home realm discovery and the provider selection dropdown will re-appear next time the user logs on.  If you’re not customizing home realm discovery on the AD FS proxy then it’s probably a good idea to set this value.

Note that this changes are limited to and scope-wise affect the AD FS proxy only.

Mixing IdP and SP-Initiated Sign-On

So far in the configuration examples, we’ve aligned IdP and SP-Initiated Sign-On, using the same authentication schemes. However, there are scenarios whereby this may not be desirable. In an IdP initiated sign-on scenario, for example, we may wish to use some sort of additional controls (e.g. host-checking) on the Secure Access gateway for clients. For managed clients, should the client pass host-check validation, we may wish to accept a weaker form of authentication (e.g. username and password)  at the gateway. Conversely, in peer mode, we may opt to continue to use two-factor authentication, irrespective of the client type, because we are bypassing host-checking functionality.  This flexibility is possible because we can shift the sign-on policies and override the default peer mode configuration for our service provider (AD FS). This allows us to take advantage of the security handshaking/enforcement capability of the SA platform to better effect, and, at the same time, allows things such as browser favorites/bookmarks to be preserved when accessing the service provider via SP initiated SSO, something that gateway-induced logon is often accused of breaking.

In either case, on the AD FS side, no change in the claims provider configuration is required because the switching is handled on the Juniper side, according to whether IdP or SP-initiated logon is taking place.

Summary

From an access scenario point-of-view, I’ve been looking at cases where both the Juniper and AD FS can operate in an IdP capability.  Internally, AD FS 2.0 can fill the gap and act as an internal identity provider to the Juniper (service provider) for claims-enabled processing and Kerberos SSO capability. Externally, the Juniper provides a broad access platform to operate from and, in turn, an identity provider to AD FS and indirectly relying party applications behind it. In a split DNS configuration this allows you to reap the benefits of both platforms (as per the diagram above).

As ever, test, test, test and break the back of that beast they call test before putting this sort of thing into production…

Have fun!

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&#8217;, 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