On 14 Mar 2015, at 4:15 PM, Graham Leggett minf...@sharp.fm wrote:
I have reached the point where with an auth-method of CLIENT-CERT is
returning the Subject DN of the certificate as the username.
What I need to achieve is for tomcat to honour the REMOTE_USER environment
variable as set by Apache httpd. I have noticed the tomcatAuthentication flag
can be used to ask tomcat to respect the authentication decision provided by
Apache httpd, but breakpoints set at the point where we check for these
values in AbstractAjpProcessor never fire.
Is this possible?
I discovered that the piece of the Apache config that was enforcing the cert
auth had been temporarily disabled. Enabling that brought me to the next wall.
When tomcat passes through httpd's version of REMOTE_USER, tomcat places the
resulting effective userid in a CoyotePrincipal object.
When the realms are being parsed, the DataSourceRealm falls back to the
RealmBase version of hasRole(), which denies access (again, silently with no
log message or explanation) because the principal object is not a
GeneralPrincipal.
if ((principal == null) || (role == null) ||
!(principal instanceof GenericPrincipal))
// BOOM - we fail here and silently return false
return (false);
GenericPrincipal gp = (GenericPrincipal) principal;
boolean result = gp.hasRole(role);
if (log.isDebugEnabled()) {
String name = principal.getName();
if (result)
log.debug(sm.getString(realmBase.hasRoleSuccess, name, role));
else
log.debug(sm.getString(realmBase.hasRoleFailure, name, role));
}
Looking at CoyotePrincipal, this represents a simple username only. In
contrast, GenericPrincipal represents a username/password/list-of-roles triple.
I need to dig further, but it seems that the tomcatAuthentication option
silently disables authorization in the process.
Regards,
Graham
—
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
