---- "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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
