Hello, is it ok now?

9296fec66f8a, thank you, please be sure to update us. Appreciate your help!

Thank you 9296fec66f8a and eee30c920d0f for responding and updating us in a timely manner.

This issue needs to be addressed immediately. Waiting until the end of the year is too long, given the impact this issue is having.

Since transitioning from ServiceNow to JSM last week, we've been dealing with a major flaw: tickets are being created under the wrong accounts, causing incorrect users to receive constant notifications. This is creating confusion, unnecessary disruptions, and a significant operational headache.

This fix cannot be delayed. I strongly urge you to escalate its priority and push for a sooner resolution. I’m certain other teams and organizations are facing the same issue, and every day this persists, the problem compounds.

Thank you!

I confirm that we are on track to deliver this by end FY25 Q4

686b6de14f53 9296fec66f8a Please post an update. We are on track for FY25 Q4 delivery.

Hi, I see that assignee is inactive we are still waiting for solution ASAP

Hello d056dd6d7b90, any update on this issue? This poses as a big security risk for our organization of 30k+ users. I do not see any updates on a launch date on any of these tickets and on Atlassian Administration. I do also notice that linked ticket ACCESS-1655 has nobody assigned to it. We hope to hear from your team soon, thank you.

it's just to call url disconnet/SAML provider after log off!

could you correct it ASAP!!!

Is the same feature also available in your “SSO for Atlassian Data Center” app?

Thank you for all of your feedback, we are now actively working on this feature request. We understand the importance of it, and we are prioritizing it accordingly. Please stay tuned for updates on a targeted launch date, we will have that for you in the new year. in the meantime, please do continue to leave your feedback here.

All of the other system administrators on my team manage apps that support SAML logout. Please prioritize this critical security feature so I don't have to be the odd one out when we talk about SSO security config

What we need to fully implement SSO on our site is a "log out URL" field in the SSO configuration policy that defines what URL the end user is taken to when they trigger the log out action. We maintain a webpage that destroys the existing SSO token to solve this exact issue, but we need to be able to send people to it.

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.

a745b7e6ce60 per comment in https://hello.jira.atlassian.cloud/browse/ENT-2303, this is the opposite scenario and is not a dupe.

Please ensure that this BUG is fixed swiftly! This missing functionality is currently causing major problems in our site, and we see that our users seek workarounds in stead of using the Service Desk, in order to ensure that their user is not misused (by a mistake) by their colleagues. 

Atlassian, are you kidding?

@Steve Letch - Which plugin?

We've resorted to using a third party plugin for the SAML SSO because the native Atlassian one is so broken in Confluence

As a previous commenter indicated, the inclusion of a logout pingback URL in the SAML settings is essential to a secure configuration.

Not only SAML, also for OpenIDC.

This ticket seems to be for DataCenter, but a Cloud ticket was closed as duplicate of this. My usecase is Cloud.

When our company SSO kicks a user out, Atlassian does not provide a pingback url which our SSP provider can call, so user is still logged in (for days) while the account is blocked for all other systems.

Due to this, we have to set a very short idle timeout interval to enforce daily relogin (our rules say: every 30min) and users complain about this. So both this ticket and the too-complex relogin (Atlassian asks for the email after an idle timeout, instead of just forwarding to the SSO which user used on last manual login) drive our users nuts: Allow automatic redirects to the SSO provider when logging into a site

If we have a reliable way to automatically end user's sessions, we could allow a very long idle time, making live much easier for everybody.

I just want to make it very clear that from my standpoint this is not a feature request but a BUG. For two reasons:

First, as much as I understand that from Atlassian’s perspective it doesn’t matter if the user is still logged into their IdP account, I want to make it clear that this is a major security issue for all Atlassian customers using SSO. I can't rely on services like internet cafes, libraries and kioskies to have the IdP session cleared after each user.

Second and most importantly, if Atlassian offers me the option to login as a different user but IS NOT CAPABLE OF CARRYING IT THROUGH TO THE END, this is a major user experience flaw.

I will vote on this "suggestion" or "feature request" as you want to call it, but this is clearly a bug in the system!

Hi Moses, I'm not able to attach a file or screenshot through comments. I'm trying to think of the best way to share the screenshot with you of the settings that were updated in our access control policy for AD federated services configuration for Atlassian.

@Cassandra Shivers,  Pls how did you solve it pls could you attach images on how you solve this problem it is urgent that we solve it. The only work around is to clear cookies on web browser when you log out.

Does Atlassian realize the security implications for enterprises if SAML2 logout is not supported.... ?? I am pretty sure that they do not ... no wonder the security maturity seems lacking in Atlassian products...

What's resolved the issue for us, was turning on an access control policy in our AD federated services configuration for Atlassian.

(Edited to add: Doesn't look like I can embed or attach a screenshot of the particular setting.)

Has there been any development regarding this issue? It is still occuring.

What is your recommendation for companies who use shared computers with Atlassian cloud instances?

This is still outstanding? Surprised more people aren't shouting for this.

As well as being a massive security risk, if you're trying to use separate admin and user accounts, this is impossible on one browser. I have a different browser logged in as admin because I can't log out of my account. 

The security implications are terrifying if you let your users have access to log on via public browsers

@Dave Meyer, in that case perhaps our issue needs to be its own ticket? We are running Data Center with Crowd and are unable to confidently log out of any Atlassian App that’s using SSO. The only way to really log out is to have users log out of their current app, then go log out of Crowd because it still keeps the session active.

63f827be31b8, just to be clear, this improvement request is for our SAML SSO offering in Atlassian Access for our cloud products. Crowd is only available for our server and Data Center deployment options.

For us, with SSO the only way to REALLY log out is to do it through crowd. Otherwise logging out of Jira, Confluence, or Bitbucket doesn't do anything and the session is kept active through crowd.

This is a serious security vulnerability and it’s rather embarrassing Atlassian hasn’t addressed this issue. Looks like we’ll have to turn off Single Sign On because you guys can figure out't single log OUT. ¯( ͡❛ ͜ʖ ͡❛)/¯

I wouldn't hold my breath sadly Lucas - it seems Atlassian do not see the severe security issues with this bug, and it has been made even more frustrating by the high cost of having SAML in place now.  We dumped it when it went to paid as there was no way our business was going to pay hundreds of dollars per year to open our entire confluence wiki and IP to be hacked/stolen just because one of our employees uses a public computer once and someone is able to immediately exploit this issue.

It is very disappointing how Atlassian have dealt with this issue.

I just tried this and it still works, i.e. I can login with any random e-mail address ending in the same domain. Are there any new developments in regards to this issue?

As of today, this is now a significantly larger issue and a security problem.

I logged out of our confluence instance (note we are using Azure as our IdP).  Once I logged out, anyone can put in an email address with the same domain as mine, and are automatically logged into my confluence instance as me - Even though I had completely logged out.  As a result, my account has now been compromised by anyone who noticed what email domain I was using.

This is entirely unacceptable - and on top of this, you are now charging us to use this service!?  I certainly won't be paying for a service that offers this kind of user security, and when all I want for my users is 2fa, this is deeply saddening.

Hi,

I was wondering if this issue is planned to be resolved by the time Identity Manager is released and becomes a paid add-on?  I feel that Identity Manager should not be charged for while this has not been resolved.  This is a failing of Identity Manager to not log out the SAML provider, and in addition, is a concerning security issue as another user can then obtain access to my Confluence (in my case) knowing only my email address, even though I have logged out.

Please advise on the current plans for this issue.