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

Reply via email to