Yes... and no.
For authentication only you can use a SSL connector configured appropriately.
Eg with clientAuth="true" and the necessary trust store.
But with a nice JAAS & role based authentication & authorization you are going to have to go deeper.
see the wiki:
(BaseCertLoginModule recently replaced AbstractCertLoginModule, along with come code restructuring )
In my experience CertRolesLoginModule only works with the latest version of JBoss (infact I had to use jbosssx from CVS with the DR4 server; DR4 Jbosssx tries to use a null log object during initialisation)
The classes are in a 3.x release as well (can't remember the number, but recent, obviously)
I really appreciate the response but what I am looking for is a way to configure two way identity authentication when, for example, two EJBs on seperate JBoss severs are communicating. Like you stated, this is accomplished for web apps by setting clientAuth="true" in a connector configuration. But how is this set up for EJB to EJB communication (is it even possible)?
The documentaion does describes a way to configure ssl with one way identity authentication i.e. the client authenticates the certificate that the server presents (Configuration is done by configuring a security domain and invoker).
Sorry, yes clientAuth was web app specific; but actually it is not necessary if the login configuration method is used.
Although the wiki material did relate to web apps the security domain and login settings sould be completely portable; the main difference is that instead of configuring a tomcat connector you will have to config the RMI invocation machinery, and instead of configuring the webapp you'll configure the EJBs.
The pay docs detail a "one way" auth secnario which sets out most of the structure for SSL RMI, and as a first try I would just try porting the login configuration to the RMI example. A JAASSecurityDomain encapsulates both a key store and a trust store so if the RMIInvoker picks them up correctly, two way auth should be feasable (if not pretty much impossible).
with any luck you have a nice SSL mutual auth happening:
SSL handshake, using sockets [hopefully] set up by the relevent invoker services with keys & trust certificates:
caller ("client") socket configured from security domain with its key & trusting the callee
Callee ("server") socket configured from security domain with its key & trusting the caller
and, if you indulge in authorisation/login: login modules will be invoked on the server (hopefully picking up client cert from connection)
(I'm gambling here as I'm much more a WS expert than RMI, but the low level SSL sould be the same, it is just a case of delivering the keys & truststore to the sockets; good luck with it)