JBossDeveloper

"m.oconnor" wrote:
I'm experiencing exactly the same problem with the 403s, as did a colleague of mine when he tried this on another unrelated project.

I'm using JBoss3.0.4-Tomcat4.1.12 and added the <valve> to tomcat41-service.xml, pointing to the patched SingleSignOnValve in a jar deployed in the /server/default/lib.
Any help on this would obviously be appreciated!

regards,
Mike O'Connor
Finalist IT Group, Amsterdam, The Netherlands.

"m.oconnor" wrote:
I'm experiencing exactly the same problem with the 403s, as did a colleague of mine when he tried this on another unrelated project.

I'm using JBoss3.0.4-Tomcat4.1.12 and added the <valve> to tomcat41-service.xml, pointing to the patched SingleSignOnValve in a jar deployed in the /server/default/lib.
Any help on this would obviously be appreciated!

regards,
Mike O'Connor
Finalist IT Group, Amsterdam, The Netherlands.

"CobraFlow" wrote:
...back again...

I'm now using jboss-3.0.6_tomcat-4.1.18 and still no joy...

Everything seems to do what it is supposed to do...I have the debug turned up to 9 on the SingleSignOn valve. Here is the output :-

[Server] JBoss (MX MicroKernel) [3.0.6 (CVSTag=JBoss_3_0_6 Date=200301260037)] Started in 0m:19s:298ms
[Engine] SingleSignOn[localhost]: Process request for '/WorkqueueManager'
[Engine] SingleSignOn[localhost]: Checking for SSO cookie
[Engine] SingleSignOn[localhost]: SSO cookie is not present
[Engine] SingleSignOn[localhost]: Process request for '/WorkqueueManager/'
[Engine] SingleSignOn[localhost]: Checking for SSO cookie
[Engine] SingleSignOn[localhost]: SSO cookie is not present
[Engine] SingleSignOn[localhost]: Process request for '/WorkqueueManager/workqueuemanager/jsp/queueList.jsp'
[Engine] SingleSignOn[localhost]: Checking for SSO cookie
[Engine] SingleSignOn[localhost]: SSO cookie is not present
[JaasSecurityManagerService] Created securityMgr=org.jboss.security.plugins.JaasSecurityManager@cb2185
[JaasSecurityManagerService] setCachePolicy, c=org.jboss.util.TimedCachePolicy@127ff0d
[JaasSecurityManagerService] Added CobraFlow, org.jboss.security.plugins.SecurityDomainContext@d9cbcb to map
[Engine] SingleSignOn[localhost]: Process request for '/WorkqueueManager/workqueuemanager/jsp/queueList.jsp'
[Engine] SingleSignOn[localhost]: Checking for SSO cookie
[Engine] SingleSignOn[localhost]: SSO cookie is not present
[Engine] SingleSignOn[localhost]: Registering sso id 'CE36375630FF56E80470B9163BAF57B4' for user 'Lewis' with auth type 'BASIC'
[STDOUT] Checking session for WorkflowUser
[STDOUT] Adding WorkflowUser to session
[Engine] SingleSignOn[localhost]: Process request for '/WorkqueueManager/workqueuemanager/css/stylesheet.css'
[Engine] SingleSignOn[localhost]: Checking for SSO cookie
[Engine] SingleSignOn[localhost]: Checking for cached principal for CE36375630FF56E80470B9163BAF57B4
[Engine] SingleSignOn[localhost]: Found cached principal 'Lewis' with auth type 'BASIC'
[Engine] SingleSignOn[localhost]: Process request for '/WorkqueueManager/workqueuemanager/images/transparent.gif'
[Engine] SingleSignOn[localhost]: Checking for SSO cookie
[Engine] SingleSignOn[localhost]: Checking for cached principal for CE36375630FF56E80470B9163BAF57B4
[Engine] SingleSignOn[localhost]: Found cached principal 'Lewis' with auth type 'BASIC'
[Engine] SingleSignOn[localhost]: Process request for '/WorkqueueManager/workqueuemanager/images/TimesheetsUnlimited_1x1.jpg'
[Engine] SingleSignOn[localhost]: Checking for SSO cookie
[Engine] SingleSignOn[localhost]: Checking for cached principal for CE36375630FF56E80470B9163BAF57B4
[Engine] SingleSignOn[localhost]: Found cached principal 'Lewis' with auth type 'BASIC'
[Engine] SingleSignOn[localhost]: Process request for '/WorkqueueManager/workqueuemanager/images/TimesheetsUnlimited_2x1.jpg'
[Engine] SingleSignOn[localhost]: Checking for SSO cookie
[Engine] SingleSignOn[localhost]: Checking for cached principal for CE36375630FF56E80470B9163BAF57B4
[Engine] SingleSignOn[localhost]: Found cached principal 'Lewis' with auth type 'BASIC'
[Engine] SingleSignOn[localhost]: Process request for '/WorkqueueManager/workqueuemanager/images/topcorner.gif'
[Engine] SingleSignOn[localhost]: Checking for SSO cookie
[Engine] SingleSignOn[localhost]: Checking for cached principal for CE36375630FF56E80470B9163BAF57B4
[Engine] SingleSignOn[localhost]: Found cached principal 'Lewis' with auth type 'BASIC'
[Engine] SingleSignOn[localhost]: Process request for '/WorkqueueManager/workqueuemanager/images/openfolder.gif'
[Engine] SingleSignOn[localhost]: Checking for SSO cookie
[Engine] SingleSignOn[localhost]: Checking for cached principal for CE36375630FF56E80470B9163BAF57B4
[Engine] SingleSignOn[localhost]: Found cached principal 'Lewis' with auth type 'BASIC'
[Engine] SingleSignOn[localhost]: Process request for '/WorkqueueManager/workqueuemanager/images/closedfolder.gif'
[Engine] SingleSignOn[localhost]: Checking for SSO cookie
[Engine] SingleSignOn[localhost]: Checking for cached principal for CE36375630FF56E80470B9163BAF57B4
[Engine] SingleSignOn[localhost]: Found cached principal 'Lewis' with auth type 'BASIC'
[Engine] SingleSignOn[localhost]: Process request for '/Timesheet/action/acquire.do'
[Engine] SingleSignOn[localhost]: Checking for SSO cookie
[Engine] SingleSignOn[localhost]: Checking for cached principal for CE36375630FF56E80470B9163BAF57B4
[Engine] SingleSignOn[localhost]: Found cached principal 'Lewis' with auth type 'BASIC'

...now I get the dreaded 403!!!

I have tried Basic and Form authentication with the same result...

Any ideas...?


Lewis

"rlynn" wrote:
Anybody know how to get this working under Jetty?

"mklemm" wrote:
Yes, I have the same problem.
When turned debugging of the SingleSignOn Valve and the HttpProcessor to full, it looks like everything is OK with SSO. The last messages before the "403" is sent to the client state that SSO has successfully assigned a principal and a JSESSIONID to the received cookie. Still I get many "403" errors that don't seem to be constantly reproducible.
What else can go wrong here? Any Ideas?

Regards, Mirko

"SNy23" wrote:
Hi all.

> Anybody know how to get this working under Jetty?

Take a look at http://groups.yahoo.com/group/jetty-discuss/message/6244

I sent that message a while back to the jetty folks and, admittedly, forgot to post it here, sorry for that.
If you are interested, download the mentioned zip file and give it a try. Please note, however, that this is a quick and dirty hack rather than a solution. I also did some minor modifications yesterday that I am just about to test. I'll keep you posted.

BTW, comments or constructive criticism would be very welcome.

Marko

"bstansberry" wrote:
I believe I have found a solution to the 403 problem with JBoss/Tomcat.

The issue is that the JBoss JaasSecurityManager requires that the user's credentials (e.g. username and password) be reauthenticated with every request. If this is not done, the JaasSecurityManager will not reliably have access to the user's role permission set when it determines whether the user has rights to a role needed to access a URL.

Tomcat's various Authenticator classes (e.g. org.apache.catalina.authenticator.FormAuthenticator) can be configured to do what JBoss wants. This is done by calling setCache(false) on these classes, which JBoss does as part of its embedded Tomcat deployment configuration.

The problem is the Tomcat SingleSignOn valve implementation does not include similar behavior. There is no setCache() method in org.apache.catalina.authenticator.SingleSignOn. Once a user has authenticated to a single sign-on session, his credentials are never again presented to the JaasSecurityManager. As a result, JaasSecurityManager does not reliably have access to the user's role set, and invalidly denies authorization to protected resources.

The problem appears to be intermittent due to a "quirk" in the JaasSecurityManager. When a user authenticates, his Subject is bound to the active thread in a ThreadLocal variable. When the same thread makes a subsequent authorization check by calling doesUserHaveRole(), that method checks if there is ANY Subject object bound to the current thread. If there is, it goes ahead, takes the Principal object passed to it as an argument, and uses that Principal to look up the user's roles. So, if ANY Subject has been bound to the current thread, the security manager will do a proper (??) lookup of roles and will not invalidly deny permission. Of course, Tomcat has a pool of threads that it uses to handle requests (class HttpProcessor). If a request by chance happens to get handed off to a HttpProcessor thread that previously handled a user logon, there will be some Subject object bound to that thread, and the call to doesUserHaveRole() will process correctly. If the request gets handed to a HttpProcessor thread that has not handled a logon, the invalid 403 occurs.

For the project I've been working on to succeed, this problem has to be resolved, so I took a crack at fixing it. If you go to sourceforge.net and look in the JBoss Patches area for patch #729923, you can get it. Its not really a patch (meaning you don't have to rebuild JBoss to use it), it's installable library code. I keep trying to upload the zip to this forum, but it always fails. Unfortunately, to get the zip small enough to upload to sourceforge, I had to remove the build jars, so to use it you'll have to run Ant on the enclosed build file.

It seems to work with both 3.0.7 and 3.2.0.

Please feel free to use, enhance, improve, criticize, make suggestions, etc. I'm sure there are problems with it; I'd be very much appreciative if any of you point them out. There is a README file inside the zip that discusses how to build and use it.

Cheers!
Brian

"bstansberry" wrote:
Please forgive if this post ends up showing up multiple times. The forum keeps saying it's there, but it never appears in the discussion thread!!! UGH!

I believe I have found a solution to the 403 problem with JBoss/Tomcat.

The issue is that the JBoss JaasSecurityManager requires that the user's credentials (e.g. username and password) be reauthenticated with every request. If this is not done, the JaasSecurityManager will not reliably have access to the user's role permission set when it determines whether the user has rights to a role needed to access a URL.

Tomcat's various Authenticator classes (e.g. org.apache.catalina.authenticator.FormAuthenticator) can be configured to do what JBoss wants. This is done by calling setCache(false) on these classes, which JBoss does as part of its embedded Tomcat deployment configuration.

The problem is the Tomcat SingleSignOn valve implementation does not include similar behavior. There is no setCache() method in org.apache.catalina.authenticator.SingleSignOn. Once a user has authenticated to a single sign-on session, his credentials are never again presented to the JaasSecurityManager. As a result, JaasSecurityManager does not reliably have access to the user's role set, and invalidly denies authorization to protected resources.

The problem appears to be intermittent due to a "quirk" in the JaasSecurityManager. When a user authenticates, his Subject is bound to the active thread in a ThreadLocal variable. When the same thread makes a subsequent authorization check by calling doesUserHaveRole(), that method checks if there is ANY Subject object bound to the current thread. If there is, it goes ahead, takes the Principal object passed to it as an argument, and uses that Principal to look up the user's roles. So, if ANY Subject has been bound to the current thread, the security manager will do a proper (??) lookup of roles and will not invalidly deny permission. Of course, Tomcat has a pool of threads that it uses to handle requests (class HttpProcessor). If a request by chance happens to get handed off to a HttpProcessor thread that previously handled a user logon, there will be some Subject object bound to that thread, and the call to doesUserHaveRole() will process correctly. If the request gets handed to a HttpProcessor thread that has not handled a logon, the invalid 403 occurs.

For the project I've been working on to succeed, this problem has to be resolved, so I took a crack at fixing it. If you go to sourceforge and look in the JBoss Patches area for patch 729923, the attached zip file that contains the first solid cut at my efforts. It's not really a patch (you don't have to rebuild JBoss to use it), its libraries you install in server/.../lib.

Sorry I can't attach it here; the forum file upload seems to not be working. Unfortunately, to upload to sourceforge I had to get it < 256Kb so had to remove the pre-built jars. You'll have to run Ant on the enclosed build file.

It seems to work with both 3.0.7 and 3.2.0.

Please feel free to use, enhance, improve, criticize, make suggestions, etc. I'm sure there are problems with it; I'd be very much appreciative if any of you point them out. There is a README file inside the zip that discusses how to use it.


Cheers!
Brian

"CobraFlow" wrote:
I'm going to have a play with this right away...top man!

I shall report my findings...

Lewis

"CobraFlow" wrote:
...sorry...no...

11:26:31,192 INFO [Engine] SingleSignOn[localhost]: Process request for '/WorkqueueManager/images/openfolder.gif'
11:26:31,192 INFO [Engine] SingleSignOn[localhost]: Checking for SSO cookie
11:26:31,192 INFO [Engine] SingleSignOn[localhost]: Checking for cached principal for C060497768C336247D1B92D91AF3BC13
11:26:31,192 INFO [Engine] SingleSignOn[localhost]: Reauthenticated cached principal 'Lewis' with auth type 'FORM'
11:26:31,202 INFO [Engine] SingleSignOn[localhost]: Process request for '/WorkqueueManager/images/closedfolder.gif'
11:26:31,202 INFO [Engine] SingleSignOn[localhost]: Checking for SSO cookie
11:26:31,202 INFO [Engine] SingleSignOn[localhost]: Checking for cached principal for C060497768C336247D1B92D91AF3BC13
11:26:31,202 INFO [Engine] SingleSignOn[localhost]: Reauthenticated cached principal 'Lewis' with auth type 'FORM'
11:26:31,242 INFO [Engine] SingleSignOn[localhost]: Process request for '/WorkqueueManager/images/document.gif'
11:26:31,242 INFO [Engine] SingleSignOn[localhost]: Checking for SSO cookie
11:26:31,242 INFO [Engine] SingleSignOn[localhost]: Checking for cached principal for C060497768C336247D1B92D91AF3BC13
11:26:31,242 INFO [Engine] SingleSignOn[localhost]: Reauthenticated cached principal 'Lewis' with auth type 'FORM'
11:26:33,956 INFO [Engine] SingleSignOn[localhost]: Process request for '/InfoRoute/action/acquire.do'
11:26:33,956 INFO [Engine] SingleSignOn[localhost]: Checking for SSO cookie
11:26:33,956 INFO [Engine] SingleSignOn[localhost]: Checking for cached principal for C060497768C336247D1B92D91AF3BC13
11:26:33,956 INFO [Engine] SingleSignOn[localhost]: Reauthenticated cached principal 'Lewis' with auth type 'FORM'
11:26:33,956 INFO [Engine] SingleSignOn[localhost]: Associate sso id C060497768C336247D1B92D91AF3BC13 with session StandardSession[FFF85FE195F5EEF9AE072F95AC664A6D]

I then get the 403...

The above environment is

MultiApp.ear
..InfoRoute.war (struts application)
....Realm - CobraFlow
......invalid login jsp (does not exist)
..WorkqueueManager.war
....Realm - CobraFlow
......login.jsp

WorkqueueManager is the 'front-end' application. The login stuff is all done here. The welcome page redirects to a secured jsp int WorkqueueManager and the login occurs. On this secure jsp I have an href to a secure url '/InfoRoute/action/acquire.do' this will FORWARD to a secure jsp in InfoRoute.war

I am assuming that I need FORM based login in both applications even though the login.jsp and error.jsp in InfoRoute.war will never be used (maybe even redirect to WorkqueueManager...)

I have two things to try :-
1) See how far down the request I am getting before I hit the 403. i.e. Is it the action or the forward to the jsp that is causing the problem.
2) The two applications outside the EAR as that was my original test environment in the previous posts.


Regards

Lewis

"CobraFlow" wrote:
YES YES YES!!!!!

I have removed the security constraint on the /action/* URI but left it on the JSP that it forwards to and it...............(holding my breath!!)............(purple now).....works!!!!!!

I am running JBoss_3.0.6/Tomcat_4.1.18. I shall post any more feedback as it happens (moving to 3.2 etc!)

Thanks again

Lewis

"bstansberry" wrote:
That's great! I knew it worked in our environment, but had no chance to test a bunch of different configurations.

Let me know if you have any troubles.

Brian

"bstansberry" wrote:
It appears today the file upload is working, so attached is the zip I talked about before. It contains source and pre-built jars.

Best,
Brian

"egilmont" wrote:
Maybe I'm wrong....

I'm using JBoss 3.2.1 with embedded Tomcat.

I try to create a modified version of org.jboss.web.catalina.EmbeddedCatalinaServiceSXMBean but didn't found this source file. I only have EmbeddedCatalinaService41 and EmbeddedCatalinaService41MBean.

Is this last file I must modify in order to have SSO working?

Emmanuel