> 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:
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?
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.
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.
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.
>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.
> 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.
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.
Did you find an answer to this problem?