Beehive
  1. Beehive
  2. BEEHIVE-635

Tomcat PageflowValve does not check for security-constraints defined in web.xml

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: V1Alpha, V1Beta, v1m1
    • Fix Version/s: 1.0.1
    • Component/s: NetUI
    • Labels:
      None
    • Environment:
      Using beehive latest from SVN and Tomcat 5.5.7

      Description

      The Tomcat implementation of the Pipeline for a Context is such that only one Valve which is also an Authenticator valve is added to the Pipeline. The standard Tomcat Authenticator valves (e.g. BasicAuthenticator) check for and honor all the security constraints specified in the webapp web.xml descriptor.

      The PageflowValve implementation part of tomcat-server under netui is an Authenticaor valve as it extends BasicAuthenticator, which means that it is mutually exclusive with the regular Tomcat authenticator valves (only one can be in the pipeline). It does not however keep the features that were part of the AuthenticatorBase and the BasicAuthentiocator invoke() method implementation. Such issue results for example in the user-data-constraint elements being completely ignored, and therefore pages who are supposed to be served only with SSL are always served without SSL.

      Following is an example of the code from the regular Tomcat authenticators that is missing from beehive adapter (please note that the code is from Tomcat 5.5.7 with which by the way beehive does not compile, but should give you a good idea of the missing features...):

      // Enforce any user data constraint for this security constraint
      if (log.isDebugEnabled())

      { log.debug(" Calling hasUserDataPermission()"); }

      Realm realm = this.context.getRealm();
      // Is this request URI subject to a security constraint?
      SecurityConstraint [] constraints
      = realm.findSecurityConstraints(request, this.context);
      if (!realm.hasUserDataPermission(request, response,
      constraints)) {
      if (log.isDebugEnabled())

      { log.debug(" Failed hasUserDataPermission() test"); }

      /*

      • ASSERT: Authenticator already set the appropriate
      • HTTP status code, so we do not have to do anything special
        */
        return;
        }
      1. patch.txt
        11 kB
        Abdessattar Sassi

        Activity

        Hide
        Julie Zhuo added a comment -

        Verified with rev374070. There is a test web in the tree that test the log in using tomcat and picking up the roles and security constraints from web.xml. Run the tests against tomcat5.5.9 successfully. Although the build files in netui/test/webapps/tomcat is not working currently due to the test environment build struture change lately. Will submit a patch to update it later at some point.

        Show
        Julie Zhuo added a comment - Verified with rev374070. There is a test web in the tree that test the log in using tomcat and picking up the roles and security constraints from web.xml. Run the tests against tomcat5.5.9 successfully. Although the build files in netui/test/webapps/tomcat is not working currently due to the test environment build struture change lately. Will submit a patch to update it later at some point.
        Hide
        Rich Feit added a comment -

        I meant to resolve this a long time ago – these changes are in the Tomcat 5.5 ServletContainerAdapter that was contributed by Abdessattar (thanks again!).

        Alex, to repro this, you can just add the following security constraint to web.xml:

        <security-constraint>
        <web-resource-collection>
        <web-resource-name>Secure PageFlow - all</web-resource-name>
        <url-pattern>/security/secure.jsp</url-pattern>
        </web-resource-collection>
        <user-data-constraint>
        <transport-guarantee>CONFIDENTIAL</transport-guarantee>
        </user-data-constraint>
        </security-constraint>

        Then, follow the instructions at $BEEHIVE_HOME/netui/test/webapps/tomcat/README.txt for integrating with Tomcat 5.5, deploy the app, and hit http://localhost:8080/<your webapp name>/security/secure.jsp. If the bug is fixed, then the request will be switched to https. If not, it'll remain in http.

        Show
        Rich Feit added a comment - I meant to resolve this a long time ago – these changes are in the Tomcat 5.5 ServletContainerAdapter that was contributed by Abdessattar (thanks again!). Alex, to repro this, you can just add the following security constraint to web.xml: <security-constraint> <web-resource-collection> <web-resource-name>Secure PageFlow - all</web-resource-name> <url-pattern>/security/secure.jsp</url-pattern> </web-resource-collection> <user-data-constraint> <transport-guarantee>CONFIDENTIAL</transport-guarantee> </user-data-constraint> </security-constraint> Then, follow the instructions at $BEEHIVE_HOME/netui/test/webapps/tomcat/README.txt for integrating with Tomcat 5.5, deploy the app, and hit http://localhost:8080/ <your webapp name>/security/secure.jsp. If the bug is fixed, then the request will be switched to https. If not, it'll remain in http.
        Hide
        Rich Feit added a comment -

        Will get this in ASAP after we get 1.0 out the door.

        Show
        Rich Feit added a comment - Will get this in ASAP after we get 1.0 out the door.
        Hide
        Abdessattar Sassi added a comment -

        Attached in patch.txt is a SVN patch file to add the necessary code and fixes for the Tomcat adapter to work with Tomcat 5.5.7 or later.
        Note that the patch requires that the catalina.jar and tomcat-coyote.jar in netui/external/tomcat/5x be updated from tomcat 5.5.7 at least (preferably 5.5.9).

        Show
        Abdessattar Sassi added a comment - Attached in patch.txt is a SVN patch file to add the necessary code and fixes for the Tomcat adapter to work with Tomcat 5.5.7 or later. Note that the patch requires that the catalina.jar and tomcat-coyote.jar in netui/external/tomcat/5x be updated from tomcat 5.5.7 at least (preferably 5.5.9).
        Hide
        Eddie O'Neil added a comment -

        Same thing in 635 as with the fix version in 634:

        http://issues.apache.org/jira/browse/BEEHIVE-635

        This is definitely something we should support post 1.0; moving to fix in TBD.

        Abdessattar, looks like you're halfway to a patch here.

        Show
        Eddie O'Neil added a comment - Same thing in 635 as with the fix version in 634: http://issues.apache.org/jira/browse/BEEHIVE-635 This is definitely something we should support post 1.0; moving to fix in TBD. Abdessattar, looks like you're halfway to a patch here.

          People

          • Assignee:
            Julie Zhuo
            Reporter:
            Abdessattar Sassi
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development