Hey d52cf31001ec , it was stated in related ticket ACCESS-592 that they are pushing to release this feature by the end of June. Can someone from Atlassian confirm? Thanks

Hi 9296fec66f8a - is there any update on this? We haven't seen a status update since October, and this is still a pressing issue for our security posture.

Hi 9296fec66f8a - is there any update on this project?

I see this has been reassigned to 9296fec66f8a  - is this still actively in progress? Is there a status update we can get on this feature?

Please see ACCESS-592 (Same issue). The assignee, Holly, is coming up as inactive on both of these tickets and there is no update on this feature being released. Please give us an update, thank you!

Thank you d056dd6d7b90 ! We really appreciate your attention to this issue!

We are now actively working on this feature request and will provide updates on timelines as we have them. Thank you for all of your feedback.

Hi 23ef3e30d63c and d056dd6d7b90 ,

Has there been any further update on this? We've been going back and forth with Atlassian Support on this for several weeks, and were finally able to get to the core of the issue, and it seems very closely related to what's outlined here.

We have a recent security requirement from a few of our fortune 100 clients to enforce a 20 minute idle session timeout. When this is managed in each application that we use independently, it's very burdensome for our users. When users work in Jira, then jump over to use other applications (for 21+ minutes), and then come back to Jira, they must reauthenticate at every context switch, resulting in our staff needing to re-authenticate as much as 24 times a day - I love Atlassian, but this is a deal breaker and may push us to look at solutions other than Atlassian if it can't be solved in a timely manner. 

The current experience: Atlassian manages it's own heartbeat and idle session timeout totally independently of the SSO provided session. This is the antithesis of what SSO is meant to accomplish - when SSO is enabled through federated access, the federating authentication platform (Okta in our case) should at least be able to be configured to provide the session heartbeat - essentially federating that responsibility to the SSO provider.

The expectation: We have a 20 minute global session idle timeout, and 12 hour max session timeout set via Okta - Atlassian should honor those, and the heartbeat should both be passed through to Okta to keep the current session alive, and check whether the Okta user current session is still alive. If the session is not still alive (as determined by Okta) the Atlassian session should force re-authentication. IdP session policies should supersede Atlassian policies, and with that clear bright line, it becomes less cumbersome to troubleshoot arising issues.

We're also very interested in Atlassian Guard Premium, and applying this sort of policy to various levels of data classification (something like 20 minute timeout for more restricted data classification, but 2 hour timeout for less restricted data). This is only really possible for us though, if Atlassian shares the session heartbeat with our IdP.

Thanks for your time and consideration.

Atlassian, we are looking to you for a quick fix of this serious security flaw.

We have actively started investigating this feature and will provide more updates as we have them.