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

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#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...