Forum Discussion

David_Wanna's avatar
David_Wanna
Icon for Nimbostratus rankNimbostratus
Nov 14, 2023

APM Portal Links SSO with Azure AD

Hi,

   We have an APM portal using AD authentication.  We recently transitioned to using Azure AD MFA to log into it.  This was done by following the solution to integrate APM with Azure AD using the bigIP as a SAML SP and works without issue.  However, after logging into the portal and clicking on any of the links for the the various apps (which are also Azure AD integrated) the user must go through the login process with Azure AD all over again which is anyoing.  Is there a way to somehow use the original SAML authentication from loging into the portal to seemlessly be logged into the various apps?  Interestingly, once the user clicks on subsequent apps after the second login, they are logged in automatically so I believe it's able to use the session tokens stored in the browser for subsequent logins after the second login (but not after the initial log in to the portal).

 

application delivery
azure ad
BIG-IP Access Policy Manager (APM)
portal
SSO

3 Replies

Sort By
  • Lucas_Thompson's avatar
    Lucas_Thompson
    Icon for Employee rankEmployee
    Nov 14, 2023

    Once APM receives a SAML assertion from an IdP, it should usually finish authentication and the user's session should be in "Allow" state.

    Upon the first network request without a cookie, APM creates a session ID and sends it to the client in an "MRHSession" cookie. Upon each subsequent network request, the client should transmit this cookie and to tie the request to the user's session. It sounds like for whatever reason, your login session isn't following this pattern.

    To see why, use your browser's dev tools to examine the cookies sent and recieved by your user's browser. It might be that you're using multi-domain mode (when you visit a host with no MRHSession cookie, the APM will redirect you to the "Primary Authentication URI" for login, then redirect back to the original URI and use some HTTP redirect tricks to share the MRHSession cookie between the domains specified in the config). This is where that multi-domain mode is set up:

    The problem could also be something else, but in any case looking at the network requests and cookies in your browser dev tools will get you closer to an answer.

    • David_Wanna's avatar
      David_Wanna
      Icon for Nimbostratus rankNimbostratus
      Nov 29, 2023

      Thanks Lucas_Thompson .  We are using Single Domain.   I tried looking at the cookies but there are a lot of cookies involved with Azure AD (EntraID) and it's not obvious which ones are relevant to authentication.  It seems to me that the issue as follows:

      1- When you first go to our VPN portal hosted by APM, the SAML auth immediately redirects you to login.microsoft.com where you go through Azure MFA.

      2- At this point you have a valid auth/session cookie but (I think) it's only valid for login.microsoft.com.

      3- When you click on an internal resource withing the portal, the app also redirects you to login.microsoft.com but this time it's rewritten by the portal to:  https://'ourvpnportal'.bah.com/f5-w-68747470733a2f2f6c6f67696e2e6d6963726f736f66746f6e6c696e652e636f6d$$/d5fe813e-0caa-432a-b2ac-d555aa91bd1c/saml2.  Where the string after f5-w- equates to the hex translation of https://login.microsoft.com.

      4- Because login.microsoft.com is hex encoded,  the browser cannot use the existing session cookie for authentication and the user must authenticate again but this time will get a cookie that is valid for ourvpnportal.bah.com and doesn't need subsequent authentications.

      Does this make sense?  Is there a way to somehow use the cookie from step 1 in step 3 so that users don't have to authenticate a second time?

      Thanks in advance.

  • Lucas_Thompson's avatar
    Lucas_Thompson
    Icon for Employee rankEmployee
    Nov 29, 2023

    Yes this makes sense. What's happening is that you're doing a federated logon with MS, then using an access policy that puts you into "reverse-proxy mode", the f5-w-xxxx thing is APM's rewriting reverse proxy (aka portal access) which has a kind of "cookie proxy" function, so the real cookies from the browser and the cookies set by the browser *during the rewrite session* are completely separate. It's weird and confusing.

    This unique rewriting reverse proxy functionality in APM was originally designed to support legacy apps that tended to use java applets (it decompiled them and recompiled them on the fly, automatically wrapping all networking functions into special APM wrappers), flash content (this worked the same way as applets), and many servers with random ports, where some of them might be linked from just static IP addresess instead of proper names (remember those days?). The only way to make these apps work via a single DNS name (ourvpnportal.blah.com, or whatever) was to intercept and rewrite all of these links and hostnames, AJAX requests, and cookies to access APM instead of where they were originally intended. Modern web apps are nothing like this and usually only occupy a singe hostname on a single port, so there is not much need for the rewriting reverse proxy any more. We usually recommend avoiding it if possible because it causes headaches like you're trying to solve now.

    If you want to proceed with the rewriting reverse proxy mode anyway, your best bet is to contact Support so they can analyze the traffic pattern exactly and recommend how to configure the rewriter to work in your specific situation so it does not rewrite the Microsoft/Azure auth links. If you want to read about how this works, the following sol should help:

    https://my.f5.com/manage/s/article/K11722121