On 20/04/2013 07:04, David Jencks wrote: > Hi Mark, > > I hope my being tired doesn't come across as being unpleasant… if so > I apologize in advance.
Not at all. No need to apologize. > I think a lot of the security discussion in the servlet spec is vague > and misleading. I think the JACC spec provides a firmer basis for > thinking about how security is supposed to work. The Servlet spec plus the J2EE spec should provide all the necessary information. If the Servlet spec needs clarification then specific areas can be raised with the Servlet EG. For 3.1 requests for clarification were generally actioned fairly quickly. > IMO you have misinterpreted roles in the ee specs. Quite possibly. I certainly should have read the Servlet spec more carefully before posting and probably the J2EE spec as well. I've just read the Servlet spec and it does clarify a couple of things but I think there are still some problems around plugability. > Based on the JACC WebRoleRefPermission, where the constructor > arguments are the servlet name and the role name, I've concluded that > the a filter gets the same isUserInRole behavior as the servlet the > request ends up at after going through the filter. I think this is a > satisfactory solution, and it's passed quite a few ee tcks by now. > It's also quite easy to implement :-). I think talking to Ron > Monzilla if you disagree with it would be the way to go. That seems reasonable prior to Servlet 3.0 and is exactly what Tomcat does at the moment. For Servlet 3.0 I think there is a potential issue if a request is mapped to a Filter and a Servlet from different fragments and the Filter and Servlet require different security-role-ref entries. There is currently no easy way to handle this. I don't yet see a simple solution to this problem. That said, so far this is only a theoretical problem and one solution could just be to clarify the situation (calls to isUserInRole in Filters always use the mapping from the mapped Servlet) in the Servlet spec. > IIUC tomcat has chosen to only support mappings where the principal > name equals the name of the application security role. IIRC the last > time I looked many years ago tomcat did not verify that all the > security roles used in security constraints or by isUserInRole calls > were actually declared application roles. Not quite. Using the Servlet spec language (particularly 13.5) Tomcat supports Principals that are members of groups and only supports a one-to-one mapping of groups to application security roles. That is certainly a limitation of Tomcat's security implementation and one we could look at improving. > From my limited recollection of tomcat internals, I don't understand > why tomcat doesn't verify that security roles that are used are > declared, Tomcat does verify this. It logs a warning if an undeclared role is used and then proceeds as if the role had been declared. We could change it to fail the web application when STRICT_SERVLET_COMPLIANCE is used but that isn't something I feel is necessary. > and why there isn't a more flexible mapping from e.g. > groups to application roles. No-one has felt the need to scratch that particular itch. > For your specific example "admin" and "sysuser" are distinct > application roles available for use across the entire application and > the problem is that there is no way in tomcat to map the hr-manager > principal representing an ldap group to roles with different names. Yes, that part of my example is a Tomcat limitation. > I think (a) is correct, by providing a more flexible way to map > between principals and application roles. I agree that that would solve that part of the problem but the issue does remain for Filters and Servlets from different fragments needing different security-role-refs. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
