A user who has logged in to Jira via 2FA (Keycloak) Opens an Edit-sceeen in Jira. In the meantime the user is working on other things. If the user Updates the Edit-screen aftere 1 hour, he has to login again. This is not the case if the user logs on with userid/pwd without Keycloak.
It seems that the cookie JSESSIONID has changed and it contains another value.
Can anyone please help me to solve this problem?
Below more info about versions/settings:
Keycloak:
Version: 10.0.2
Java Version: 1.8.0_265
OS: Ubuntu 18.04, Linux 4.15.0-121-generic x86_64 (not the same machine as Jira)
Jira:
v8.9.1
OS: Ubuntu 18.04, Linux 4.15.0-121-generic x86_64 (not the same machine as Keycloak)
Description of the problem:
A user logs in succesfully to Jira, with 2FA via Keycloak.
The user opens several Edit-screens.
After one hour, while the Edit-screens have been idle, the user has to logon again.
Settings in Keycloak:
Realm Settings/Tokens:
SSO Session Idle: 1 Days
SSO Session Max: 1 Days
SSO Session Max Remember Me: 0 minutes
SSO Session Idle Remember Me: 0 minutes
Offline Session Idle: 30 Days
Offline Session Max Limited: OFF
Client Session Idle: 1 Days
Client Session Max: 1 Days
Access Token Lifespan: 1 Days
Access Token Lifespan For Implicit Flow: 5 Hours
Client login timeout: 1 Minutes (changing to 5 hours did not help)
Login timeout: 30 Minutes (changing to 5 hours did not help)
Login action timeout: 5 Minutes (changing to 5 hours did not help)
User-Initiated Action Lifespan: 5 Minutes (changing to 5 hours did not help)
Default Admin-Initiated Action Lifespan: 12 Hours
Override User-Initiated Action Lifespan: -
What happens in Jira:
In the browser a cookie has been created: JSESSIONID
Data in JSESSIONID:
A value, for instance: *****************************
Domain: *********************
Expires: Session
After one Hour the cookie has been replaced by one with another value.
A refresh of one of the above mentioned Edit-screens results in the following message:
XSRF Security Token Missing
Jira could not complete this action due to a missing form token.
You may have cleared your browser cookies, which could have resulted in the expiry of your current form token. A new form token has been reissued.
Request URL: /secure/QuickEditIssue.jspa
Please log in and retry this action.
We have captured the submitted values (shown below). Please copy it now. This text will be lost when you leave this screen.
…
…
Hi,
i believe there are several options to connect Jira to an IDP. What plug-in or configuration type did you use?
Here’s the background of the question:
If you log into the IDP you receive a token with a lifetime (access token) and a refresh token that allows to connect to the IDP to pick up a new access token. Thats what you configure and you try to extend.
Now in some configurations the IDP is no longer validating the token but instead the token is used to create a separate session (as you see the JSESSIONID - the domain is the Jira server, not the IDP).
So in that configuration the IDP is no longer in the game, meaning no one is checking with the IDP for the validity of the access token. Instead, the user ID was extracted from the token, the new session was created (a matter of trust) - and you are turning the wrong knobs.
Solution options:
Perform a configuration that leverages the IDP after login to validate / extend the session
Configure the Web Server where Jira runs on to get a longer session.
I’m sorry but i just did straight analysis. I’d recommend you contact the vendor of the plug-in - i tried to access the documentation but i don’t have access.
I’m pretty sure that this is a “standard” issue many fall over, but the keycloak forum here may be the wrong place to look for resolution. Keycloak works fine for you.
It turns out that Jira sends a GET http-request to Keycloak after one hour, to relogin with ‘noprompt’; this will not work of course, while there is no-one to add a userid, password and a new token.
The question is, where does the GET come from. It comes obviously from Jira, while I saw it’s ip-address in the tcpdump, but in Jira all timers in all configfiles are set to at least 5 hours to exclude the cause of the problem; also the Atlassian Bot Session Killer has been disabled.
So there seems to be something else in Jira. The problem does not occur without the implementation of Keycloak, so we have to focus on the difference with/without Keycloak. Then one difference is the SSO Keycloak plugin. It seems odd, but might it be possible that this plugin causes the problem?
It must be the plugin as this is the only piece knowing the connection to keycloak.
I did not find any “relogin noprompt” stuff but conceptually it could just do what is required:
Imagine, it would take the refresh token and send it to keycloak in the backend to receive a new access token. That would possibly do what you look for, but in this case you need to have some config options for the timing (oh yes it could read the validity from the initial login and autoconfigure).
It would be interesting to know:
When you do the login first time to Atlassian, are you being redirected to login on the keycloak page? Or is there a password field that you fill on a page hosted by Atlassian?
My suggestion in the first paragraph makes only sense in the 2nd case.
We solved the problem by using the SAML-protocol instead of the Open-Id-protocol.
If you have the Datacenter-version, SAML is available in jira, but if you have the Server-version, you need a plugin. The plugin of 2ImproveIT is a very good solution, and much cheaper then the solution of Reichert.
Thank you for your very quick response, I really appreciate it
We are actually on sever version and we’ve just applied SSO to our agents … but 1h session timeout
I’m going to take a look to 2ImproveIT’s plugin.
for you.