[
https://issues.apache.org/jira/browse/GERONIMO-5626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jencks resolved GERONIMO-5626.
------------------------------------
Resolution: Fixed
See also tomcat bugzilla 50015 and 50016
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
