On Apr 19, 2013, at 11:04 PM, David Jencks <david_jen...@yahoo.com> wrote: > 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.
Mark does bring up a gap here though. Before 3.0, the only reference to a role from code would be in the parameter value passed to isUserInRole(), and the assembler was responsible for listing all of those in web.xml; the deployer was responsible for linking them to actual roles in <security-role> elements, and then linking those to groups/principals in the authorization system in a container-specific manner. Declarative security (security-constraint/auth-constraint) did not require a linkage mechanism as the deployer could modify the value in the <auth-constraint> declaration in web.xml. With 3.0 annotations, however, the auth-constraint is now declared in code and the deployer has no mechanism to link its roleNames() to an actual role. Option b) sounds like a potential solution but as you say that is not something the spec currently allows. The spec could be extended to allow this, and I think that would even be a compatible change given the existing requirement for <security-role-ref> to default to a <security-role> with the same name if no explicit link is specified. There is a scoping issue for role ref names but that is not new - 2.x libraries can also conflict by using the same value in calls to isUserInRole(). > 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. As the spec stands with <security-role-ref>/@DeclareRoles only allowed on Servlets and not on Filters I'd come to the same conclusion. It is a weird coupling though as the role reference is made by the filter and not the servlet, the servlet author does not know a-priori what filters will be applied or vice versa. Again, more of an issue now we have annotation based config. IMO, getting the spec to clarify this, and potentially allowing filters to declare role references would be useful. I've assumed the same model would apply for calls to isUserInRole() from within listeners e.g. request or request attribute? Or from within an extension-mapped servlet like the JSP servlet? > 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. +1, although falling back to mapping application roles to groups in the absence of configuration by the deployer is temptingly convenient (although with the "new-group" problem you mention). ... > On Apr 19, 2013, at 2:28 PM, Mark Thomas <ma...@apache.org> wrote: ... >> >> 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? Seems to me there's ambiguity there that would be worth clarifying. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
