Bug 536032 (RHQ-426)

The underlying cause of RHQ-528 is the same thing like here.
Subject has a sessionId. This gets set up upon login() and invalidated on logout().
The call to the business layer will be validated by the RequiredPermissionInterceptor in places where we pass in the Subject as first parameter to a business operation. This one checks if the sessionId of the subject is the same as the current one (iirc) and throws errors when this is not the case - like after the user has logged in a second time.

work around for now is to only have a user login once at a time.  will push to 2.0 for further consideration.

from lukas - he did some research and here's what he found:

---

Problem
-------

At heart of the issue we're experiencing is, I believe,
the ...enterprise.server.auth.SessionManager class that implements custom
session management for RHQ.

The main question is: why do we need it? What is the distinction between RHQ
session and an http session? Is it to support WSes and remote EJB calls?

Are there any other problems with the concurrent logins apart from the
apparent "user1 logging out logs out user2 as well" scenario?

Code analysis
-------------

The offending method that causes our problems is
SessionManager.getSessionIdFromUsername(String). This method is unfortunately
called from a number of places (excluding tests):

SubjectManagerBean
    -- boolean isLoggedIn(String username)
        this method is never called in app logic - only in tests.
        This is remote EJB + web method. The implementation could be changed
        to use a new SessionManager's method that would loop over the existing
        sessions. What is the usage of this method anyway?
        
    -- Subject login(String username, String password)
        in here we actually assign an existing session id to the newly logged
        in user if a session for that username already exists. This is
        a remote EJB and web method. This method's contract is stating that
        the user is associated with an existing session if such session exists
        for given username. This is in contrast with the requirement for
        allowing multiple logins under the same user name. Why do we need this
        behaviour?
        We return the Subject instance with the session id initialized so the
        remote endpoints know their session ids. Why do we then need the
        login method to support the "reattaching" behaviour?

        -- EditPasswordAction.execute()
            relogin
            
        -- RegisterAction.execute()
            login of the newly registered user

        -- AuthenticateUserAction.execute()
            logs in the user
        
    -- loginUnauthenticated(String username, boolean reattach)
        if reattach==true and a user already exists - the newly logged in user
        shares a session with the previously logged in user.
        This is only a EJB local method.
        This is problematic method, because it only requires a username and
        should be possible to "reattach" the user to an existing session -
        i.e. at most one session is allowed to exist at any given time. If we
        passed the whole Subject to this method, the semantics of the method
        could be the same (i.e. log me in as this user even if i don't know
        the password) but we could implement the reattach scenario properly by
        simply checking that given user's session is still active and "touch"
        it or creating a new session for the subject if no valid session is
        present.
        
        -- DiscoveryBean.addResource()
            loginUnauthenticated(username, true)
            the "creator" of the resource is logged in temporarily in this
            method - no problem as the "creator" is a Subject instance in the
            method body.

        -- OperationJob.getUserWithSession(Subject user, boolean reattach)
            The purpose of this method is to get a user with a valid
            session (obviously). This is done using the unauthenticated login.
            If we reimplemented the loginUnauthenticated() method as described
            above, we most probably wouldn't change the expected behaviour
            of this method.

            -- GroupOperationJob.execute()
                getUserWithSession(user, false)

            -- ResourceOperationJob.execute()
                getUserWithSession(user, false)

            -- ResourceOperationJob.invokeOperationOnResource()
                getUserWithSession(user, true)

Conclusion
----------

From the code analysis we can see that there is just a single problem with the
implementation and that is the possibility to reattach a Subject instance to a
session id that already existed for another Subject with the same username.
All analyzed code paths can be easily changed to avoid the need for such
behaviour and the only problem is that of the compatibility of "3rd party"
software relying on this behaviour when invoked remotely either using EJB or
WS.

This bug was previously known as http://jira.rhq-project.org/browse/RHQ-426

Changing such that each login gets its own session and will not stomp on a user already logged in as that user.

The ability to "reattach" to an existing session for a user will go away because there will no longer be a single session associated with a username.

primary work:
commit 07471e1f014eed497b43cafeddaffa1cabc873c1
addendum fix:
commit fa3cb7852df40c0bfbb49fa6f40ae4d6cb8f82f6

Historically a username shared an RHQ session (not the HTTP session, the
underlying RHQ session, the sessionId on the Subject).  This had some mild
upside when it was convenient to share a session but has serious downside
as the logout of one gui session or cli job would invalidate the session
for any other gui or cli session using the same username.

So, this changes the behavior to make things behave more in line with what
folks hopefully expect. Each login gets its own RHQ session. Logout or
session timeout will not affect other logins.

One exception may be multiple sessions in the same browser, as there could
be conflict in cookie handling. This is not new and not a use case we are
planning to address.

In addition, I replaced some SubjectManagerLocal methods and supporting
queries with equivalent Criteria calls.

This seems stable.

Test Notes:

Log in as the same user from various places, Browser1, Browser2, CLI, etc.  When logging out one session the other sessions should remain unaffected.

Also, test other session issues from the browser.  Ensure F5 refreshes work as expected.  Also, session expiration (you'll need to wait an hour for the session to die automatically.  Then, on subsequent login of the same user you should start where you left off).

verified by logging into RHQ from 2 different browsers on 2 different machines.  logged in, logged out, navigated around.  the browser sessions did not affect one another.

Bulk closing of issues that were VERIFIED, had no target release and where the status changed more than a year ago.