tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <>
Subject Re: <security-role-ref> and security constraints
Date Sun, 21 Apr 2013 22:56:28 GMT
On Apr 19, 2013, at 11:04 PM, David Jencks <> 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

> 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
+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 <> 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:
For additional commands, e-mail:

View raw message