oh...@cox.net wrote:
---- oh...@cox.net wrote:
---- "André Warnier" <a...@ice-sa.com> wrote:
André Warnier wrote:
oh...@cox.net wrote:
---- oh...@cox.net wrote:
P.S. I forgot to mention:
As you know, I'd been using a sniffer, to see the data on the
Apache-to-Tomcat connection. I have a sniff from earlier, where I
was using "ProxyPass ajp://", and, comparing that sniff vs. a sniff
that I have from when I tested with your suggested <Location>, in the
latter sniff, I can see the userID (testuser), whereas in the former,
that same area in the hex dump is basically just null-terminated
strings.
So, it appears like, when the OAM stuff and the ajp: stuff is in the
Apache .conf, as you were guessing, the userID isn't making it into
the Apache-to-Tomcat/AJP connection at all.
Jim
Hi,
Sorry for the top-post :(...
Here're the sniffs from the tests that I did:
a) Working (OAM disabled, <Location> per Andre):
00000000 12 34 02 AB 02 02 00 08 48 54 54 50 2F 31 2E 31 .4.«....
HTTP/1.1 00000010 00 00 1F 2F 73 61 6D 70 6C 65 73 61 6A 70 2F 73
.../samp lesajp/s 00000020 73 6F 41 4D 54 6F 6D 63 61 74 54 65 73 74
2E 6A soAMTomc atTest.j 00000030 73 70 00 00 0B 31 39 32 2E 31 36
38 2E 30 2E 37 sp...192 .168.0.7 00000040 00 FF FF 00 14 61 70 61
63 68 65 31 2E 77 68 61 .ÿÿ..apa che1.wha 00000050 74 65 76 65 72
2E 63 6F 6D 00 01 BB 01 00 09 A0 tever.co m..»... 00000060 0B 00
14 61 70 61 63 68 65 31 2E 77 68 61 74 65 ...apach e1.whate
00000070 76 65 72 2E 63 6F 6D 00 A0 0E 00 3F 4D 6F 7A 69 ver.com.
..?Mozi 00000080 6C 6C 61 2F 35 2E 30 20 28 57 69 6E 64 6F 77 73
lla/5.0 (Windows 00000090 20 4E 54 20 36 2E 31 3B 20 72 76 3A 38 2E
30 29 NT 6.1; rv:8.0) 000000A0 20 47 65 63 6B 6F 2F 32 30 31 30
30 31 30 31 20 Gecko/2 0100101 000000B0 46 69 72 65 66 6F 78 2F
38 2E 30 00 A0 01 00 3F Firefox/ 8.0. ..? 000000C0 74 65 78 74 2F
68 74 6D 6C 2C 61 70 70 6C 69 63 text/htm l,applic 000000D0 61 74
69 6F 6E 2F 78 68 74 6D 6C 2B 78 6D 6C 2C ation/xh tml+xml,
000000E0 61 70 70 6C 69 63 61 74 69 6F 6E 2F 78 6D 6C 3B applicat
ion/xml; 000000F0 71 3D 30 2E 39 2C 2A 2F 2A 3B 71 3D 30 2E 38 00
q=0.9,*/ *;q=0.8. 00000100 00 0F 41 63 63 65 70 74 2D 4C 61 6E 67 75
61 67 ..Accept -Languag 00000110 65 00 00 0E 65 6E 2D 75 73 2C 65
6E 3B 71 3D 30 e...en-u s,en;q=0 00000120 2E 35 00 00 0F 41 63 63
65 70 74 2D 45 6E 63 6F .5...Acc ept-Enco 00000130 64 69 6E 67 00
00 0D 67 7A 69 70 2C 20 64 65 66 ding...g zip, def 00000140 6C 61
74 65 00 00 0E 41 63 63 65 70 74 2D 43 68 late...A ccept-Ch
00000150 61 72 73 65 74 00 00 1E 49 53 4F 2D 38 38 35 39 arset...
ISO-8859 00000160 2D 31 2C 75 74 66 2D 38 3B 71 3D 30 2E 37 2C 2A
-1,utf-8 ;q=0.7,* 00000170 3B 71 3D 30 2E 37 00 A0 06 00 0A 6B 65 65
70 2D ;q=0.7. ...keep- 00000180 61 6C 69 76 65 00 A0 05 00 1A 42
61 73 69 63 20 alive. . ..Basic 00000190 64 47 56 7A 64 48 56 7A
5A 58 49 36 59 6D 56 7A dGVzdHVz ZXI6YmVz 000001A0 64 44 46 69 00
A0 08 00 01 30 00 03 00 08 74 65 dDFi. .. .0....te 000001B0 73 74
75 73 65 72 00 04 00 05 42 61 73 69 63 00 stuser.. ..Basic.
000001C0 08 00 12 44 48 45 2D 52 53 41 2D 41 45 53 32 35 ...DHE-R
SA-AES25
Yes, this is probably it.
Refer to this to know what you are looking for :
http://tomcat.apache.org/connectors-doc/ajp/ajpv13a.html
The sections "Request Packet Structure", then "Headers" and "Attributes".
We are seeing a HTTP header like this :
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
but since the "Authorization" header is a common one, the name of the
header has been replaced by a code (0xA005).
That looks like the last header, and then starts the attributes part,
where we seem to have indeed these two :
?remote_user 0x03
?auth_type 0x04
(auth_type is "Basic" here, because that is what is configured in the
Apache "AuthType" directive.)
So now disable the Basic Auth, and put the OAM auth instead, and let's
see what happens.
If with OAM, we cannot find the "remote_user" attribute in the packet
trace, then it must mean that OAM is /not/ really authenticating the
user as far as Apache is concerned.
(Meaning, it does not set the user-id where Apache would expect it, it
does its own thing somehow; but maybe in the configuration of OAM, there
exists a parameter to tell OAM to do it right ?).
Addendum:
I browsed a bit on the web, and found some OAM documentation.
According to this :
http://docs.oracle.com/cd/E15217_01/doc.1014/e12493/apch2ihs.htm#CHDFEJCC
(and if I am using the correct documentation)
you should be able to do this :
<Location /sampleajp>
# AuthType Basic
# AuthName "toTomcat"
# AuthUserFile /some-path/passwords
# Require user testuser
# leave these as they are :
SetHandler jakarta-servlet
SetEnv JK_WORKER_NAME tomcatA (<- or whatever name your worker has)
# add the OAM stuff here :
AuthType Oblix
require valid-user
</Location>
Also, according to that, OAM /should/ set the user-id in Apache. Otherwise the "require
valid-user" would not work.
"require valid-user" is a standard Apache directive, and the requirement fulfillment is
checked by Apache; so it must be checking it in its internal request record information;
ergo, OAM must set it.
But maybe I am missing some other OAM parameter somewhere else, which is needd along with
this.
Andre,
I just tried the test you suggested, with just the 4 lines in the <Location>:
SetHandler jakarta-servlet
SetEnv JK_WORKER_NAME tomcatA
AuthType Oblix
require valid-user
and the user is not authenticated in Tomcat. The sniff looks the same as the non-working
one I posted earlier, with nothing in the AJP packet where the "remote_user"
string should be.
If you think about it, this is actually almost exactly where I started, after you had suggested trying AJP tomcatAuthentication, problem-wise.
I totally agree with you that, *LOGICALLY*, it *SHOULD* just work, but it just
DOESN'T, for some reason :(.
I'm almost out of ideas on this one, but I do have a question: To add the OAM webagent
("webgate") into Apache, I add a LoadModule, to load the OAM module.
That normally goes at the end of the httpd.conf, after all the other normal
Apache LoadModules.
I think that the modules are executed in reversed order to what they have in the httpd.conf, so that would mean that the OAM module would be first to execute.
The normal Apache mod_auth, etc. are first in httpd.conf, so that would make
them execute last, after the OAM module.
I haven't tried it yet (just thought about it :)), but I'm going to try to put
the OAM LoadModule above (before) the mod_auth in the httpd.conf, and see if
that makes a difference.
If that doesn't work, then I really am out of ideas...
Will post back...
Jim
Hi,
Well, that (moving the OAM LoadModule before the other LoadModules) didn't make
any difference. It still doesn't work (not authenticate into Tomcat,
remote_user string not populated in AJP buffer).
I think that, at this point, my valve, which does work ok, is probably the only
alternative?
I did not expect that changing the order of loading of the modules would make a
difference. This is an authentication module, and those get called pretty early in the
cycle, before the content-generating modules. And not all get called, just the one
configured for the scope (here, the <Location>).
I am also about out of my wits.
Obviously, the OAM scheme is not setting the internal Apache user-id.
Maybe it never does, or maybe there is some required OAM setup parameter that
we don't know.
Now let me ask another question :
Why do you need to authenticate the user at the Apache level, and pass this user-id to
Tomcat ?
Obviously, from the OAM documentation I scanned, there must exist an OAM module directly
for Tomcat, to authenticate users there. Why are you not using that ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
