JIRA session timeout set to 1 hour due to JIRA bug - Okta and 2FA users take note!

[Jeff Turner]

(this is a straightforward bug report, but https://jira.atlassian.com no longer allows reports from mere mortals, and Starter licensees can no longer create support tickets)

As you may know, JIRA's default session timeout these days is 5 hours, as specified in atlassian-jira/WEB-INF/web.xml:

<!-- session config -->
<session-config>
<session-timeout>300</session-timeout>
</session-config>

The problem is that in reality, a session never lasts more than 1 hour.

A 1 hour session isn't much of a problem to regular users who click 'Remember me', but it is a (really annoying) problem for:

- Users of Okta and similar external authentication systems that don't set a long-lasting "remember me" cookie equivalent. Okta users will be redirected to Okta every time their 1h session expires. This gets really annoying.

- Users of 2FA plugins like SecureLogin. Such users will have to re-enter a 2FA token after an hour of inactivity, because the plugin stores its "2fa authenticated" state in the session.  

To see your JIRA's session timeout, add the following JSP to atlassian-jira/secure/sessionattributes.jsp

<%@ page session="true" import="java.util.*" %>
<h1>Session attributes</h1>
<%
Enumeration keys = session.getAttributeNames();

out.println("Session ID: " + session.getId() + "<br>");
out.println("Max Inactive Interval: " + session.getMaxInactiveInterval() + "<br>");
while (keys.hasMoreElements())
{
String key = (String)keys.nextElement();
out.println(key + ": " + session.getValue(key) + "<br>");
}
%>

Then hit https://your.jira/secure/sessionattributes.jsp, and look for the 'Max Inactive Interval' line, which returns the HttpSession.getMaxInactiveInterval() value (i.e. session length). You'll probably see:

Max Inactive Interval: 3600

3600 seconds == 1 hour.

The problem is the Bot Killer plugin. Bot Killer initially sets the session timeout to 1 minute, and then it meant to set it back to the default on the second request. But it's buggy: sessions always get set back to 1 hour.

To demonstrate this for yourself, remove your JSESSIONID cookie, then hit /secure/sessionattributes.jsp (logging in if necessary). On first hit, 'Max Inactive Interval' will be 60. On second hit it becomes 3600.

Disabling the Bot Killer plugin is a simple and safe fix. Afterwards (and after removing your JSESSIONID) 'Max Inactive Interval' should report '18000' = 5h.

[Rick Carini]

Okta is reporting the following:

https://help.okta.com/en/prod/Content/Topics/ReleaseNotes/production.htm

Okta Production 2017.49 began deployment on December 11 

JIRA and Confluence SAML toolkits updated to version 3.0.6

This version supports the following:

• Support for adding Remember me cookie during JIRA logins.
• Fix for new sessions not being created for Jira and Confluence apps when an already logged in user re-authenticates with a new SAML assertion.
• SP-initiated flows are disabled for Confluence users that are not present in Okta.

For version history, see Confluence Authenticator Toolkit Version History and JIRA Authenticator Toolkit Version History.

I have not tried it yet, so I don't know.

[Jeff Turner]

Atlassian finally fixed this bug in Jira 8.5.6 (https://jira.atlassian.com/browse/JRASERVER-70574).

[Sysad]

Hi @Jeff Turner 

When I hit url/sessionattribute.jsp I get a dead link. Any idea why?

[Jeff Turner]

Is atlassian-jira/secure/sessionattributes.jsp present? Is it readable by the user Jira is running as?

[Sysad]

Thank you for your reply. The issue is with the file permissions. And below is what I see, 

Session attributes

Session ID: 43EF
Max Inactive Interval: 3600
atlassian.xsrf.token: B0CJ-
ASESSIONID: jcj7vl-43EFDBDCEADAE7688C27AD
com.atlassian.labs.botkiller.BotKiller: 28800

I have removed session cookie and I saw rest to 3600, now I am not sure where to disable bot killer any suggestions?

Thanks

[Lars Olav Velle]

This bug has been around for some time, and every SSO-vendor should know about it. We reported the bug to Atlassian, but I do not know the status of that case.

Our experience was that there were a few prerequistes for it to happen though.

We (Kantega Single Sign-on) implemented a fix for it  2016-11-21 in version 1.68 our add-on. That is also the reason we added the following to our debug information page.

sesssion: {maxInactiveInterval: 18000, lastAccessedTime: Fri Aug 25 08:46:55 CEST 2017}

-Lars

[Alexander Kueken]

Hi Jeff,

Thank you for finding the reason behind this issue. We had two customers, who had the problem, that they had to revalidate the Secure Login PIN in a very short interval. But we were not able to reproduce the issue on any of our test systems. But your finding should explain the issue.

Regards,
Alexander

[Martin Beke]

Hi Jeff, 

we have that the same problem, when we can expect that the problem will be solved?

Thanks and Regards

Martin Beke