Tomcat 4.0.1 / JBoss 2.4.3 / Distributed mode

[fhubin]

Hello all,

I'm currently running Tomcat 4.0.1 successfully. User validation is done against an OpenLDAP server. Everything is fine.

Beside that, I'm running JBoss 2.4.3 which is also successfully validating user and retrieving role information from the same OpenLDAP server. Tomcat and JBoss are running in separate VM and might even run on separate machine in the future.

I'm now trying to propagate the user information I have in my JSP pages to JBoss. I was planning to use the plain old Context.SECURITY_PRINCIPAL and Context.SECURITY_CREDENTIALS fields in the InitialContxt, but I've noticed it is not supported in JBoss (or perhaps not in the spec anymore). So I've tried to figured out how to configure JAAS and all the stuff.

Currently, I'm able to authenticate a user against JBoss from a plain java app with JAAS. When I try to move the code to my JSP, it failed: the user is always null. I started to investigate and understood by reading the code that is certainly not the right way.

Here are my questions:

- Is it possible to propagate user info from Tomcat 4.0.1 to JBoss 2.4.3?
- If yes, what is the overall architecture (I'll deal will the details) to do it?
- Is there a way to enable Context.SECURITY_PRINCIPAL and Context.SECURITY_CREDENTIALS? (If no, why?)

Thanks in advance.

[luke_t]

> Is it possible to propagate user info from Tomcat 4.0.1 to JBoss 2.4.3?

It should be, but I haven't tried it with Tomcat 4, so the following is a general guide and may be completely wrong or omit crucial details :)

> If yes, what is the overall architecture (I'll deal will the details) to do it?

It should be pretty much the same as for Tomcat 3.2 or any other standalone web container:

You need:

An additional interceptor (or "Valve") in the invocation stack which will set up the security association on each call so that info will be propagated with calls to JBoss. Obviously the security information that Tomcat 4 is using must be compatible with what the security domain you are using in JBoss (it should be in your case).

You need the standard JBoss client jar files and any client files for your app.

You need to set up JNDI in Tomcat to point to JBoss.


> Is there a way to enable Context.SECURITY_PRINCIPAL and Context.SECURITY_CREDENTIALS? (If no, why?)

Dunno. Isn't this intended for accessing a secured naming service?

[fhubin]

Thanks Luke for the info. I finally found what was not working properly. Actually, the ClientLoginModule I was using was causing the problem. I extracted it from its jar and replace it with a commented version. By reading the log, I understood he was behaving correctly. So, I remembered a class loader problem I've got with WebLogic.

Actually at the very begining, I put all my JBoss + JAAS files in the war file. Doing that, I've got a security exception telling me the LoginModule could not be instantiated. I spent a lot of time trying to modify security policy, but with no success (other stuff broke).

I moved some files (that was the mistake) to the server/lib of tomcat and load them 'globally'. But some other files were still loaded by the application. Actually, they were so seeing each other, but they should have since ClientLoginModule is using a singleton class to store Principal/Credential information. Now, I've put all JAAS/JBOOS stuff globally, so I avoid the security problem and every class see each other.

I would like to solve the security problem instead because it is more elegant, but at least, I can progress.

Thanks.

[jpeach]

Luke,

I saw your message about creating a Valve implementation that sets the security context for JBoss and I'm confused about how the Valve should go about setting the context.

When I want to use a standalone client, I associate the user via the creation of a LoginContext (using JAAS). This is straightforward, but I'm not sure if the approach translates for the Valve implementation.

This is to say, should the valve implementation use the JAAS approach with a client side login module to pass the username and credentials, and if so is it necessary to login and logout in the Valve's invoke method.

Or...

Should I take the approach used by the org.jboss.web.catalina.JBossSecurityManagerRealm class and lookup the JBoss SecurityManager from java:comp/env/security? My intuition is that this wouldn't work since it relies on the namespace to be set up by the org.jboss.web.catalina.EmbeddedCatalinaServiceSX.

Any steering is greatly appreciated.

-Joel

[luke_t]

fhubin wrote:
>Actually at the very begining, I put all my JBoss + JAAS
> files in the war file. Doing that, I've got a security
>exception telling me the LoginModule could not be
>instantiated. I spent a lot of time trying to modify
>security policy, but with no success (other stuff broke).

I think this is sympomatic of a bug in JAAS which has been fixed in JDK 1.4.

JBoss has a "ProxyLoginModule" which allows you to workaround this problem. See the docs for that if you want to load custom login modules from within your app.

Luke.

[luke_t]

jpeach wrote:

> I saw your message about creating a Valve implementation
> that sets the security context for JBoss and I'm confused
> about how the Valve should go about setting the context.

It would probably follow the same format as the JBoss realm interceptor which is used with Tomcat. I'll have a go at doing it myself tonight and let you know.

Luke.

[yeroc]

Luke,

Did you ever investigate this further? We are running into a similar situation where we want to run our servlets/jsps on Tomcat 4 connecting & authenticating back to a remote JBoss container.

I've searched a number of threads where people are trying to do similar things but there seems to be no consensus on how best to do this.

Any thoughts?

[mattvincent]

Did you find an answer to this problem?