Forum Discussion

JP88730K_296639's avatar
JP88730K_296639
Icon for Nimbostratus rankNimbostratus
Oct 25, 2016
Solved

APM Session Visibility across VIPs

What is the best way to establish session visibility across multiple APM sessions without a SSO configuration or a persistent cookie? My site hosts projects which have multiple virtual servers. We use PKI certificate information injected into HTTP headers for authentication and APM message boxes for EULA compliance. Some sites use Active Directory for authentication but others use OpenLDAP or local user databases populated with certificate information.

 

We have a requirement to suppress all but the first EULA messages when users browse sites within the same project. For example, if a user goes to payroll1.company.com they should receive a EULA message. If they then go to payroll2.company.com they shouldn’t receive a second message box, but if they go to sales.company2.com they should receive a second EULA prompt.

 

APM
application delivery
  • Lucas_Thompson_'s avatar
    Lucas_Thompson_
    Oct 25, 2016

    The browser must simply include the cookie in the request to be associated with the session. RFC 6265 defines exactly how this works, if you aren't familiar with it. The wikipedia article on HTTP cookies is also very good.

     

    Customers usually choose one of the following options to share the cookie across multiple vips/hostnames:

     

    1. Set the cookie domain to be wide like ".company.com" so that the cookie will be transmitted to *.company.com.

       

    2. Use APM's multi-domain mode so that when APM gets a request without a cookie, it will "check with" the domain set as the primary-authentication URI to see if it's been set. This happens by using some 302 redirects between the hostanmes/vips.

       

    For either of these options, make sure the session scope is set appropriately.

     

4 Replies

Sort By
  • JoshBecigneul's avatar
    JoshBecigneul
    Icon for MVP rankMVP
    Oct 25, 2016

    A way to achieve this with out-of-the-box behavior would be to have payroll1.company.com and payroll2.company.com use the same access policy, and sales.company2.com should use a separate access profile.

     

    When a profile's SSO setting is in "Single Domain" mode, if you set the domain cookie to "company.com", then as long as the users for each site connect to other VIPs with the same policy with in their session timeout period, they should not go through the login process again. You can narrow this down to particular sites, and not domains, using the "Multiple Domains" setting.

     

  • Lucas_Thompson_'s avatar
    Lucas_Thompson_
    Historic F5 Account
    Oct 25, 2016

    The browser must simply include the cookie in the request to be associated with the session. RFC 6265 defines exactly how this works, if you aren't familiar with it. The wikipedia article on HTTP cookies is also very good.

     

    Customers usually choose one of the following options to share the cookie across multiple vips/hostnames:

     

    1. Set the cookie domain to be wide like ".company.com" so that the cookie will be transmitted to *.company.com.

       

    2. Use APM's multi-domain mode so that when APM gets a request without a cookie, it will "check with" the domain set as the primary-authentication URI to see if it's been set. This happens by using some 302 redirects between the hostanmes/vips.

       

    For either of these options, make sure the session scope is set appropriately.

     

    • JP88730K_296639's avatar
      JP88730K_296639
      Icon for Nimbostratus rankNimbostratus
      Oct 25, 2016

      So if I go with the first option and set a domain wide cookie, can it's existence be queried in APM?

       

      expr {HTTP::cookie exists *.company.com} to Allow

       

      fallback to EULA prompt

       

    • Lucas_Thompson_'s avatar
      Lucas_Thompson_
      Historic F5 Account
      Oct 25, 2016

      APM has session state management built-in, you don't need to do anything like that. Also that's not really the right way to call HTTP::cookie.

       

      If the browser transmits the APM session cookie (MRHSession) and the session is in "allow" state, then the request will be allowed without re-executing the access policy.