Getting tomcat to honour REMOTE_USER as provided via mod_proxy_ajp

[Graham Leggett <mi...@sharp.fm>]

Hi all,

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?

Regards,
Graham
—


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

Re: Getting tomcat to honour REMOTE_USER as provided via mod_proxy_ajp

[Graham Leggett <mi...@sharp.fm>]

On 14 Mar 2015, at 4:15 PM, Graham Leggett <mi...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org