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 ---- oh...@cox.net wrote: > > ---- oh...@cox.net wrote: > > > > ---- "André Warnier" <a...@ice-sa.com> wrote: > > > oh...@cox.net wrote: > > > > ---- "André Warnier" <a...@ice-sa.com> wrote: > > > >> oh...@cox.net wrote: > > > >> > > > >> .. re-synchronising.. > > > >>> I've made some progress. I have a VirtualHost, so I had to add a > > > >>> "JkMountCopy 'on'" inside the <VirtualHost>, and now, it's at least > > > >>> proxying through to the Tomcat using mod_jk!! > > > >>> > > > >>> BUT, it's still not logging me into the Tomcat :(... > > > >>> > > > >>> I don't want to post the entire jk.log, so can someone point me to > > > >>> what to look for in there, maybe? > > > >>> > > > >> Ok, so let's now continue on the mod_jk track, since you've got that > > > >> part running. > > > >> > > > >> What you are looking for, is an AJP "request attribute" named > > > >> "remote_user" (lowercase), > > > >> in the packets which mod_jk sends to Tomcat. > > > >> I don't know if that would be in the log, nor if there is any way to > > > >> coerce mod_jk into > > > >> putting it in the log. > > > >> > > > >> But since your Tomcat is not authenticating, chances are that it isn't > > > >> there. > > > >> > > > >> So let's try to cheat, and force it to be there. > > > >> In your Apache configuration, add this line : > > > >> > > > >> JkEnvVar remote_user "blablabla" > > > >> > > > >> and let's see what happens. > > > >> > > > >> > > > >> (and after that, we'll try mod_rewrite or a combination) > > > >> > > > > > > > > > > > > Andre, > > > > > > > > I had already tried including a "JkEnvVar" as you suggested in my > > > > httpd.conf, in order to try to hard-code getting SOMETHING to show up, > > > > but no joy :(... > > > > > > > > I've also tried a bunch of other variants: > > > > > > > > JkEnvVar REMOTE_USER > > > > > > > > also: > > > > > > > > JkEnvVar remote_user "foobar" > > > > > > > > also: > > > > > > > > JkEnvVar AJP_REMOTE_USER "foobar" > > > > > > > > Nothing works :(... > > > > > > > > This is really getting discouraging :(. It almost seems to me like > > > > that 'tomcatAuthentication' functionality doesn't even exist at all. > > > > > > > > I've searched the jk.log for multiple things, "attr", "remo", etc., and > > > > find nothing relevant/significant at all in there... > > > > > > > > > > Do not get discouraged. I can guarantee that the > > > tomcatAuthentication="false" works, when > > > the Apache front-end really does authenticate the user. I use this all > > > the time. > > > (Just not with the same SSO mechanism as you). > > > > > > I also know that "JkEnvVar" does work in general for setting request > > > attributes at the > > > Apache level, and have them passed to Tomcat by mod_jk, because I also us > > > that regularly. > > > (And there exists a similar functionality in mod_proxy_ajp). > > > > > > What may not work in the trials above, is that specifically this > > > "remote_user" request > > > attribute may be overwritten by mod_jk or mod_proxy_ajp, even when you > > > have set it > > > explicitly in Apache. > > > > > > After all, this feature is designed to do one thing : examine the > > > "request record" of > > > Apache for an authenticated user-id, and if one is set, pass it along to > > > Tomcat over the > > > AJP channel. If mod_jk/mod_proxy_ajp do not find such a user-id in the > > > request record, > > > they may just /clear/ the remote_user attribute, thus voiding our > > > attempts at cheating. > > > > > > To verify this is relatively simple. > > > Create the following <Location> section in Apache : > > > > > > <Location /sampleajp> > > > AuthType Basic > > > AuthName "toTomcat" > > > AuthUserFile /some-path/passwords > > > Require user testuser > > > SetHandler jakarta-servlet > > > SetEnv JK_WORKER_NAME tomcatA (<- or whatever name your worker has) > > > <Location> > > > > > > Note: the SetHandler and SetEnv lines above, in that <Location>, are > > > equivalent to saying : > > > JkMount /sampleajp/* tomcatA > > > > > > Then follow the instructions here to create the password file and the > > > user "testuser" in it : > > > http://httpd.apache.org/docs/2.2/howto/auth.html > > > section : Getting it working > > > > > > If you try to access such a URL "/sampleajp/*", the browser will popup a > > > bssic auth dialog > > > and force you to login. > > > This will result in the request being duly authenticated for Apache, > > > which /will/ result > > > in the Apache user-id being passed to Tomcat. > > > > > > Then, once you have verified (in Tomcat) that it is so, have another look > > > at the mod_jk > > > logfile, to see if then you spot the attribute being passed. > > > (You will know that it is passed, but it may still not show up the logs). > > > > > > If all of that works, then we know that in order for your scheme to work, > > > you must somehow > > > force the user-id obtained by your SSO system, to be also set in the > > > Apache request > > > record. Which should be a solvable problem. > > > > > > And if not, then you still have your Valve.. > > > > > > > > > Andre, > > > > I haven't tried your full suggestion yet, but I removed all of the OAM SSO > > stuff out of my Apache httpd.conf, just to see what happens, but even after > > that, still am not getting logged into Tomcat, so it may be as you suggest, > > that mod_jk tries to get the userid from somewhere deep inside of Apache. > > > > So, I will try adding what you suggested, to get authenticated with just > > the Apache, and then see what happens, and will post back. If that works, > > we can go from there. > > > > Thanks for following up with this! > > > > Jim > > > > > > Hi Andre, > > I configured the <Location> as you suggested, and guess what? > > It WORKS! > > That was good, BUT, recall that I had removed the OAM stuff from the Apache > .conf earlier. > > So, after confirming that, without the OAM stuff, and with your suggested > <Location>, that it worked, I then went and uncommented the OAM stuff, i.e., > added back the OAM agent. > > Then, I tested going to the /samplesajp again, and I kept getting connection > closed, i.e., accessing the app on the Tomcat no longer worked. > > So, it appears that, somehow, not only is having the OAM configuration > enabled causing the tomcatAuthentication to not work, but the OAM > authentication stuff is also interfering with the basic Apache authentication > stuff, to the point that the latter fails. > > I'm not sure where to go with this at this point. I know, as you said, that > the original valve approach does appear to work. I'd really like to get > AJP/JK working, but the valve may be the only viable approach :(... > > I'd be interested in your thoughts (or anyone else's) at this point. I'll > spend a bit more time trying to tweak some stuff with both the OAM and > AJP/JK, but I'm not optimistic that I know enough to make any further > progress on this path. > > Thanks again, > Jim > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
