geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Jencks (JIRA)" <>
Subject [jira] [Resolved] (GERONIMO-5626) Improvements in tomcat security contracts
Date Tue, 08 May 2012 17:45:50 GMT


David Jencks resolved GERONIMO-5626.

    Resolution: Fixed

See also tomcat bugzilla 50015 and 50016
> Improvements in tomcat security contracts
> -----------------------------------------
>                 Key: GERONIMO-5626
>                 URL:
>             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.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message