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!