Shared Authentication Domains on BIG-IP APM

How to share an APM session across multiple access profiles.

A common question for someone new to BIG-IP Access Policy Manager (APM) is how do I configure BIG-IP APM so the user only logs in once.

By default, BIG-IP APM requires authentication for each access profile.

This can easily be changed by sending the domain cookie variable is the access profile’s SSO authentication domain menu.

Let’s walk through how to configure App1 and App2 to only require authentication once.

We’ll start with App1’s Access Profile.

Once you click through to App1’s settings, in the Top menu, select SSO/Auth Domains.

For the Domain Cookie, we’ll set the value to f5demo.com since App1 and App2 use this domain and it is a FQDN. Of course, click Update.

Next, we’ll select App2’s Access Profile. Like App1, we select SSO/Auth Domains and set the Domain Cookie value to f5demo.com.

To make sure it works, we’ll launch App1 in our browser.

We’re prompted for authentication and enter our credentials and luckily, we have a successful login.

And then we’ll try to login to App2. And when we click it, we’re not prompted again for authentication information and gain access without prompts.

Granted this was a single login request for two simple applications but it can be scaled for hundreds of applications. If you‘d like to see a working demo of this, check it out here.

ps

Published Feb 14, 2017
Version 1.0

Was this article helpful?

6 Comments

  • I have this configured for multiple virtual servers and just recently added a new one and it won't work. I have tons of VS's, but for the sake of understanding this let's just say I have 4. They are:

     

    vs1 - outlook.test.com vs2 - sharepoint.test.com vs3 - time.test.com vs4 - newsite.test.com

     

    Here's how the APM cookies are set:

     

    vs1 - test.com vs2 - sharepoint.test.com (persistent) vs3 - test.com vs4 - test.com

     

    VS1 and VS2 and VS3 work just fine. However, VS4 seems to be getting messed up. If I have no sessions and I go to VS4 it works. And then when I go to VS1 it works. But after I've gone to VS1 and if I try and go back to VS4 it never works. In the logs it shows that i'm trying to access the virtual server for VS1 instead of VS4. It's as if it sees the existing MRHSession cookie and thinks it should be bound to VS1.

     

    Thoughts?

     

  • How does this relate to the profile scope? Does the scope need to be set to Global for this to work?

     

  • jojo83's avatar
    jojo83
    Icon for Nimbostratus rankNimbostratus

    hi,

     

    what about the creation of the app2 policy?

     

     

    Thank you in advance

  • Great article But, you should clarify that you´re using the same access policy on both the Virtual Server for App1 and App2.

  • It works well to share the session between App1 and App2, but is it skipping the whole policy workflow of the second app then? So if i have App3 which is secured by a second factor while App1 and App2 are not ... am i bypassing this second factor by logging in at App1 first and then App3? If i check the logging it seems to. And if yes how to solve this bypassing?

     

    dnsApp1.domain.orgApp2.domain.orgApp3.domain.org
    vsvs1vs2vs3
    policyApp1_apm_policyApp2_apm_policyApp3_apm_policy
    scopeglobalglobalglobal
    domain cookiedomain.orgdomain.orgdomain.org
    radius as mfa configured at policynonoyes
    sso (forward auth to backend)App1_sso_profileApp2_sso_profileApp3_sso_profile
  • Yes, in a per-session policy once you have a session in Allow state and have access to the MRHSession cookie, no further prompts will be performed.  The only way to address this would be to use a per-Request access policy on App3 to perform "step-up" authentication.