problem with authentication domains

[manos]

Hello!

I have deployed 2 ears on JBoss 3.2.1 on a Linux machine. Each has several EJBs and two web apps, the administration web app and the client WEB app. The EJBs are of the same type but access different databases, and the two EARs are configured to use different classloaders (). The two administration apps are using a security domain to protect access from unauthenticated users, while the client apps provide unrestricted access. To accomplish this the jboss-web.xml files for the administration apps contain:

<security-domain>java:/jaas/app_x</security-domain>
guest

And the appropriate security-constraint elements are defined in web.xml. The jboss-web.xml files for the client WEB apps contain the same, but no security-constraint elements are defined in web.xml.

The login-config.xml defines the app_x application policies to use the DatabaseServerLoginModule.

Authentication and authorization for the admin apps works fine. However the following problem occurs in the client WEB apps:

(In separate browsers)
BROWSER 1: See app_1_client - OK
BROWSER 2: See app_2_client - OK
BROWSER 3: Login to app_1_admin - OK (username admin_1)
BROWSER 4: Login to app_2_admin - OK (username admin_2)
BROWSER 1: REFRESH throws exception:

javax.ejb.EJBException: checkSecurityAssociation; CausedByException is:
Authentication exception, principal=admin_1

App_1_admin is still functional. If I login again to app_2_admin, app_2_client works and app_1_client stops with a similar exception.

It seems to me that the authentication domains get mixed up for a reason I do not understand. Is there anything to do about it? If more details are required for the configuration, I will gladly provide.

Thank you in advance,
Nikos

[manos]

Well the only solution we have found after two days ... was to create a dummy principal (invisible to anyone) with full privileges in the client side who does what JBoss guest was supposed to do....

[starksm64]

Create a bug report on sourceforge with example ears which demonstrate this behavior please.

http://sourceforge.net/tracker/?group_id=22866&atid=376685

[niox]

Hello,

It seems this problem was related to the fact that Tomcat does not delete credentials(?) from a thread that served a request. Whenever a request required authentication things worked normally. If however a request did not require authentication, like in the case of a client site, the credentials from the last served request remained and confused the system.

This problem seems to have been solved in JBoss 3.2.3 when we tried it.

There are several posts in the Security & JAAS forum that describe this problem.

Nikos

[starksm64]

There has been a patch for the credential leak for jboss-3.2.1_tomcat-4.1.24.zip since 2003-05-04. patch description:
http://sourceforge.net/project/shownotes.php?release_id=157183

patch jar:
http://prdownloads.sourceforge.net/jboss/sa-valve-patch.jar?download

[manos]

Sorry about that, just a test reply,.... &#945;&#960;&#940;&#957;&#964;&#951;&#963;&#951;

[manos]

Sorry about that, just a test reply,.... απάντηση