tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: Do any of the Tomcat LDAP-type realms support "no password" authentication?
Date Sat, 03 Dec 2011 15:40:09 GMT
ohaya@cox.net wrote:
> ---- ohaya@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 ?).


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message