2 Replies Latest reply on May 14, 2004 12:34 PM by Brian Stansberry

    Tomcat SingleSignOn Invalid 403 Error

    Brian Stansberry Newbie

      Sorry to create a new topic; for some reason my posts to existing topic http://www.jboss.org/modules/bb/index.html?module=bb&op=viewtopic&t= do not appear. Maybe 20 messages is the max the forum will hold in a thread.

      Anyway, 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 section for patch 729923, the attached zip file contains the first solid cut at my efforts.

      Sorry I couldn't upload it here; the forum seems to not be accepting uploads. Unfortunately, sourceforge only accepts < 256Kb uploads; to get the zip that small I had to remove the pre-built jars. So, you'll have to run Ant against 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