On Apr 21, 2013, at 3:56 PM, Jeremy Boynes <jboy...@apache.org> wrote:
> 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. Not quite following you here. I thought you'd declare all your roles using the @DeclareRoles annotation or in @AllowRoles inside constraints. These are equivalent to <security-role> elements in web.xml. If for some reason you don't like the role names in the annotations you can always override them in web.xml just like you can override other non-cdi annotations. Otherwise the deployer can link the principal names to the role names just like with web.xml. > > > 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. How is this different from the existing possibility to define a proprietary mapping between principal names and application role names? thanks david jencks > > 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 >
