0 Replies Latest reply on Oct 23, 2006 3:03 PM by Anil Saldanha

    Stateful Session Beans and RunAsIdentity mismatch

    Anil Saldanha Master

      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.