geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Jencks (JIRA)" <j...@apache.org>
Subject [jira] Created: (GERONIMO-5626) Improvements in tomcat security contracts
Date Wed, 22 Sep 2010 22:41:37 GMT
Improvements in tomcat security contracts
-----------------------------------------

                 Key: GERONIMO-5626
                 URL: https://issues.apache.org/jira/browse/GERONIMO-5626
             Project: Geronimo
          Issue Type: Bug
      Security Level: public (Regular issues)
          Components: Tomcat
    Affects Versions: 3.0
            Reporter: David Jencks
            Assignee: David Jencks
             Fix For: 3.0


I have some problems with some internal tomcat security arrangements.  I'm going to work in
our tomcat copy first and when I'm satsified with the changes suggest them to tomcat.

There are 2 similar problems that have a bad division of responsibility.

1. Request.isUserInRole tries to prevent jacc implementations and is also wrong.

In the current tomcat implementation, role-ref mappings are first applied to the supplied
role and then the target role is tested.  If the user is not in the mapped role the original
role is tested.  However,
(a). jacc requires that this be implemented by constructing a role-ref permission with the
current servlet name and the _supplied_ (not mapped) role.  So to be reasonably amenable to
a jacc implementation Request.isUserInRole should supply the _original_ role and if possible
the servlet name.  
(b) if there is a mapping, only the mapped role should be checked.  Aside from the spec language,
consider a web app with two roles A and B and a servlet S that maps A to B and B to A.  A
user that logs in and is in role A and not B should be able to test in S

is in A >> false
is in B >> true

The current implementation reports true for both A and B.

2.  The implementation of the new login and logout methods are excessively intrusive into
the internals of the authentication.  Both should be delegated directly to the Authenticator.
 In particular, checking which known Authenticator is installed to see if it supports user/pw
login is overly restrictive since other authenticators might be installed.  Also any caching
of the results certainly doesn't belong in the Request.



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message