Sensible approach 1, don't use xdoclet if you can't get it to generate seperate security permissions based on the interface type. It should as this is allowed i n the ejb-jar.xml method-permission.
A caller from TRUSTED_APP into CORE will have their security context propagated, so if the principal and credentials are the same between the two domains the call will work.
You can also deploy the CORE app with a custom ejb container configuration that removes or modifies the SecurityInterceptor to allow access to local interfaces.
Well, it turns out we can't rely on TRUSTED_APP being in the same container, so the "local interfaces wide open" approach won't work.
What we need is a way for TRUSTED_APP to be authenticated in a headless way (say, a kerberos keytab), and that information to be used to access stuff in another ear (potentially on a separate machine).
But the only thing that seems to be propagated from one security realm to another is the callback handler. Sadly, authenticating a keytab doesn't *have* a callback handler. In the target (CORE) login modules, it doesn't use the caller subject (it's blank), and doesn't use subjects, principals, or credentials in SecurityAssociation, even if a remote login module (for TRUSTED_APP) plays the same game as ClientLoginModule in explicitly setting these. It seems that they get dropped on the floor once the initial auth of TRUSTED_APP is done.
The only thing that seems to work is if TRUSTED_APP authenticates itself against a keytab (or other shared secret), then in a bean in TRUSTED_APP I explicitly set SecurityAssociation.setPrincipal(), SecurityAssociation.setCredential() and *then* hit the CORE bean. I guess setting SecurityAssociation.* fakes out the callback handler to believe that this is the callback.
That works, but it seems like the wrong way to go. Surely there's a standard, official, best-practice way for a given ejb app to authenticate itself to another ejb app in a headless, keytab-ish way, right?
The jboss book (I'm a good person and paid for the docs) says in its description of ClientLoginModule that SecurityAssociation is subject to change without notice, so we can't rely on it, and ClientLoginModule is the only official way to . I have a fat client that can remotely authenticate to CORE using a "shared secret" principal and ClientLoginModule, but that evidently doesn't work when the "client" using CORE is itself ejb app.
The jboss book states: "Both stand-alone client applications
and server environments, acting as JBoss EJB clients where the security environment has not been configured to use JBossSX transparently, need to use the ClientLoginModule." Could someone expand on that a bit? It only seems to use JBossSX transparently when the username and password are created by something that the callback handler can recognize and use (like a jsp or simple auth trap set up in web.xml). How do I get headless authentication, keytab-based or otherwise, to work between ejb apps?
thanks for any help!
You configure the apps to use the same security domain and have the security domain include login modules that know how to communicate/validate the keytab auth mechanism.