APM SSO with Atlassian Jira, Confluence and Sharepoint

Hi,

 

For one of our clients we are trying to realize a single sign on solution on our F5 for Atlassian Jira, Confluence, Stash and Sharepoint. To this end we have created a virtual server with an APM policy of type LTM-APM. All websites are published through one and the same Virtual Server. We filter host-headers (HTTP::host) in order to decide which backend server traffic needs to be forwarded to and use different SSO Configurations for connecting to the backend. In addition we used a community iRule to provide for Sharepoint-office integration SSO (as provided here: https://devcentral.f5.com/codeshare/apm-sharepoint-authentication) with some tweaks.

 

Although SSO works we're still struggling with issues that we've not yet been able to resolve and we think are related to the fact that especially Jira and Confluence are stateful HTML5 applications with ajax. This in combination with the fact that there is no integration between the F5 and the backend webservers. These problems are giving me a headache.

 

I've already searched devcentral but have been unable to find a solution for our problems. Amongst others the following problems are encountered:

 

• When a logged on user is inactive for some time he runs into an APM session inactivity timeout (F5 side) and the session is deleted from the session table; This shouldn't be a problem in a normal situation, but the webapplication clientside does not signal the user that the session expired. Now when the user comes back again and clicks somewhere on the webpage 1 of 2 things may happen:

a. The user clicks a link which fires a javascript/ajax/restapi-call; this script may perform a call to the backend server, is blocked by the F5 and redirected to a login page in the background. For the user this means an unresponsive webapplication with a doughnut or an error on the screen (without the F5 in between the user would also get an 'error', but with a possibility to copy data that will be lost and a link to the logon page). For the user the webapplication is broken at this point.

 

b. The user clicks a link that will actively fire a redirect to the F5 login page. This is desirable behaviour from our point of view, but...

 

• In comes the next issue... After a re-login via APM the user is redirected back to the landing-page that initiated the APM_SESSION_STARTED event. Because the webapplication fires all kinds of requests from the client to the server more often than not this process erroneously redirects the user to some page belonging to the rest api or a javascript on the webserver. When redirected to javascript the user sees javascript, when to the rest api it's even more jibberish.

There some other issues too but my post is getting too long i guess so i'll leave them for a different post.

 

We thought of several solutions but up until now none of them really seem to work satisfactory:

 

• Javascript injection (something like this: https://devcentral.f5.com/questions/ltm-apm-session-expired-detection) to detect APM session timeout and actively redirect the user. This however would not solve incorrect redirect behaviour mentioned in my second statement; in addition
• Auto redirect on inactivity would eventually also timeout on the APM loginform after which the original landing page is no longer available;
• Auto logout on serverside; This is a problem however if user is still working in different browser-tab in another application and the application timing out redirects the user to the logon page, which in turn is being detected by the F5, hereby unintentionally killing the APM session altogether and requiring an 'active' user to re-login and potentially losing work;
• Redirect to a default page (for the second issue); this solution is not acceptable to our client;
• Sending heartbeats to always keep the session alive; this would however circumvent active security policies and therefore is not acceptable;
• Using Client Initiated forms based auth and only enable APM for login pages; this seems to work somewhat (inactivity timeout on the serverside provides for the desired behaviour), however, after the first login APM is never being hit again causing an inactivity timeout in no time.

The main goal is to provide a seamless SSO-experience for the users.

 

Any thoughts to resolve these issues would really be appreciated.

 

Thanks, Mark