F5 is upgrading its customer support chat feature on My.F5.com. Chat support will be unavailable from 6am-10am PST on 1/20/26. Refer to K000159584 for details.

Forum Discussion

2 Replies

  • There are generally 3 built-in methods for session sharing:

     

    1. Domain session cookie – setting the domain attribute of the APM session cookie to a common denominator between the VIPs (ex. .example.com) will allow the browser to send this same session cookie to all of the matching host names. If there’s an active and valid session on the APM that matches this session token, then it will use this access session.

       

    2. Multi-domain mode – this mode creates a mechanism that allows APM VIPs to share session information between them. You typically configure a single “logon” VIP for authentication and configure each app VIP to redirect to the logon VIP, which then authenticates the user and redirects them back with a session token. This can be done with a domain cookie (see above) or an encrypted URI that points back to the valid session.

       

    3. Federation – APM SAML allows you to establish a trust relationship between any number of identity providers and any number of service providers. Similar to the multi-domain mode described above, a user authenticates at the identity provider and forwards a signed XML assertion to the service provider. Unlike the multi-domain mode, however, the IdP and SP can be on different boxes and actually be provided by different SAML-capable vendors.

       

    The key to all of these methods is browser behavior. In order to get a browser to send a cookie generated at one host to another host, you need to make it a domain cookie, otherwise you need to insert some crafted URI, JavaScript, etc. to make the browser send information about the first host to the second.

     

  • We have two sites with two different login pages and two different VIPs/APM policies and two different hostnames - www.example.com and www.project.com... would that option still apply??

     

    Yes it would. Keep in mind though that options 1 and 2 above will "short circuit" any subsequent access policy evaluations. So for example, you have two different applications and you want to authenticate users to the second by virtue of authenticating to the first. You can simply share the session cookie with a domain attribute, or flow through the multi-domain config in APM, but once you have a valid session token from the first policy, all subsequent policies in other VIPs are ignored. If you wanted to do something extra in the other policies (an additional LDAP query for example), this too would be ignored. That may not be an issue in your case as you can usually grab everything you need from the initial authentication. But should you need something more distinct per APM VIP, then the 3rd option may be more fitting.