Plugging in Authentication Providers on EJB3 Interceptors

[anil.saldhana]

The EJB3 interceptors have the InvocationContext as follows:

public interface javax.ejb.InvocationContext {
 public Object getBean();
 public Method getMethod();
 public Object[] getParameters();
 public void setParameters(Object[]);
 public Context getEJBContext();
 public java.util.Map getContextData();

 public Object proceed() throws Exception;
}

Does the InvocationContext have sufficient security information to provide external authentication providers? This has to take into consideration various transports like IIOP that propogate security via the ORBs.

What are your thoughts on this?

[bill.burke]

interceptors have access to the EJB's EJBContext. I don't know if that is enough or not...You tell me.

[anil.saldhana]

I think the EJB3 InvocationContext (which has EJBContext internally) will suffice for the external authentication providers.

I am not clear on CSIv2 and RMI/IIOP communication for EJBs. If that brings any new issue to the equation.

[starksm64]

I don't see why the security context cannot be provided via an entry in the getContextData map. The test is to integrate the current iiop invoker to validate this. Access to transport level security contexts like ssl certs and the csiv2 need to be validated.

[anil.saldhana]

Yes, the ContextData that exists in the InvocationContext will suffice.

But I am not 100% clear on what the implications are while using CSIv2, where the ORB is the security service. Guess will have to ask the CORBA guys.

As you suggested a testcase that validates this against the IIOP Invoker, is the right start.

[anil.saldhana]

Doubt: When CSIv2 is involved, does the ORB do the authentication before transferring the ejb invocation to the EJB3 container or it just acts as a conduit for the invocation?

Scott Says:

Have to dig into the interaction between the
org.jboss.iiop.csiv2.SASClientIdentityInterceptor/SASTargetInterceptor
and org.jboss.iiop.jacorb.SSLServerSocketFactory/SSLSocketFactory

[reverbel]

Doubt: When CSIv2 is involved, does the ORB do the authentication before transferring the ejb invocation to the EJB3 container or it just acts as a conduit for the invocation?

IIOP/CSIv2 support for EJB3 is not in place yet, so I'll comment on the EJB 2.x case.

The ORB acts just as a conduit. At the client side there is a CORBA portable interceptor, which takes security info (username and credentials) from the SecurityAssociation and stuffs the info into a CSIv2 context that is sent out with outgoing IIOP requests. At the server side there is another CORBA portable interceptor, which extracts the security info from the CSIv2 context. The EJB CORBA servants (EjbHomeCorbaServant and EjbObjectCorbaServant) get the security info from the server-side CORBA PI and stuff it into a JBoss Invocation, which is then passed to the EJB container (through the MBean server). Authentication is performed by a JBoss security interceptor, just like in non-IIOP cases.

[starksm64]

So after talking about this at J1 it seems the only universal ejb profile would be based on corba portable interceptors. We should have a jboss specific profile as a clean integration api as well.