Assume we have a regular bean A which makes a call on a Stateful Session B.
Bean A configures a RunAsIdentity of (principal=anil,roles=user). Now when A makes a call on B, the following things happen:

1) The current subject in A is pushed on the subject context.
2) The StatefulSessionInstanceInterceptor pushes a null subject on to the subject context as per:

/* The security context must be established before the cache
 lookup because the activation of a session should have the caller's
 security context as ejbActivate is allowed to call other secured
 resources. Since the pm makes the ejbActivate call, we need to
 set the caller's security context. The only reason this shows up for
 stateful session is that we moved the SecurityInterceptor to after
 the instance interceptor to allow security exceptions to result in
 invalidation of the session. This may be too literal an interpretation
 of the ejb spec requirement that runtime exceptions should invalidate the session.
 */
 SecurityActions.pushSubjectContext(mi.getPrincipal(), mi.getCredential(), null);

3) The SecurityInterceptor fronting B finds that there is a RunAsIdentity configured. Hence does not do a authentication check, but duplicates the subject context on the SA stack. Now because of step 2 (a null subject gets duplicated).


This use case is only for Stateful session beans. I think in step 2, there is a need to check for availability of RunAsIdentity, failing which a null subject can be pushed in.

Thoughts?