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

Jeff Turner
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
August 24, 2017

(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.

5 answers

1 vote
Rick Carini December 12, 2017

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.

0 votes
Jeff Turner
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
July 29, 2020

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

0 votes
Sysad October 18, 2019

Hi @Jeff Turner 

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

Jeff Turner
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
October 18, 2019

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

Sysad October 21, 2019

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

0 votes
Lars Olav Velle
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
August 24, 2017

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

0 votes
Alexander Kueken August 24, 2017

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 April 30, 2019

Hi Jeff, 

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

 

Thanks and Regards

Martin Beke

Suggest an answer

Log in or Sign up to answer