F5 Access Policy Manager (APM) is an F5 module that has a set of features centering around authentication and remote access.

I recently attended F5’s training course for APM in Seattle.  I definitely gained a better understanding of the different pieces of APM and how they can be used together.  It can play a lot of different roles.  APM is almost less of a pre-packaged solution, than a set of building blocks to make your own solution.  Our use case for it is primarily for the authentication and SSO features.

One thing I was curious about was how multi-domain SSO (single sign on) worked.  F5 APM has SSO features, where the user will auth once to APM, and the APM will present those credentials to the server on the back end.  In multi-domain mode, F5 APM transparently presents the same credentials to multiple different sites on completely different FQDN’s.

We’ve tested it, and I knew that it worked but I was curious to understand how it worked.  Linking sessions between domains is made somewhat harder because HTTP cookies are only sent to the site that created them.  I did some testing while looking at Fiddler, and here’s a walk through on how it works.

In the APM, you configure a list of FQDN’s that are considered to be part of the SSO domain list, as well as a primary FQDN.  In this case lets say the primary FQDN is “login.mycorp.com”, and “site1.mycorp.com” and “site2.mycorp.com” are other sites listed  in the SSO list.  All of those sites point to the APM, to VIP’s that have the same APM access profile applied to them.

Initial Auth

  1. User makes an initial request for site1.mycorp.com.

  2. The APM sends an HTTP 302 redirect back to the user, redirecting them login.mycorp.com.  A querystring is also included in the redirect; it  passes session information to the primary URL (including what the initial URL you requested was).  I’ve substituted ?xyz for the querystring example to keep things short. 1

  3. The APM receives the request for login.mycorp.com, and redirects the user again to /my.policy. 2

  4. The APM runs through the access policy, and authenticates the user (via client cert, form, HTTP prompt, or whatever method you’ve configured) to the primary site.

  5. Once the user authenticates, the APM responds with an “MRHSession” cookie containing session information (valid login.mycorp.com), and redirects the user back to site1.mycorp.com again with a special querystring value containing the session information. 3

  6. The APM receives the request, and decodes to the querystring in order to link the user to the existing session (where the user has already been authenticated).  The APM also sends another session cookie back to the user, this one valid for site1.mycorp.com.  It also redirects the user back to the initial URL they requested. 4

  7. The user’s browser requests the initial URL again.  The user’s browser includes the session cookie for site1.mycorp.com in the request, so the APM is able to tell which authenticated session the request is a part of, and it passes the traffic through. 5

Accessing another Site in the Same Auth Domain

  1. After already accessing site1 (and authenticating), a user makes a request for site2.mycorp.com.

  2. The APM sends an HTTP 302 redirect back to the user, redirecting them login.mycorp.com.  A querystring is also included in the redirect; it  passes session information to the primary URL (including what the initial URL you requested was). 6

  3. When hitting login.mycorp.com, the browser sends the existing “MRHSession” cookie that it already obtained for login.mycorp.com.

  4. Based on the session cookie, the APM associates the user with the existing authenticated session, and redirects the user back to the original site, with a querystring containing session information. 7

  5. The browser sends a request for the original site to the APM (along with the querystring); the APM responds with a session cookie for site2.mycorp.com and redirects the user to the initial URL that they requested.8

  6. The user’s browser requests the initial URL again.  The user’s browser includes the session cookie for site2.mycorp.com in the request, so the APM is able to tell which authenticated session the request is a part of, and it passes the traffic through. 9