Uploaded image for project: 'Identity'
  1. Identity
  2. ID-127

Logging out of OnDemand invalidates all sessions for current user

    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      It would be good to be able to log out of one session, but still maintain all others (other browsers/locations) for one user.

            [ID-127] Logging out of OnDemand invalidates all sessions for current user

            Adarsh added a comment -

            With all users upgraded to Atlassian account, new logout behaviour ensures you only log out of your current session. Only in case of password reset, users will be logged out from all active sessions.

            Adarsh added a comment - With all users upgraded to Atlassian account, new logout behaviour ensures you only log out of your current session. Only in case of password reset, users will be logged out from all active sessions.

            There must be some misunderstanding of the issue I've reported. Otherwise, I can't imagine anyone would take this stance.
            The root of the issue is that if a session is initiated by any mechanism or via any client that session WILL be closed at the time any other session is closed by any mechanism or client that is initiated by the same user (same account).

            That is counter intuitive behavior and is inconsistent with almost all other session management schemes in place by other "systems", vendors, providers, etc. I believe for good reason.

            If you simply think of this in an OOP paradigm you can see that this is very awkward. Forgive my pseudo-code You are suggesting that given sessions.sessionA and sessions.sessionB, sessions.sessionA.endSession() results in sessions.sessionB.endSession(). Something like sessionManager.invalidateAllUsersSessions(sessions.sessionA.user);

            Or you are stating that sessions.sessionA == sessions.sessionB is true. Such that sessions.sessionA.endSession() == sessions.sessionB.endSession().

            Is there another explanation? Why is this in any way necessary? As a non default feature of session management you may wish to provide that as an option. As default behavior for all sessions it is disruptive to normal operations.

            Now, to the Comment from Michael Knight about handling stolen laptops and also using privacy mode on the client. Wonky!

            In the case of a stolen "client", you have introduced a security issue with this "feature". If the thief were to change my profile contact email and password and then logout of their session then I would be logged out and have no knowledge of the new password or any ability to reset it (email has been changed in the profile).

            Nice Security! Its not just session hijacking now, its account hijacking.

            Further, that "privacy mode" should in anyway be a part of session/security management mechanism is scary! You are suggesting that we should rely on the client to adequately "forget" the session. That is bad practice from a security perspective as well as from a server side resource utilization perspective. You would intentionally leave a session open that a "hijacker" could still access even though the original user (session initiator) believes the session is closed. In terms of resources, the server will keep those sessions (and all the related state) available long past the usefulness of the session. Expanded that usage out over multiple users and multiple sessions this would result in a highly inefficient use of resources.

            Please escalate this to a high priority BUG and fix as soon as possible.

            Scott L'Hommedieu added a comment - There must be some misunderstanding of the issue I've reported. Otherwise, I can't imagine anyone would take this stance. The root of the issue is that if a session is initiated by any mechanism or via any client that session WILL be closed at the time any other session is closed by any mechanism or client that is initiated by the same user (same account). That is counter intuitive behavior and is inconsistent with almost all other session management schemes in place by other "systems", vendors, providers, etc. I believe for good reason. If you simply think of this in an OOP paradigm you can see that this is very awkward. Forgive my pseudo-code You are suggesting that given sessions.sessionA and sessions.sessionB, sessions.sessionA.endSession() results in sessions.sessionB.endSession(). Something like sessionManager.invalidateAllUsersSessions(sessions.sessionA.user); Or you are stating that sessions.sessionA == sessions.sessionB is true. Such that sessions.sessionA.endSession() == sessions.sessionB.endSession(). Is there another explanation? Why is this in any way necessary? As a non default feature of session management you may wish to provide that as an option. As default behavior for all sessions it is disruptive to normal operations. Now, to the Comment from Michael Knight about handling stolen laptops and also using privacy mode on the client. Wonky! In the case of a stolen "client", you have introduced a security issue with this "feature". If the thief were to change my profile contact email and password and then logout of their session then I would be logged out and have no knowledge of the new password or any ability to reset it (email has been changed in the profile). Nice Security! Its not just session hijacking now, its account hijacking. Further, that "privacy mode" should in anyway be a part of session/security management mechanism is scary! You are suggesting that we should rely on the client to adequately "forget" the session. That is bad practice from a security perspective as well as from a server side resource utilization perspective. You would intentionally leave a session open that a "hijacker" could still access even though the original user (session initiator) believes the session is closed. In terms of resources, the server will keep those sessions (and all the related state) available long past the usefulness of the session. Expanded that usage out over multiple users and multiple sessions this would result in a highly inefficient use of resources. Please escalate this to a high priority BUG and fix as soon as possible.

            If your account has been compromised (e.g. a stolen laptop), you can go to another computer, login and logout again to ensure that the stolen laptop cannot be used to access your OnDemand instance.

            If you just want to temporarily login to an OnDemand instance (e.g. on a borrowed computer) without invalidating your other sessions, use the browser's privacy mode. Instead of logging out, just end the privacy mode.

            Michael Knight added a comment - If your account has been compromised (e.g. a stolen laptop), you can go to another computer, login and logout again to ensure that the stolen laptop cannot be used to access your OnDemand instance. If you just want to temporarily login to an OnDemand instance (e.g. on a borrowed computer) without invalidating your other sessions, use the browser's privacy mode . Instead of logging out, just end the privacy mode.

            This is more of a bug than it is an enhancement.
            What reason exists to log a user out of all sessions instead of just the one that is associated with the "logout action"?

            Scott L'Hommedieu added a comment - This is more of a bug than it is an enhancement. What reason exists to log a user out of all sessions instead of just the one that is associated with the "logout action"?

            I believe this is an Indra issue, so I've moved it to the OnDemand project.

            Eric Dalgliesh added a comment - I believe this is an Indra issue, so I've moved it to the OnDemand project.

              Unassigned Unassigned
              dnicholson David Nicholson (Inactive)
              Votes:
              4 Vote for this issue
              Watchers:
              9 Start watching this issue

                Created:
                Updated:
                Resolved: