You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2024/02/28 19:53:30 UTC
Add support for HTTP connectors to accept REMOTE_USER information from a proxy?
All,
When using AJP, setting tomcatAuthentication="false" allows mod_jk or
mod_proxy_ajp to transmit authenticated user information across the
connection to Tomcat so that request.getRemoteUser() will return
whatever httpd has for REMOTE_USER.
The same is not true for the HTTP connectors.
RemoteIPValve takes care of X-Forwarded-* headers
SSLValve takes care of SSL_* variables for cipher, client cert, etc.
This appears to be one of the only commonly-used pieces of information
that is difficult to transmit across HTTP while it's easy with AJP.
https://lists.apache.org/thread/bmps52nv8h63mkfqhzmh7p5bhhglgbpl
As a part of my crusade to get people to move from AJP to HTTP, I'd like
to propose that we make arrangements for this information to be
transmitted in some reasonable way.
One way to do it would be to add something to RemoteIPValve that would
be willing to accept e.g. X-Remote-User header and assign that to the
request. (This would be disabled by default!) Straightforward,
relatively easy to understand and configure, and uses existing
components. But perhaps X-Remote-User is "out of scope" for RemoteIPValve?
Another way would be to add tomcatAuthentication="false" as an option
for the HTTP connector. It would behave like its AJP twin, except it
would look in HTTP headers for ... X-Remote-User? REMOTE_USER? Somethign
user-configurable? While this option mirrors the way it's done for AJP,
I don't like it as much as using RemoteIPValve, if for no other reason
than it has nothing to do with the connector itself and the
RemoteIPValve already has similar configuration options for setting the
names of special HTTP headers.
We could introduce a new Valve that just does this, and maybe adds other
things later that we find are also missing. This introduces a completely
new component, makes the valve chain even longer, etc. and so I still
favor adding this to RemoteIPValve.
Thoughts?
Thanks,
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Add support for HTTP connectors to accept REMOTE_USER information from a proxy?
Posted by Mark Thomas <ma...@apache.org>.
On 06/03/2024 08:51, Christopher Schultz wrote:
> All,
>
> *bump*
>
> Any thoughts?
I'd go with the RemoteIPValve.
Mark
>
> -chris
>
> On 2/28/24 14:53, Christopher Schultz wrote:
>> All,
>>
>> When using AJP, setting tomcatAuthentication="false" allows mod_jk or
>> mod_proxy_ajp to transmit authenticated user information across the
>> connection to Tomcat so that request.getRemoteUser() will return
>> whatever httpd has for REMOTE_USER.
>>
>> The same is not true for the HTTP connectors.
>>
>> RemoteIPValve takes care of X-Forwarded-* headers
>>
>> SSLValve takes care of SSL_* variables for cipher, client cert, etc.
>>
>> This appears to be one of the only commonly-used pieces of information
>> that is difficult to transmit across HTTP while it's easy with AJP.
>>
>> https://lists.apache.org/thread/bmps52nv8h63mkfqhzmh7p5bhhglgbpl
>>
>> As a part of my crusade to get people to move from AJP to HTTP, I'd
>> like to propose that we make arrangements for this information to be
>> transmitted in some reasonable way.
>>
>> One way to do it would be to add something to RemoteIPValve that would
>> be willing to accept e.g. X-Remote-User header and assign that to the
>> request. (This would be disabled by default!) Straightforward,
>> relatively easy to understand and configure, and uses existing
>> components. But perhaps X-Remote-User is "out of scope" for
>> RemoteIPValve?
>>
>> Another way would be to add tomcatAuthentication="false" as an option
>> for the HTTP connector. It would behave like its AJP twin, except it
>> would look in HTTP headers for ... X-Remote-User? REMOTE_USER?
>> Somethign user-configurable? While this option mirrors the way it's
>> done for AJP, I don't like it as much as using RemoteIPValve, if for
>> no other reason than it has nothing to do with the connector itself
>> and the RemoteIPValve already has similar configuration options for
>> setting the names of special HTTP headers.
>>
>> We could introduce a new Valve that just does this, and maybe adds
>> other things later that we find are also missing. This introduces a
>> completely new component, makes the valve chain even longer, etc. and
>> so I still favor adding this to RemoteIPValve.
>>
>> Thoughts?
>>
>> Thanks,
>> -chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Add support for HTTP connectors to accept REMOTE_USER information from a proxy?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
All,
*bump*
Any thoughts?
-chris
On 2/28/24 14:53, Christopher Schultz wrote:
> All,
>
> When using AJP, setting tomcatAuthentication="false" allows mod_jk or
> mod_proxy_ajp to transmit authenticated user information across the
> connection to Tomcat so that request.getRemoteUser() will return
> whatever httpd has for REMOTE_USER.
>
> The same is not true for the HTTP connectors.
>
> RemoteIPValve takes care of X-Forwarded-* headers
>
> SSLValve takes care of SSL_* variables for cipher, client cert, etc.
>
> This appears to be one of the only commonly-used pieces of information
> that is difficult to transmit across HTTP while it's easy with AJP.
>
> https://lists.apache.org/thread/bmps52nv8h63mkfqhzmh7p5bhhglgbpl
>
> As a part of my crusade to get people to move from AJP to HTTP, I'd like
> to propose that we make arrangements for this information to be
> transmitted in some reasonable way.
>
> One way to do it would be to add something to RemoteIPValve that would
> be willing to accept e.g. X-Remote-User header and assign that to the
> request. (This would be disabled by default!) Straightforward,
> relatively easy to understand and configure, and uses existing
> components. But perhaps X-Remote-User is "out of scope" for RemoteIPValve?
>
> Another way would be to add tomcatAuthentication="false" as an option
> for the HTTP connector. It would behave like its AJP twin, except it
> would look in HTTP headers for ... X-Remote-User? REMOTE_USER? Somethign
> user-configurable? While this option mirrors the way it's done for AJP,
> I don't like it as much as using RemoteIPValve, if for no other reason
> than it has nothing to do with the connector itself and the
> RemoteIPValve already has similar configuration options for setting the
> names of special HTTP headers.
>
> We could introduce a new Valve that just does this, and maybe adds other
> things later that we find are also missing. This introduces a completely
> new component, makes the valve chain even longer, etc. and so I still
> favor adding this to RemoteIPValve.
>
> Thoughts?
>
> Thanks,
> -chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org