[jira] [Resolved] (GERONIMO-5626) Improvements in tomcat security contracts

["David Jencks (JIRA)" <ji...@apache.org>]

     [ 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