Hi Eddie, 

I actually have it almost working right now on my environment. It's not
that far from being OK ;) I can specify security constraints in web.xml,
get the CONFIDENTIAL constraint to be partially honored (see below) and
even be able to use both the tomcat authentication based on the web.xml
security constraints side by side with the beehive annotations to
require logins.

The only reason why I'm not happy yet with it is that the patch I have
is partial as it implements the security constraint checking only for
new requests or redirections that go through Tomcat. For example, it
does not ensure the automatic switching to secure connections when
redirections are happening between pageflow actions (which is typically
the case after a NotLoggedInException is thrown). For that, I think that
I will need the beehive team help :-) 

I'll try to submit the patch for Tomcat 5.5 and for the partial security
constraint checking soon.

Regards,
Abdessattar Sassi

-----Original Message-----
From: Eddie O'Neil (JIRA) [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, May 10, 2005 8:44 PM
To: Sassi, Abdessattar
Subject: [jira] Updated: (BEEHIVE-635) Tomcat PageflowValve does not
check for security-constraints defined in web.xml

     [ http://issues.apache.org/jira/browse/BEEHIVE-635?page=all ]

Eddie O'Neil updated BEEHIVE-635:
---------------------------------

    Fix Version: TBD

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.  :)



> Tomcat PageflowValve does not check for security-constraints defined 
> in web.xml
> ----------------------------------------------------------------------
> ---------
>
>          Key: BEEHIVE-635
>          URL: http://issues.apache.org/jira/browse/BEEHIVE-635
>      Project: Beehive
>         Type: Bug
>   Components: NetUI
>     Versions: V1Alpha, V1Beta, V1
>  Environment: Using beehive latest from SVN and Tomcat 5.5.7
>     Reporter: Abdessattar Sassi
>      Fix For: TBD

>
> 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;
>         }

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Reply via email to