[jboss-jira] [JBoss JIRA] (WFLY-1319) Thread security context stuck with invalid credentials after authentication failure

[Martin Maierhofer (JIRA)]

Martin Maierhofer created WFLY-1319:
---------------------------------------

             Summary: Thread security context stuck with invalid credentials after authentication failure
                 Key: WFLY-1319
                 URL: https://issues.jboss.org/browse/WFLY-1319
             Project: WildFly
          Issue Type: Bug
          Components: Security
    Affects Versions: 8.0.0.Alpha1
         Environment: JBoss AS 7.1.1-FINAL on Win2K3 Server and Linux, 64-bit JRE 7
            Reporter: Martin Maierhofer
            Assignee: Darran Lofthouse


We came across this in an environment of ours that uses a custom login module, but if I read the code correctly, this is a more general problem: if an authentication failure occurs while handling an EJB method, then the security context for the thread is not reset correctly, and subsequent uses of the thread for anonymous methods (e.g. timers) use the incorrect credentials.

I suspect the problem lies in SimpleSecurityManager's push() implementation, which is invoked from the SecurityContextInterceptor as follows:
{code}
    @Override
    public Object processInvocation(final InterceptorContext context) throws Exception {
        // TODO - special cases need to be handled where SecurityContext not established or minimal unauthenticated principal context instead.
        doPrivileged(pushAction);
        try {
            return context.proceed();
        } finally {
            doPrivileged(popAction);
        }
    }
{code}

If the pushAction throws an exception, then the popAction is never invoked. SimpleSecurityManager's push action starts off with
{code}
public void push(final String securityDomain) {
        // TODO - Handle a null securityDomain here? Yes I think so.
        final SecurityContext previous = SecurityContextAssociation.getSecurityContext();
        contexts.push(previous);
        SecurityContext current = establishSecurityContext(securityDomain);
{code}

If an exception is subsequently raised, then the thread's security context is never reset (and previous is never popped off the "contexts" stack either).

If the same thread is subsequently used in a timer invocation that is supposed to run without a principal, the old security context is still active in the thread, and will be used incorrectly. (In our case leading to the same authentication exception over and over.)

I was able to successfully work around this issue by catching exceptions in push() and invoking pop() in the catch block, before rethrowing the exception.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira