tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Mapping role names to groups
Date Thu, 06 Aug 2009 15:17:25 GMT
Hash: SHA1


On 8/6/2009 8:33 AM, Jason Royals wrote:
> Thanks for the advice, but I think <security-role-ref> is only valid
> within the context of a <servlet> element though? As such, it wont work
> on JSP's or other resources that might do a
> request.isUserInRole("admin") but are not servlets themselves (such as
> filters and listeners).

You might be able to get away with re-defining the JSP Servlet and
including the <security-role-ref>, but you're right: that won't cover
filters or listeners. It's a shame the spec is written in this way.

As for André's comment about the top-levelness of <security-role-ref>,
Chuck points out that it's <servlet>-specific, but does not say where
that is defined. I found it very quickly by looking at the 2.3 servlet
DTD ( which contains this

The security-role-ref element contains the declaration of a security
role reference in the web application's code. The declaration consists
of an optional description, the security role name used in the code,
and an optional link to a security role. If the security role is not
specified, the Deployer must choose an appropriate security role.

The value of the role-name element must be the String used as the
parameter to the EJBContext.isCallerInRole(String roleName) method
or the HttpServletRequest.isUserInRole(String role) method.

Used in: servlet

- -->
<!ELEMENT security-role-ref (description?, role-name, role-link?)>

Searching for actual uses of security-role-ref confirms that it is only
valid within a <servlet> element. :(

> I'd also like to avoid changing anything in
> web.xml if possible. Configuring the container is fine (eg, server.xml)
> but messing around too much in the application WAR package could be
> trouble.

I know you mentioned you don't want to mess around with web.xml but I
think you'll probably have to do it. If you're willing to do that, you
could write a filter that wraps the request and overrides isUserInRole
to provide a look-up-table of mapped group names. Something like this:

public class GroupRenamingFilter
   implements Filter
   private Map roleNameMap; /* fill this yourself */

   public void invoke(ServletRequest request, ServletResponse,
FilterChain chain)
      if(request instanceof HttpServletRequest)
        request = new GroupRenamingRequest((HttpServletRequest)request);

      chain.doFilter(request, response)

   private class GroupRemaningRequest
     extends HttpServletRequestWrapper
      public GroupRenamingRequest(HttpServletRequest wrapped)

      public boolean isUserInRole(String roleName)
        String realRoleName = (String)roleNameMap.get(roleName);

        if(null == realRoleName)
          realRoleName = roleName; // not sure what to do, here

        return super.isUserInRole(realRoleName);

Now that I've written it, I think you'll need to implement this as a
Valve that is invoked /before/ Tomcat's authorization code runs (which
may not be possible?).

On the other hand, what's wrong with a search-and-replace within the
web.xml to change the names of the security-role names to those you
actually use instead of the more generic "users" and "admins"?

- -chris
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla -


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

View raw message