Created attachment 32567 [details] Patch for tomcat v7.0.x In the current implementation of the tomcatAuthentication parameter, this allows the REMOTE_USER variable from the webserver to be used as the principal for the tomcat request. A side effect of this option is that if the web application uses roles (authorization), the roles will be silently ignored, and the user will be locked out. This limits the usefulness of tomcatAuthentication. The attached patches introduce the tomcatAuthorization flag. When true, the REMOTE-USER will be used as the principal, while authorization will continue in Tomcat as normal. What this means practically is that it now becomes possible to place a webserver in front of a web application, and the authentication performed by the webserver will cleanly replace the authentication performed by tomcat, while leaving the web application authorization configuration intact.
Created attachment 32568 [details] Patch for tomcat v8.0.x
Created attachment 32569 [details] Patch for tomcat v9.0.x
I've taken a quick look at the patch for 9.0.x. I suspect that my comments will apply equally to the back-ports. Overall, +1. I'd change some of the details (see below) but the general approach looks sound. I'm happy fixing the details when I apply the patch so no need to re-submit. On those details: - 'remote user' has a specific meaning in a servlet container. I think this needs to be changed to 'AJP authenticated user'or something similar. - The indentation is inconsistent (it should be four spaces). Some of that is because the patch is trying to follow the existing code which itself is not very consistent. In particular, the continuation lines look odd. - There is clearly some scope for refactoring to reduce duplication in the authenticators. That should be completed first. I'm a little wary of adding a new method to Realm but, we have done that before when the need arose and there is an implementation in RealmBase so the impact should be minimal. Thanks for the patch. This is on my todo list for tomorrow.
I did look at this yesterday and I got as far as having something ready to commit but I'm not entirely happy with. The question is where to do the authorization. If authorization is done in the CoyoteAdaptor (the Context and therefore the Realm is available) then it will work regardless of the Authenticator implementation that is used. The down side is that it happens before the Principal caching that avoids large numbers of Realm lookups is reached (this is in AuthenticatorBase). It also makes an assumption that the request mapping won't changed (e.g. by the RewriteValve). If authorization is done in AuthenticatorBase then Connector authorization depends on the Authenticator implementation and that doesn't seem right. I've looked at several options and - so far - all of them have issues. I'll spend some more time thinking about this.
I opted for a combination of both approaches. Implemented in r4667546 for Tomcat 9 based on the provided patch. I'm happy to back-port this to 8.0.x. Not so sure about 7.0.x. Definitely not for 6.0.x.
Back-ported to 8.0.x for 8.0.21 onwards.
Thanks for this. We backported all the way back to v7.0.x, as we're forced to use that by support contracts on various software, such as Jira and Confluence.
Backported to 7.0.xfor 7.0.60 onwards.