---- 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? Thanks again for hanging in there with me on this! Jim --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
