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 Fri, 02 Dec 2011 20:19:01 GMT
ohaya@cox.net wrote:
> ---- Christopher Schultz <chris@christopherschultz.net> wrote: 

Chris, you managed to confuse the guy..

...

> To be clear, in the discussion before now, I was just using mod_ajp 

and that was a perfectly valid way to connect Apache to Tomcat.

...


> 
> I'm now in the process of trying to switch my Apache conf to use mod_jk.  

Aaaah. Why did you do that ?
Not that it is not /also/ a valid way to connect Apache to Tomcat, but both are pretty 
much equivalent, and now you're starting a whole new bag of possible complications.

> The reason is that I'm starting to get the feeling that the Apache 3rd party agent
(it's Oracle's OAM webgate, which I haven't said till now, sorry) might not be setting
things in the Apache environment that are needed for AJP.

Well, in that case it won't be doing it for mod_jk either, because mod_jk and 
mod_proxy_ajp use exactly the same protocol (AJP) to talk to Tomcat.  That's because they

are both talking to the same <Connector protocol="AJP"> in Tomcat, so of course they
have 
to speak the same dialect.

I hope you saved your prior configuration..


...
skipping a whole big chunk
...

> 
> 
> Shouldn't the one "JkMount /samplesajp/*" that I have be enough to proxy through the
mod_jk?
>
Yes it should, if used in the right place.
But maybe you are using <VirtualHost> sections, in which case the JkMount directive
might 
not be in the right place.


> Also, why is it appearing to try to process the "/oam/..." URIs?
> 
That is because, to Apache, mod_jk is a "content handler" or "response handler".
Apache doesn't know that Tomcat even exists.
When Apache gets a request, it processes it in a series of steps, of which the response 
generation is one of the last.
Apache will "pass" the request to all registered response-generating modules which are 
(potentially) applicable for this request, one after the other.
Each such module gets a chance to look at the request and decide if it is for him or not.
If it decides not, then it returns a "declined" response to Apache, and Apache passes the

request to the next response-generating module in the chain.
The first response-generator in the chain which decides "hey, this is for me", generates 
the appropriate response, and returns an "ok" response to Apache.
Then Apache knows that the response was generated, and that it does not need to call the 
next module in the chain anymore.

mod_jk is such a response handler, so it gets /every/ request that Apache processes, and 
it can decide if it wants to take it or not.
It does this by examining the URI, and deciding if it matches one of the entries in its 
URI mapping table (the one it built from the JkMount directives).
That's what you see in the log.
If it decides that the URI does not match (as in the case of that /oam/ URI), it 
immediately returns a "declined" response to Apache, and Apache will call the next 
possible response handler.
If it decides that it does match one of the entries in its table, then mod_jk will 
"generate the response" for that request (and let Apache know later that it did).

But mod_jk is a cheat.
It does not really generate a response itself. Behind the scenes (and unknown to Apache),

it slily passes the request to the back-end Tomcat (via AJP), and lets Tomcat do the work.
And when Tomcat sends back a response, mod_jk presents it to Apache as if it has produced

it all by itself, and Apache is none the wiser.

Now since I have berated poor mod_jk, I should mention that any other proxy module (like 
mod_proxy_http or mod_proxy_ajp) does exactly the same.
They get to have a peek at any Apache request (at least any that falls into their "scope",

be that the whole <VirtualHost> or just a <Location>), and they decide if they
want to 
handle it or not.
(This is a difference between Apache and Tomcat : in Tomcat, it is Tomcat which does the 
work of matching a request to a webapp; in Apache, it is the modules who do that work).


So now that this is out of the way, let's get back to the core of the issue.
You wanted to pass the Apache authenticated user-id to Tomcat, right ?

And we have not yet established, but pretty much guessed, that this should happen via a 
"request attribute" within the AJP protocol exchange between Apache (via mod_proxy_ajp OR

mod_jk) and Tomcat, said request attribute being very likely to be the one named 
"remote_user" (lowercase). (And if not, one would be allowed to wonder what this AJP 
request attribute might be for).

And Apache has a different terminology, and what AJP and Tomcat call "request attributes",

Apache seems to name "server variables" or "environment variables", depending on where you

look.

And in any case, as you have yourself established, it seems that Tomcat is pretty much 
ignoring the HTTP header "REMOTE_USER" that you have set, at least for any purpose of 
authentication.

So the whole point is, how do you set this Apache server or environment variable within 
Apache, before the request gets proxied to Tomcat ?
And how do you insure that mod_jk or mod_proxy_ajp really picks up that value, to pass it

to Tomcat ?



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


Mime
View raw message