Big-IP and ADFS Part 3 - “ADFS, APM, and the Office 365 Thick Clients”

Okay, so I never mentioned a part 3. But, the topic is just too much fun to let go. Besides, we have one more important section to cover.

First, let’s recap parts one and two. In part one we discussed load balancing the ADFS and ADFS proxy farms providing for a highly-available and scalable deployment. Part two focused on utilizing the Access Policy Manager, (APM) module as a replacement for the ADFS proxy layer. This not only creates a more secure and flexible solution but simplifies the infrastructure.

As you may recall, (if you’ve been following along), Office 365 was the use case for part two as we showed how the Big-IP with APM could provide pre-authentication and SSO sign-on for Outlook Web Access, (OWA). However, when it comes to accessing Office 365 resources from thick clients, (aka active protocols and active profiles), including Outlook and the Lync client things become a little more complicated. Let’s take a look.

Passive Protocol – (Outlook Web App)

Clients using the WS-Federation passive protocol, (primarily browser-based) process is as follows:

1. The client attempts to access the Office 365 resource;
2. The client is redirected to the Microsoft Federation Gateway
3. The client is redirected to their organization’s internal federation service, (AD FS);
4. The AD FS server authenticates the client to active directory;
5. The AD FS server provides the client with an authorization cookie containing the signed security token and set of claims for the resource partner;
6. The client connects to the Microsoft Federation Gateway where the token and claims are verified. The Microsoft Federation Gateway provides the client with a new service token; and
7. The client presents the new cookie with included service token to the Office 365 resource for access.

In the above case AD FS is using the WS-Federation protocol and SAML. This type of connection can be greatly enhanced by using the Big-IP’s APM to proxy the connections to AD FS.

Active Protocol – (Outlook & Lync Clients)

The interaction of clients like Outlook and Lync, (external client), is slightly different. In this case, the process utilizes the active protocol, WS-Trust, and SOAP.

1. The client attempts to access the Office 365 resource and provides credentials;
2. Office 365 looks to the Microsoft Federation Gateway for authentication;
3. Microsoft Federation Gateway contacts the AD FS service on behalf of the client and presents the credentials;
4. The AD FS authenticates the client credentials with active directory;
5. AD FS provides the Microsoft Federation Gateway with a token; and
6. The Microsoft Federation Gateway provides the Office 365 resource with the token allowing the client to access the resource.

In simple terms, rather than the client doing the leg-work required to request and get the token from AD FS, the Microsoft Federation Gateway interacts directly with AD FS. Since the client is not connecting to AD FS itself APM, (or any proxy service) cannot be used.

So, here’s the challenge. How do we allow the Microsoft Federation Gateway direct access for authentication of the thick clients, (Outlook and Lync) when deploying AD FS behind the Big-IP and APM while still pre-authenticating the passive connections, (browser-based and internal Lync)? It’s simple really; we’ll use an iRule.

APM Bypass iRule

To allow for direct access by the MS Federation Gateway, an iRule is created and assigned to the ADFS virtual server created in part two of this series. The iRule uses the HTTP_REQUEST event, (triggered when the system parses the HTTP request) and analyzes the URI. When a relevant request is received, the ACCESS::disable command is called disabling access policy enforcement and allowing the request through. For additional guidance on the third party proxy requirements, please refer to Microsoft’s guidance. Create and assign the following basic iRule to the external AD FS virtual server.

   1: when HTTP_REQUEST {

   2:  

   3:   # For external Lync client access all external requests to the

   4:   # /trust/mex URL must be routed to /trust/proxymex. Analyze and modify the URI

   5:   # where appropriate 

   6:   HTTP::uri [string map {/trust/mex /trust/proxymex} [HTTP::uri]]

   7:  

   8:   # Analyze the HTTP request and disable access policy enforcement WS-Trust calls

   9:   if {[HTTP::uri] contains "/adfs/services/trust"} {

  10:     ACCESS::disable

  11:   }

  12:  

  13:   # OPTIONAL ---- To allow publishing of the federation service metadata 

  14:   if {[HTTP::uri] ends_with "FederationMetadata/2007-06/FederationMetadata.xml"} {

  15:     ACCESS::disable

  16:   }

  17:  }

That’s it! Pretty straightforward right? Give it a try and let me know how it goes. Since we are working with external access I did not address AD FS 2.0 support for identifying and blocking external access. But, if you're interested in this advanced feature, please refer to Microsoft’s guidance.

Additional Links:

Big-IP and ADFS Part 1 – “Load balancing the ADFS Farm”

Big-IP and ADFS Part 2 – “APM–An Alternative to the ADFS Proxy”

BIG-IP Access Policy Manager (APM) Wiki Home - DevCentral Wiki