>
> 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.
