Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: domain of cedric.couralet@gmail.com
 designates 209.85.213.46 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <52F9F02C.5040708@ice-sa.com>
References: <20140211002056.GD31484@dx4.org>
	<CAMwoAzfL3fG6DUsw1xATFVoHeE1v67M8gZgwS0rDo04SP5nLyw@mail.gmail.com>
	<52F9F02C.5040708@ice-sa.com>
Date: Tue, 11 Feb 2014 11:03:26 +0100
Message-ID: 
 <CAMwoAzcaOOJTCUCLqTb45awO-rddxrLrdnjEiMap+Usx2o+6Yw@mail.gmail.com>
Subject: Re: AJP and attributes versus headers
From: =?ISO-8859-1?Q?C=E9dric_Couralet?= <cedric.couralet@gmail.com>
To: Tomcat Users List <users@tomcat.apache.org>
Content-Type: multipart/alternative; boundary=bcaec50b4bde3ee60604f21e9166

--bcaec50b4bde3ee60604f21e9166
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

2014-02-11 10:41 GMT+01:00 Andr=E9 Warnier <aw@ice-sa.com>:

> C=E9dric Couralet wrote:
>
>> 2014-02-11 1:20 GMT+01:00 Elliot Kendall <elliot.kendall@ucsf.edu>:
>>
>>  We have a Java application running on Tomcat with an Apache HTTP proxy
>>> in front. Our SSO system (Shibboleth) runs as an Apache module and sets
>>> an HTTP header with the logged-in username, which gets passed through
>>> to Tomcat and which the app uses Spring's
>>> RequestHeaderAuthenticationFilter to read.
>>>
>>> We would like to switch from HTTP to AJP for the proxy, as recommended
>>> by our SSO vendor. When we do, though, the logged-in username ends up
>>> in an environment variable and gets passed to Tomcat as a request
>>> attribute rather than a header. The Spring filter is using
>>> javax.servlet.http.HttpServletRequest.getHeader to read the value,
>>> which fails. For things to work, it would need to use
>>> javax.servlet.ServletRequest.getAttribute. As far as I can tell, no
>>> filter exists in Spring that uses requests instead of headers.
>>>
>>> Is there a way to make Tomcat expose the values of AJP request
>>> attributes as headers so that the Spring filter can see them? Or maybe
>>> a way to make one the user principal, accessible through
>>> javax.servlet.http.HttpServletRequest.getUserPrincipal? Then I could
>>> use a different Spring filter, J2eePreAuthenticatedProcessingFilter).
>>> And if there is a way to do one or both of these, do you think I would
>>> be better off trying to fix this on the Spring side?
>>>
>>>
>>>  You could try setting tomcatAuthentification=3D"false" on your AJP
>> connector
>> in server.xml. If Shibboleth put the value in REMOTE_USER as it should
>> then
>> tomcat should pick it up as the principal.
>> Be aware that you should protect your ajp connector so that no other
>> machine than your Apache can connect to it.
>>
>>
> Cedric,
> I think that the essence of the above is correct, but that strictly
> speaking the details are not.
> I do not think that the authenticated user-id from Apache is passed via
> (or taken from) the REMOTE_USER header.  The mod_jk and mod_proxy_ajp
> modules most probably take the Apache authenticated user-id directly from
> the Apache "request record" (r->user), no matter how it has been set, and
> pass it on to Tomcat throughj AJP as a request attribute.
> The setting of the REMOTE_USER http header is just a side-effect, and may
> be happening or not.
> The AJP connector at the Tomcat level, if tomcatAuthentication=3D"false",
> then uses the value of the received AJP request attribute to set Tomcat's
> request userPrincipal value.
> There is no need then for anything else in Tomcat to grab the REMOTE_USER
> header of the request.
>
>
Yes, I did not mean REMOTE_USER as header but as the environment variable
in apache httpd (I don't know how to call it). I picked it up from this
page  :

https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPJavaInstall

"Setting the tomcatAuthentication=3D"false" attribute on the AJP
<Connector>element allows for passing
REMOTE_USER from Apache httpd. See Tomcat's AJP Connector documentation for
more."


> I do not know Shibboleth, but I would presume that when it authenticates =
a
> user, it sets the Apache r->user first. And then maybe, accessorily and/o=
r
> optionally, Shibbolet may add a REMOTE_USER header to the request.
>
> And at the Tomcat level, one /may/ have some authentication module that
> picks up the user-id from the REMOTE_USER header of the request, and sets
> it as the Tomcat userPrincipal.
>
> But what I mean to say is that both these things with the REMOTE_USER htt=
p
> header are not mandatory.  If Apache httpd authenticates a user, by
> whatever well-written method, the httpd r->user will be set, and the
> proxied AJP request will contain the corresponding user-id.  And if the
> Tomcat AJP <Connector> says tomcatAuthentication=3D"false", then the
> Connector will pick up this user-id from the AJP request attribute, and s=
et
> the Tomcat user to that value.  Independently of any REMOTE_USER header
> being set or not.
>
> Of course you can always override this, and force the usage of the
> REMOTE_USER header on both sides. But why would you do that, if a standar=
d
> mechanism is already built-in into AJP ?
> (It would be different if you were using mod_proxy_http as a connector).
>
>
>

--bcaec50b4bde3ee60604f21e9166--