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
dp_119903Cirrostratus
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?
Stan_WardAltocumulus
How does this relate to the profile scope? Does the scope need to be set to Global for this to work?
jojo83Nimbostratus
hi,
what about the creation of the app2 policy?
Thank you in advance
SqueakCirrus
Great article But, you should clarify that you´re using the same access policy on both the Virtual Server for App1 and App2.
- Irre_Levant
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?
dns App1.domain.org App2.domain.org App3.domain.org vs vs1 vs2 vs3 policy App1_apm_policy App2_apm_policy App3_apm_policy scope global global global domain cookie domain.org domain.org domain.org radius as mfa configured at policy no no yes sso (forward auth to backend) App1_sso_profile App2_sso_profile App3_sso_profile - Walter_Kacynski
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.
