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:
If the pushAction throws an exception, then the popAction is never invoked. SimpleSecurityManager's push action starts off with
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.