Hi Andre (and Christopher and Olaf),
I think that that is a good summary of where this is at this point.
Thanks!
Jim
On Saturday, May 16, 2020, 08:23:54 AM EDT, André Warnier (tomcat/perl)
<a...@ice-sa.com> wrote:
In summary, yes, I think you're right in your final conclusion below.
If the tomcat access log shows the authenticated user, it means that tomcat got
it, and I
see no other way than from Apache and through that "tomcatAuthentication=false"
option of
the tomcat AJP connector.
And that in turn means that, for Apache, this request was authenticated, which
in turn
means that OAM /did/ also set the Apache-internal R->user variable.
The values printed by your Apache cgi-bin script are maybe a bit confusing
regarding what
is going on, because they are the result of a different (and parallel) process
: when
Apache runs a cgi-bin script, it does this in a separate child process, and
when it
creates this process, it provides it with an environment. And that is what your
cgi-bin
script is showing (it's own environment values).
That in this environment, Apache creates a "remote-user" variable and populates
it with
the Apache authenticated user-id, is fortuitous but unrelated to the fact that
Apache+mod_proxy_ajp *also* passes this authenticated user-id via AJP to tomcat.
So now indeed, you have to figure out why this tomcat webapp wants the browser
to retrieve
a login page, despite the fact that this access is already authenticated.
But indeed this is no longer an Apache or a tomcat or tomcat Connector issue,
it is a
webapp logic or configuration issue.
On 16.05.2020 08:40, ohaya wrote:
> Hi,
>
> When I configure the OAM protection, they have the ability to configure
> values that go into HTTP headers (among other things) upon successful
> authentication (to OAM).
>
> I usually test this by protecting /cgi-bin/printenv on the Apache. printenv
> has this :
>
> ##
> ## printenv -- demo CGI program which just prints its environment
> ##
> use strict;
> use warnings;
>
> print "Content-type: text/plain; charset=iso-8859-1\n\n";
> foreach my $var (sort(keys(%ENV))) {
> my $val = $ENV{$var};
> $val =~ s|\n|\\n|g;
> $val =~ s|"|\\"|g;
> print "${var}=\"${val}\"\n";
>
> and when do that test, it does dump out remote_user (among others).
>
> Also FYI, I was just looking at the Tomcat localhost_access_log.<date>.txt
> file, and I am seeing lines like:
>
> xx.0.xx.xx - <remote_user_value> [16/May/2020:06:18:41 +0000] "GET /xxx/login
> HTTP/1.1" 302 -
>
> where <remote_user_value> is the username of the user that authenticated to
> OAM.
>
> I am not 100% about the format of that log, but does that line say that
> Tomcat thinks that the user that is logged INTO TOMCAT is that
> <remote_user_value>?
>
> If so, then does that mean that I am already passing that user from Apache
> into Tomcat successfully?
>
> If so, I have thinking that maybe the webapp that I am trying to get logged
> into (it is Apache Syncope) is not leveraging the authentication mechanisms
> that are inbuilt in Tomcat?
>
> That kind of makes sense, because I know that I didn't have to add that user
> to the tomcat-users.xml.
>
> Finally if that is the case, this is no longer just a Tomcat-related issue.
>
> Jim
>
>
> On Friday, May 15, 2020, 09:38:19 AM EDT, Christopher Schultz
><ch...@christopherschultz.net> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Jim,
>
> On 5/15/20 08:42, ohaya wrote:
>> Yes, I am using Oracle Access Manager (OAM) so we have what they
>> call an "OAM webgate" that is integrated with the Apache. That
>> webgate automatically populates an HTTP header named "remote_user"
>> with the user that OAM authenticated.
>>
>> So the problem I having is trying to figure out how to "integrate"
>> that with Tomcat.
>
> Okay.
>
>> So we have:
>>
>> Browser <==> Apache+webgate <==> Tomcat (webapp)
>
> Good.
>
> First thing's first: Do you get your pages from Tomcat, but you aren't
> authenticated, or do you get some other kind of error? Sounds like you
> see your application, just no authentication.
>
> If this is your first time doing this, I assume you mean you're trying
> to figure out how to get it done, not trying to move a working
> configuration from another environment./version to Tomcat 9, right?
>
> There is nothing in the configuration you have posted so far that
> leads me to believe you'll be sending any REMOTE_USER HTTP header to
> Tomcat. Apache httpd doesn't (usually) auto-forward anything to
> Tomcat. Your OAS module is more likely setting an environment variable
> (remote_user) than an HTTP header. But it might be setting a header.
> That would be good information to know.
>
> To send arbitrary headers (etc.) to Tomcat via mod_proxy_ajp, you need
> to configuration to do that. Let's take a look at the Tomcat
> documentation to see how tomcatAuthentication="false" works.
>
> Awesome, the documentation says nothing about how to tie-into it.
> Well, the code says that tomcatAuthentication="false" means that AJP
> can accept the REMOTE_USER /request attribute/ which is a special
> servlet-thing which isn't the same as a header. So you have to arrange
> for mod_proxy_ajp to send your "remote_user" (header or environment
> variable) to Tomcat as a request attribute.
>
> Here's how to do that. According to the mod_proxy_ajp docs:
>
> "
> Environment Variables
>
> Environment variables whose names have the prefix AJP_ are forwarded
> to the origin server as AJP request attributes (with the AJP_ prefix
> removed from the name of the key).
> "
>
> Cool, so we just need to set an environment variable AJP_REMOTE_USER
> and it will be sent as an attribute. So I think we have all the
> pieces, now. So try this:
>
> # Copy OAS's REMOTE_USER env variable -> AJP_REMOTE_USER for Tomcat
> SetEnv AJP_REMOTE_USER "%{REMOTE_USER}e"
>
> Just before your ProxyPass and friends.
>
> I'm not entirely sure that will work. SetEnv doesn't say what "value"
> can be; I'm hoping it will see that token and understand it's an
> environment variable.
>
> If that works, you're all set. Another option would be to tell OAS
> that the environment variable you want is actually AJP_REMOTE_USER,
> but if you want to use the environment variable "remote_user" for
> other things, maybe making a copy like this is a better idea.
>
> If that doesn't work, it may be that OAS is really setting an HTTP
> header, which would be weird but, hey, Oracle is weird.
>
> If you have to deal with HTTP headers, you'll want to do this:
>
> # Disallow any random client from masquerading as any user
> RequestHeader unset REMOTE_USER early
> # Copy OAS's REMOTE_USER header -> AJP_REMOTE_USER for Tomcat
> SetEnv AJP_REMOTE_USER "%{REMOTE_USER}"
>
> Note the lack of a trailing "e" on the value of the environment variable
> ..
>
> Hope that helps,
> - -chris
>
> PS It looks like there's some room to improve Tomcat's documentation
> of the "tomcatAuthentication" configuration attribute.
>
>> On Friday, May 15, 2020, 08:36:18 AM EDT, André Warnier
>> (tomcat/perl) <a...@ice-sa.com> wrote:
>>
>> Let me give my 5 cent.
>>
>> In the tomcat AJP Connector Tomcat, you use the
>> tomcatAuthentication attribute :
>>
>> <Connector port="8009" protocol="AJP/1.3" redirectPort="8443"
>> tomcatAuthentication="false"/>
>>
>> This setting has the effect that tomcat will "believe" the
>> authenticated user-id that Apache is passing to it in the AJP
>> protocol messages that Apache sends to tomcat, and not try to
>> re-authenticate again at the tomcat level. (Note : this is not
>> done by a "REMOTE_USER" HTTP header added by Apache; it happens via
>> some internal variable specific to the AJP protocol).
>>
>> Of course, for this, the request needs to be first authenticated
>> in Apache (so that it has a user-id to pass to tomcat).
>>
>> So do you have anything at the Apache httpd side, which
>> authenticates the user before the request gets passed to tomcat
>> (via AJP) ?
>>
>>
>>
>>
>> On 15.05.2020 14:08, ohaya wrote:
>>> Hi Olaf,
>>>
>>> Thanks. I do appreciate that! I will do more digging.
>>>
>>> Jim
>>>
>>>
>>> On Friday, May 15, 2020, 07:41:50 AM EDT, Olaf Kock
>>> <tom...@olafkock.de> wrote:
>>>
>>>
>>> On 15.05.20 13:23, ohaya wrote:
>>>> Hi,
>>>>
>>>> I just tried adding the secret to the Apache side:
>>>>
>>>> ProxyPass ajp://192.168.218.XXX:8009 secret="123"
>>>> ProxyPassReverse ajp://192.168.218.XXX:8009 secret="123"
>>>>
>>>> and I get an error when I try to start Apache:
>>>>
>>>> AH00526: Syntax error on line 554 of
>>>> /apps/oracle/apache/conf/httpd.conf: ProxyPass unknown Worker
>>>> parameter
>>>>
>>>> I am currently using Apache 2.4.39. Is there another way to
>>>> specify the "secret"?
>>>
>>> With 9.0.20 you do not yet need to pass a secret - that came
>>> along later (somewhere around 30-33 AFAIR). However, you'll need
>>> to make sure that your AJP port is only available for the reverse
>>> proxy and nobody else - there was a recent security disclosure,
>>> which led to the change of many default settings for the AJP
>>> connector in the current releases.
>>>
>>> It boils down to the last sentence of my previous answer: I've
>>> never used REMOTE_USER headers for authentication, and there's
>>> no indicator in your setup that you're allowing Tomcat to trust
>>> such a header. I might be completely off here, but as nobody else
>>> answered yet, I thought I'd give it a try.
>>>
>>> Olaf
>>>
>>>> Thanks, Jim
>>>>
>>>>
>>>> On Friday, May 15, 2020, 07:04:44 AM EDT, ohaya
>>>> <oh...@yahoo.com.invalid> wrote:
>>>>
>>>> Hi,
>>>>
>>>> The Tomcat version I am using is 9.0.20. I will take a look at
>>>> the changelog.
>>>>
>>>> This is the first time I have tried this, and I couldn't find
>>>> much info, so I appreciate the feedback. I will look for info
>>>> about "secret".
>>>>
>>>> I wasn't sure about the format on the Apache side for the
>>>> ProxyPass/ProxyPassReverse - does what I posted look all
>>>> right?
>>>>
>>>> Also, when I was searching around for info, I saw some
>>>> comments that seem to be saying that the "tomcatAuthentication"
>>>> parameter on the Tomcat connection was no longer supported or
>>>> something like that?
>>>>
>>>> Also re. "secret" on the Tomcat side: If that is set to, for
>>>> example, "mysecret", how do I pass that on the Apache side?
>>>>
>>>> Thanks again, Jim
>>>>
>>>>
>>>> On Friday, May 15, 2020, 03:33:19 AM EDT, Olaf Kock
>>>> <tom...@olafkock.de> wrote:
>>>>
>>>>
>>>> On 15.05.20 09:06, oh...@yahoo.com.INVALID wrote:
>>>>> Hi,
>>>>>
>>>>> I am using an Apache proxy in front of Tomcat 9, and I am
>>>>> using AJP connection to connect from the Apache to Tomcat,
>>>>> and I have the Apache sending a username to the Tomcat in a
>>>>> REMOTE_USER header.
>>>>>
>>>>> In the Tomcat server.xml I have:
>>>>>
>>>>> <Connector port="8009" protocol="AJP/1.3"
>>>>> redirectPort="8443" tomcatAuthentication="false"/>
>>>>>
>>>>> In the Apache httpd.conf, to test, this I have:
>>>>>
>>>>> <LocationMatch /myapp*> ProxyPass ajp://192.168.218.XX:8009
>>>>> ProxyPassReverse ajp://192.168.XX.224:8009 </LocationMatch>
>>>>>
>>>>> But when I access the app via the Apache, it is not
>>>>> automatically logging me into the app.
>>>>>
>>>>> Is there anything else that I have to do to get this to work
>>>>> besides what I did above? Is there something that I have to
>>>>> modify in the app itself to get this to work?
>>>> Hi Jim,
>>>>
>>>> which exact version of Tomcat 9 are you using? Note that there
>>>> were significant changes for the default and required
>>>> configuration for the AJP connector, in order to use it. Best
>>>> to find all of them: Search for AJP in the change log
>>>> tomcat.apache.org/tomcat-9.0-doc/changelog.html
>>>>
>>>> Notable among them: Everything to do with "secret", and the
>>>> default bind address, "localhost", for the AJP connector. i.e.
>>>> I'd expect this configuration to be insufficient for any of
>>>> the latest releases.
>>>>
>>>> I haven't ever used this REMOTE_USER authentication, but
>>>> nothing in the configuration that you've posted gives any clue
>>>> about what you do and what you send. I would expect Tomcat to
>>>> *not* blindly accept any REMOTE_USER header by default, unless
>>>> it's whitelisted and explicitly asked for - it otherwise would
>>>> be a great way to exploit servers that don't have a remote
>>>> proxy (or one where the remote proxy is configured to remove
>>>> this header). Nothing in the configuration you post gives me a
>>>> hint about what you do to make tomcat accept and trust this
>>>> header.
>>>>
>>>> Olaf
>>>>
>>>>
>>>>
>>>> --------------------------------------------------------------------
> - -
>>>>
>>>>
>>>>
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>>
>>>
>>>
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>>
>>
>>
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>>
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6+mzgACgkQHPApP6U8
> pFinaBAArCzDTK3JcIq2xZu4S/BTwESRLCAmnA8p53RgcafKclFucFeM1uC8dCMv
> CNKZBsKv0Nf2GrmQSdAGYKZAY17Bp0VHEUNiWdKMbX8r7QcR0tWhJL9sx5a2nLBh
> nhjWJSXzwj9dC49dW/LjI9Xkdbo3mzcXIm5J+mlYAseqmnRWU8ISY+MpQh/Qys37
> 1dteYPpdHuwMzqoB8EF+aq69xTuVM/Z2+EkGthxtk0LmW1BYAlbKubaOjV58bzG2
> 0YOH6BfadWlvWRsIruF1Gc6DTeWBOdcMANHoHYOTRM9Wbn1Y8D62EnlXQwsImVlf
> EIEhPN57fQkutgxfJjFb/wHGORPT6z+6icr4ja1u9JNYuLuUH+yjusB2HDxiHal9
> EaBF2wmHivqxOx5yEVWRWz2BPWUZ/+lG7bionhXM6o59VjRS0/FkxthTBR+FHMlN
> B/j7nMXfrobblGbZfFeUjvJJCwG+a2SnO44r6TERisdAQDvVqRd2E7M+RKIywAgX
> hjYC9Xl/Kg83u4WS5iHmzvKPGmdQB+R4UYMwchn74+A6sWnddeDIT4tr7ga0adqu
> deLowaV7JfrbZiDNZ1AjatBCGyOmSmwrhLZmiS03BImgLWqkNrygnOaKxX/amJO3
> zWRYTyN/gs7IWuLHDDvslbwabqLFuyhD5loiPo11FS1+iGOJJRc=
> =t7ee
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
