Hi Mark, I hope my being tired doesn't come across as being unpleasant… if so I apologize in advance.
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. IMO you have misinterpreted roles in the ee specs. The specs including the servlet spec define application roles and base the declarative security constraints on them. Then you can map strings that bits of the application like, at least ejbs and servlets, to these declared security roles using a security-role-ref. The role-link has to be one of the declared application roles. For web apps the security-role-ref is defined on servlets. The application roles no matter where defined are scoped to the entire application not just one web app or web fragment. If a security-role-ref is not defined for a string, and you call isUserInRole with that string, the string is assumed to be a defined application role. 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. Then you presumably have an external security system such as ldap with some defined entities such as groups, and these usually get represented as Principals, perhaps in a Subject.. These are not application roles. You need to map the externally defined entities to the application roles. 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. From my limited recollection of tomcat internals, I don't understand why tomcat doesn't verify that security roles that are used are declared, and why there isn't a more flexible mapping from e.g. groups to application roles. 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. Your option (b) is IMO definitely and very clearly not spec compliant. I think (a) is correct, by providing a more flexible way to map between principals and application roles. I've always thought that even a default map between principals and roles using name equality was somewhat dangerous in the case that you don't want to assign any groups to a particular role. The ldap administrators could not know about the role and create a matching group and suddenly there are users in that role. A little googling to try to remind myself about security-role-refs turned up http://docs.oracle.com/javaee/5/tutorial/doc/bncav.html#bncax which indicates very clearly that Sun thinks groups are not roles and that you need a flexible mapping between them. (see the sun-web-app snippet at the bottom). thanks david jencks On Apr 19, 2013, at 2:28 PM, Mark Thomas <ma...@apache.org> wrote: > Currently, Tomcat only checks against <security-role-ref> elements if > there is a call to isUserInRole(). Prior to Servlet 3.0 this made sense. > The person deploying the web application has control over web.xml and > hence the security roles (those used in security constraints) but no > control over application roles (those used by developers in Servlets > with isUserInRole()) and therefore needed a mechanism to map the > application roles to security roles. > > This mechanism is usually used to map application roles to security > roles that exist in an external authentication and authorisation system > such as an LDAP directory. For example, the application role admin in > the HR application may get mapped to the hr-manager role that exists in > the LDAP directory. > > With Servlet 3.0 plugability features the picture changes a little. > > Now a fragment may define security constraints that use a security role > that does not match the organisations security roles and can't be > modified in the application's web.xml. For example, an HR application > with two fragments may define a role "admin" in fragment A and "sysuser" > in fragment B both of which need to be mapped to the "hr-manager" role. > > Oh, and just to throw a spanner in the works, if a Filter uses > isUserInRole() there is no way to map the application role to a security > role. > > I'm currently unsure how this issue should be addressed. The options as > I see them are: > > a) There is an obvious solution I have missed. > > b) Check <security-role-ref>'s when processing security constraints. > > c) Something else. > > > Given the Filter issue, I think c) is the only viable option. > > > Tomcat's current behaviour looks to be specification compliant but there > appears to me to be an issue here the the Servlet EG needs to address. > Before I move this issue there what do folks think about this? Is there > an issue or am I missing the obvious? > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
