tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Mapping role names to groups
Date Thu, 06 Aug 2009 15:17:25 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jason,

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 (http://java.sun.com/dtd/web-app_2_3.dtd) which contains this
documentation:

"
<!--
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)
      {
        super(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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkp69AUACgkQ9CaO5/Lv0PC6qQCaAi3L37mYx5zBU50GUB675qdJ
dRsAoK6UoU7hpjMjvnNQwFVRLM7TAOOG
=zPlp
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message