I have not followed JINI for years and when I stopped the RMI security model jsr had just been rejected so RMI still has no notion of a security context. What is the current JINI mechanism for establishing the security context?
1) Should work if JINI picks up the security context from the AccessControlContext Subject.
2) You can get access to the authenticated Subject, but since RMI has no notion of a security context and how to obtain/propagate it you are own your own to establish the JINI security context.
Will this work?:
1. Configure the EJB (let's call it SBean) which access remote server thru RMI with security checking.
2. Configure all other EJBs which access the SBean with a security-identity/run-as role-name
3. Setup a special security domain for the specified role
The main assumption is that when the methods of SBean are invoked, they are invoked in the thread with AccessControlContext which are tied to remote server authentication mechanism, and any RMI call within the SBean will use the same AccessControlContext.
The main assumption is incorrect. A secured component is not running within a Subject.doAs priviledged block. This is something you could add via a custom ejb interceptor, but it is not the mechanism for securing components used by jboss. Securing the ejb gives you the JAAS login for free, your custom ejb interceptor would then obtained the authenticated subject and dispatch the call from within a Subject.doAs priviledged block. Do you have reference to the current JINI security model?
You are right about my assumption and that's also my fear. So, I'll back to the hard-coded way.
As for JINI security model, I do not have one in particular. In our case, we just use standard JAAS as
- get a LoginContext
- get subject
- call Subject.doAs...(...)