[jboss-dev-forums] [Design of Security on JBoss] - Stateful Session Beans and RunAsIdentity mismatch

[anil.saldhana@jboss.com]

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?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980146#3980146

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980146