Forum Discussion

Rabbit23_116296's avatar
Rabbit23_116296
Icon for Nimbostratus rankNimbostratus
Jan 18, 2016

Shared access session with webtop

I know webtop will ignore mrhsession cookies by design. Running BIG IP 12, What I'd like is any way at all that I can share the existing access allowed session for a webtop (virtual server a) between another APM enabled virtual (virtual server b). Reason being we can't re-challenge for two-factor authentication seeing as content is being served from virtual b from another platform/website.

 

We can't use the standard method for sharing access cookies in APM for various reasons. The main reason is that the user experience is destroyed when you move traffic between data centres (different session/SSO databases on APM).

 

Virtual server a is exposed to the internet, virtual server b is not. I've tried various things, giving virtual b the IP of virtual a, as well as having it totally isolated (preferred). I've tried this link, https://devcentral.f5.com/wiki/APM.ShareAccessCookies.ashx, with no joy at all. It seems to keep the URI/protocol/scheme URI querystring in tact yet when it does the final Location HTTP response, I get nailed with a HTTP 504.

 

When I access virtual B from the internet without APM or a 'dummy allow' AP, all is fine.

 

3 Replies

  • I've even thought maybe an IP whitelist in an iRule datagroup that I can somehow manage. I can whitelist the IP when access session is allowed but then how to remove it when ACCESS session expires/destroyed/logged out presents me with more questions ;)
  • This is from the cookie documentation online with F5: Session Cookie: Persistence Session cookie persistence functions only on BIG-IP LTM+APM deployments. For BIG-IP APM deployments with connectivity resources (such as Network Access, Portal Access, etc.), you cannot set BIG-IP APM cookies as persistent. This is by design, as session cookie persistence can present a security risk. For some deployments of the BIG-IP APM system, as with Microsoft SharePoint, cookie persistence may be required. When you select cookie persistence, persistence is hard coded at 60 seconds.

     

    How can I override this security behaviour?

     

  • Hi Rabbit23 -- it sounds like you're looking for single sign-on where if the user logs into a webtop they are also logged into another virtual server. Have you looked at using SAML authentication? It is designed to implement single sign on for web applications. This would be your access flow: - user goes to the webtop - access policy on the webtop requires SAML authentication and redirects the user to the SAML identity provider - the SAML identity provider authenticates the user however is desired (including your two-factor requirement). - if the identity provider accepted the user, the identity provider gives the user a SAML claim (like a Kerberos ticket -- a bit of data that proves the identity of the user) - the user POSTs the claim back to the webtop access policy - the webtop access policy validates the claim and then anything else you want to check in the access policy (e.g. perhaps group membership) - the user has access to the webtop Later when the user clicks in the webtop to go to "virtual server b"... - user goes to virtual server B - access policy on virtual server B requires SAML authentication and redirects the user to the SAML identity provider - SAML identity provider remembers the user (because of the cookie that the user will send) and if the user's session is still valid it will give the user a claim for virtual server B - the user POSTs the claim back to the webtop access policy - the virtual server B access policy validates the claim and then anything else you want to check in the access policy (e.g. perhaps group membership) - the user has access to virtual server B It doesn't matter that virtual server B is only available internally. The SAML identity provider will need to be externally available however or else no one will be able to login to the webtop. If you don't have a separate SAML identity provider, you can implement within the F5 -- see Access Policy -> SAML.