Passing subject/roles from one realm to another?

[mharm]

Hi.

Apologies if this is a dumb one, but I'm stumped.

I've got one ear deployed, that has some core services. Let's call it CORE.ear. It needs to be accessible via remote fat clients, and hence has to be locked down reasonably well. We have other webapps in the same container; let's call one TRUSTED_APP.ear. Now, trusted_app has to be accessible to unauthenticated browsers, and it has to be able to invoke beans in CORE.ear. So what I'm trying to do is set up TRUSTED_APP to use one security realm with an "unauthenticatedIdentity" set, with sensible roles, and then it is allowed to call stuff in CORE without a password being needed.

One option is to set up CORE so it's local interfaces are wide open, but it's remote ones are locked down. But that's a drag; xdoclet doesn't seem to like the idea of separate security roles for remote and local interfaces.

Is there a way that I can force a user/role in TRUSTED_APP (say, by loading a local keytab or other shared secret), that is then used when it calls things in CORE? I find that when TRUSTED_APP tries to invoke anything in CORE the login modules don't use anything from the environment of TRUSTED_APP... no jaas shared state, no subject, nothing.

Is there a sensible way to do this that I'm missing?

Thanks for any help!

[starksm64]

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.

[mharm]

Hi again.

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!

-mike

[starksm64]

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.