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 Mon, 22 Apr 2013 15:21:22 GMT
On Apr 21, 2013, at 11:37 PM, David Jencks <> wrote:

> On Apr 21, 2013, at 3:56 PM, Jeremy Boynes <> wrote:
>> 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.
> 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.

I may be wrong, but I've viewed @DeclareRoles as more akin to <security-role-ref> in
that is declaring a role reference I make from within code in a discoverable way; without
annotation, an assembler or deployer would need to rely on documentation supplied with the
code to know this reference was made. That's different to @RolesAllowed et al. which are specifying
the deployment concern of what roles are permitted to access the servlet.

Or, putting it another way, @DeclaresRole is metadata describing what the implementation code
does whereas @RolesAllowed is configuration about the how the code should be used. Changing
the role reference described by @DeclaresRole requires modifying the code that calls isUserInRole()
which is outside the assembly/deployment 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.
> How is this different from the existing possibility to define a proprietary mapping between
principal names and application role names?

It's a portable way for an assembler creating a web-application from components provided by
different suppliers to link the roles declared in the annotations (whose names are defined
by the component providers) to a common set of application roles (defined by the assembler).
The deployer then maps one set of application roles to principal names in a proprietary way.

Its trying to address the situation where two components from different providers both specify
@RolesAllowed("user") but mean different things by "user," or where one defines "user" and
the other defines "customer" and the assembler wants them to map to the same application role.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message