On Jan 5, 2009, at 4:13 AM, Luis Fernando Planella Gonzalez wrote:


I tried this out in embedded mode using "guest" instead of "public" and it
worked fine.  Should work the same way in Tomcat.

Give the code above a try in Tomcat but with "guest" in the RolesAllowed instead of "public". If that works as I suspect, than making the change to
allow the default username to be changed should do the trick.


It doesn't work in Tomcat. I've noticed that TomcatSecurityService overrides
the getLogicalRoles() method.

AbstractSecurityService implements it by iterating over the logical roles and the principal names, granting roles matching principal names. In that case, what you said is true: having a default principal named "guest" would
have a role named "guest".

However, TomcatSecurityService understands two Principal implementations:
TomcatUser (which carries together the Realm, and delegates to it) and
RunAsRole, which knows the role being "runned as".

In my case, to make it work, I've implemented the following in a tomcat
Valve:

   @Override
   public void invoke(Request request, Response response) throws
IOException, ServletException {

       if (!initialized) {
           SystemInstance systemInstance = SystemInstance.get();
           final RoleResolver defaultResolver = (RoleResolver)
systemInstance.getComponent(SecurityService.class);
           systemInstance.setComponent(RoleResolver.class, new
RoleResolver() {
               @Override
public Set<String> getLogicalRoles(Principal[] principals,
Set<String> logicalRoles) {
                   Set<String> roles =
defaultResolver.getLogicalRoles(principals, logicalRoles);
                   if (roles == null || roles.isEmpty()) {
                       roles.add("public");
                   }
                   return roles;
               }
           });
           initialized = true;
       }
   }

It works, because the defaultResolver (TomcatSecurityService) returns no
roles.

So, it seems to me that it's really a new feature to be implemented. I've
registered https://issues.apache.org/jira/browse/OPENEJB-984 for it.

I see. Looks like we should update the TomcatSecurityService to understand the User and Group principals that will be in the defaultSubject created by its parent. That in addition to letting the defaultSubject name be configurable seems like it'd do the trick.

-David


Reply via email to