You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by oh...@cox.net on 2011/12/01 00:25:01 UTC
Do any of the Tomcat LDAP-type realms support "no password"
authentication?
Hi,
I'm new here, and hope that someone can help.
I was wondering if any of the LDAP-type realms (e.g., JNDIRealm, etc.) support an authentication mode where no password or credentials are required? In other words, where just a userID/username is presented, and if that userID/username is present in the LDAP, then the user gets authenticated?
Thanks,
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password" authentication?
Posted by Marvin Addison <ma...@gmail.com>.
> I was wondering if any of the LDAP-type realms (e.g., JNDIRealm, etc.) support an authentication mode where no password or credentials are required?
It's hard to imagine a valid use case for this -- I hope you know what
you're doing. That said, you could use JAASRealm with
http://code.google.com/p/vt-middleware/source/browse/vt-ldap/tags/vt-ldap-3.3.4/src/main/java/edu/vt/middleware/ldap/jaas/LdapDnAuthorizationModule.java
to accomplish this. I should note that the intention is for
LdapDnAuthorizationModule to be combined with another module that
actually performs authentication (e.g. bind or compare), but you could
abuse it for your use case I believe.
M
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password"
authentication?
Posted by oh...@cox.net.
---- Mark Thomas <ma...@apache.org> wrote:
> On 01/12/2011 18:17, ohaya@cox.net wrote:
> > Having said all of that, I guess that my question has changed
> > somewhat. Specifically, now I'm wondering: With what I described
> > above, and with my valve as described above, does the asserted user
> > NOT have to be in the Tomcat realm at all?
>
> Correct. If you populate the user Principal, Tomcat doesn't care whether
> or not it is in the Realm.
>
> Mark
>
Hi Mark,
See my response to Andre's last msg. If you happen to be able to pinpoint that thread that he mentions about this, I'd really like to look at it.
Thanks,
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password" authentication?
Posted by Mark Thomas <ma...@apache.org>.
On 01/12/2011 18:17, ohaya@cox.net wrote:
> Having said all of that, I guess that my question has changed
> somewhat. Specifically, now I'm wondering: With what I described
> above, and with my valve as described above, does the asserted user
> NOT have to be in the Tomcat realm at all?
Correct. If you populate the user Principal, Tomcat doesn't care whether
or not it is in the Realm.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password" authentication?
Posted by André Warnier <aw...@ice-sa.com>.
ohaya@cox.net wrote:
> ---- Christopher Schultz <ch...@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
Re: Do any of the Tomcat LDAP-type realms support "no password" authentication?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jim,
On 12/2/11 2:08 PM, ohaya@cox.net wrote:
> ---- Christopher Schultz <ch...@christopherschultz.net> wrote:
>>
>> See
>> http://tomcat.apache.org/connectors-doc/reference/apache.html.
>> Specifically, the JkRemoteUserIndicator directive which allows
>> you to override the environment variable whose value will be used
>> to send-over the username to Tomcat.
>
> FYI, that link you posted give as 404 error.
WFM... ??!
> To be clear, in the discussion before now, I was just using
> mod_ajp (built into/included with Apache), and NOT mod_jk.
That's mod_proxy_ajp, but I understand. I believe they both provide
that capability, but I'm not sure... the documentation for
mod_proxy_ajp is sorely lacking.
> I'm now in the process of trying to switch my Apache conf to use
> mod_jk. 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. I've been checking, and
> there's very little (= none) that I can do with trying to change
> the OAM webgate behavior, and if it's not setting whatever
> Apache/AJP needs, then I'm stuck, so I'm trying mod_jk, hoping that
> that'll give me some way to set what AJP needs.
mod_jk definitely has a lot more capabilities than mod_proxy_ajp. I
have only ever used mod_jk for historical reasons (project predates
mod_proxy_ajp) and because we can't do certain things with
mod_proxy_ajp and actually require mod_jk at this point.
Fortunately, mod_jk isn't tough configure -- though mod_proxy_ajp can
do a lot with tro simple directives :)
> # 2011-12-02 - ADDING MOD_JK LoadModule jk_module
> modules/mod_jk.so JkWorkersFile
> c:/Apache2.2/conf/workers.properties # some other configuration
> JkLogFile "c:/Apache2.2/logs/jk.log" JkLogLevel debug JkShmFile
> c:/Apache2.2/logs/jk.shm JkOptions +ForwardKeySize
> +ForwardURICompat -ForwardDirectories # forwarding URL prefixes to
> Tomcat instances JkMount /samplesajp/* tomcatA
Do you have any VirtualHosts? If so, the JkMounts at the top-level
won't be copied-into the VirtualHosts unless you use another special
directive: JkMountCopy.
> JkEnvVar REMOTE_USER
This will put the REMOTE_USER environment variable (on the httpd side)
into the request /attributes/ on the Tomcat side.
> And, here's the workers.properties:
>
>
> <IfModule mod_jk.c>
^^ That's not appropriate in workers.properties. If mod_jk isn't
loaded, this file won't be loaded, either.
> # a list of Tomcat instances #JkWorkerProperty worker.list=tomcatA
> worker.list=tomcatA # connection properties to instance A on
> localhost # JkWorkerProperty worker.tomcatA.type=ajp13 #
> JkWorkerProperty worker.tomcatA.host=weblogic1.whatever.com #
> JkWorkerProperty worker.tomcatA.port=8009
> worker.tomcatA.type=ajp13
> worker.tomcatA.host=weblogic1.whatever.com
> worker.tomcatA.port=8009
All that looks just fine to me.
> And, here's what I'm seeing in jk.log when I try to access my test
> URL (via the Apache): [...] [Fri Dec 02 14:04:50.022 2011]
> [744:560] [debug] jk_translate::mod_jk.c (3488): missing uri map
> for apache1.whatever.com:/samplesajp/ssoAMTomcatTest.jsp [Fri Dec
> 02 14:04:50.022 2011] [744:560] [debug] jk_map_to_storage::mod_jk.c
> (3647): missing uri map for
> apache1.whatever.com:/samplesajp/ssoAMTomcatTest.jsp
That certainly looks like you don't have any JkMounts in your
VirtualHost. Try using JkMountCopy (if you want to be lazy) or move
your JkMount directives into the <VirtualHost> that you are using.
> Shouldn't the one "JkMount /samplesajp/*" that I have be enough to
> proxy through the mod_jk?
>
> Also, why is it appearing to try to process the "/oam/..." URIs?
mod_jk has to consider all URIs to determine if it's going to forward
them. In that case, it wouldn't have forwarded to Tomcat because it
wouldn't have matched any JkMount directive.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7ZNGcACgkQ9CaO5/Lv0PBesgCbBFKtc3b2FQyfZBt9hlRwa3BA
9PYAoKF8KB6OuZDSovKDQmt03t5ilfPx
=67UA
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password" authentication?
Posted by André Warnier <aw...@ice-sa.com>.
ohaya@cox.net wrote:
> ---- ohaya@cox.net wrote:
>> ---- "André Warnier" <aw...@ice-sa.com> wrote:
>>> ohaya@cox.net wrote:
>>>> ---- "André Warnier" <aw...@ice-sa.com> wrote:
>>>>> ohaya@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.
>
Well, you should have one OR the other, not both.
Comment-out the Basic authentication stuff, as below, and /then/ add your OAM stuff inside
the location instead.
<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 :
</Location>
(and show us an example of the OAM setup , passwords etc. removed of course)
(Maybe also, if you have a pointer to some documentation explaining the OAM setup, that
may be helpful too).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password" authentication?
Posted by André Warnier <aw...@ice-sa.com>.
ohaya@cox.net wrote:
> ---- "Caldarale wrote:
>>> From: ohaya@cox.net [mailto:ohaya@cox.net]
>>> Subject: Re: Do any of the Tomcat LDAP-type realms support "no password" authentication?
>>> In other words, even though my valve code can assert a user
>>> into Tomcat, and even if that same user already exists in the
>>> Tomcat realm, the asserted user seems to be 'disassociated'
>>> from the same user in the Tomcat realm?
>> Need to get some terminology correct here. A Realm does not normally contain users, roles, or any other authentication or authorization _data_; rather, it is a Java class that embodies rules for examining the credentials supplied by a login attempt and comparing them to credentials and roles stored in some external location. By default (and never meant to be used in production), the external location is the file tomcat-users.xml, and the Realm is UserDatabaseRealm (augmented by LockOutRealm to discourage probing). Several other Realm classes are supplied with Tomcat, to allow access to credentials from LDAP servers, relational databases, JAAS, etc.
>>
>> I think what you need is essentially a Realm that does no authentication of its own (trusting httpd to do that), but does perform the authorization function. It can then map the userid to whatever set of roles are appropriate for that user, and return the appropriate response when queried. See the doc for details:
>>
>> http://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html
>>
>> It would seem likely that someone out there has written a Realm that performs the above functions in conjunction with httpd authentication. (Note: you keep using the word "Apache" - which is a software organization with many products - when you're referring to httpd, a specific Apache product, as is Tomcat.)
>>
>> - Chuck
>>
>
>
> Hi Chuck,
>
> Corrections understood, and I'll try to be more careful. As you point out, and as I mentioned earlier in the thread, it seems like I've come all the way around to the original subject "...Tomcat LDAP-type realms support "no password" authentication?".
>
> I've been and still am looking around for something like that, but haven't found it yet.
>
> I'm still puzzled by something though. Even if I did find (or implement) a realm that was a "no password realm", how do I tie the two pieces that I end up with, the valve and the no-password realm, together?
>
> In other words, I can pull the userID from the incoming header in the valve, but then I think that the valve code then needs to authenticate against the no-password realm. Is that correct?
>
> And, if so, how to do that?
>
> I've been looking for a way (API?) to programmatically "authenticate the user" against Tomcat, so that I could add that into my valve code, but haven't been find anything yet.
>
I am answering here, but it also follows-up on other previous messages to the list, to try
and keep this manageable.
I believe that now you have reached a fundamental issue which you need to resolve first,
before looking at the technical details of how to do it.
The basic issue - and I may not be expressing this entirely using the correct terms - is
that the notion of "role" is somewhat specific to the Java servlet world, and it does not
entirely match what in other "scopes" is called a "user attribute" and in yet other scopes
is called a "user group", or even "privileges" for users and/or groups.
I don't know how OAM works, nor on what kind of concept among the above its "permissions"
(to use yet another related concept) are based.
But in your case, to be entirely consistent, you would have to do the following :
After the user is /authenticated/ (meaning that you just have a user-id which you can
trust), comes the /authorization/ part. That is, the user wants to access this webapp in
Tomcat; is he allowed to do that ?
And to be consistent, you would have to ask OAM. And OAM would answer yes or no, on the
base of information that OAM has, and Tomcat doesn't.
Because if you do otherwise, then you are going to find yourself obliged to duplicate
under Tomcat a whole management of "roles" and keep them in sync with whatever back-end
OAM uses to determine this.
To be more explicit : suppose you protect an application by Tomcat's declarative style of
security, and in the web.xml of that application, you indicate that this application can
only be used by users which have the "roleX" in their list of roles.
Then whenever a user tries to access the application, Tomcat will make a "isUserInRole"
call, to find out if the current user has the role "roleX".
And for that, Tomcat will need a Realm, and this Realm will need a back-end which it can
check to answer that question. And if this back-end is independent from the OAM system,
then somehow you will have to keep it synchronised. Because tomorrow the user can be
promoted or demoted, and not have access to this application anymore, and this will be
managed by the people who manage the users in the OAM system.
And you may also need a translation table, because what in your application's web.xml is
named as "roleX", may translate in OAM terms to something rather different.
So let me suggest another way, thinking a bit "out of the box" :
In fact, when you think about it, the only thing for which Tomcat needs these "roles", is
to determine if the user has or not access to the application. (I doubt that inside the
applications themselves, there are any "isUserInRole" calls; are there ?).
Now, you already use a front-end Apache httpd, and this front-end httpd already has an OAM
plugin. And this OAM plugin allows you to configure a Location such :
<Location /myapp>
AuthType Oblix
require valid_user
SetHandler jakarta-servlet
...
</Location>
I have to suppose that there exists a way, within OAM, to indicate not only if this user
is valid in general, but also to indicate íf this user has access or not to "/myapp".
If so, then nothing stops you from having as many <Location> sections in the front-end
Apache httpd, as you have webapps in Tomcat, like :
<Location /myapp2>
<Location /myapp3>
etc..
And then, provided that the only way to access Tomcat is through the httpd font-end, you
do not need any roles in Tomcat.
If the user is not allowed by OAM to access "/myapp2", then he will never get past the
front-end, and the request will never even be forwarded to Tomcat.
And if you need the OAM /user-id/ within the Tomcat applications, then that is a different
matter. Maybe a simple servlet filter examining the OAM cookies, extracting the user-id
and populating the userPrincipal would be sufficient to do that.
And if the above doesn't work, then I have some more ideas, based on the "external
applications" part of OAM, which I saw while browsing the OAM documentation.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Do any of the Tomcat LDAP-type realms support "no password"
authentication?
Posted by oh...@cox.net.
---- ohaya@cox.net wrote:
>
> ---- "Caldarale wrote:
> > > From: ohaya@cox.net [mailto:ohaya@cox.net]
> > > Subject: Re: Do any of the Tomcat LDAP-type realms support "no password" authentication?
> >
> > > In other words, even though my valve code can assert a user
> > > into Tomcat, and even if that same user already exists in the
> > > Tomcat realm, the asserted user seems to be 'disassociated'
> > > from the same user in the Tomcat realm?
> >
> > Need to get some terminology correct here. A Realm does not normally contain users, roles, or any other authentication or authorization _data_; rather, it is a Java class that embodies rules for examining the credentials supplied by a login attempt and comparing them to credentials and roles stored in some external location. By default (and never meant to be used in production), the external location is the file tomcat-users.xml, and the Realm is UserDatabaseRealm (augmented by LockOutRealm to discourage probing). Several other Realm classes are supplied with Tomcat, to allow access to credentials from LDAP servers, relational databases, JAAS, etc.
> >
> > I think what you need is essentially a Realm that does no authentication of its own (trusting httpd to do that), but does perform the authorization function. It can then map the userid to whatever set of roles are appropriate for that user, and return the appropriate response when queried. See the doc for details:
> >
> > http://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html
> >
> > It would seem likely that someone out there has written a Realm that performs the above functions in conjunction with httpd authentication. (Note: you keep using the word "Apache" - which is a software organization with many products - when you're referring to httpd, a specific Apache product, as is Tomcat.)
> >
> > - Chuck
> >
>
>
> Hi Chuck,
>
> Corrections understood, and I'll try to be more careful. As you point out, and as I mentioned earlier in the thread, it seems like I've come all the way around to the original subject "...Tomcat LDAP-type realms support "no password" authentication?".
>
> I've been and still am looking around for something like that, but haven't found it yet.
>
> I'm still puzzled by something though. Even if I did find (or implement) a realm that was a "no password realm", how do I tie the two pieces that I end up with, the valve and the no-password realm, together?
>
> In other words, I can pull the userID from the incoming header in the valve, but then I think that the valve code then needs to authenticate against the no-password realm. Is that correct?
>
> And, if so, how to do that?
>
> I've been looking for a way (API?) to programmatically "authenticate the user" against Tomcat, so that I could add that into my valve code, but haven't been find anything yet.
>
> Thanks,
> Jim
>
>
Hi,
I've had some success, so I thought that some of you might be interested. After much more searching, I still haven't been to find anything like a "no password realm", so what I've been hacking around is to add an authenticate() method to my valve, where that calls an realm.authenticate(), then a register() method.
This is more of an "experiment" than something realistic.
Anyway, doing the above, I've been able to successfully authenticate the incoming userID "into the Tomcat realm". What I mean by "into the Tomcat realm" is that I get a MemoryUser object back, that has the roles (via MemoryUser.getRoles()) that are configured in the tomcat-users.xml.
In other words, a header comes into Tomcat with, say, userID of "foobar". My valve code authenticates the user into the Tomcat realm, and then things like isInRole(), etc. seem to all work.
What I'm still trying to figure out is that the realm.authenticate() is still requiring a password match. I thought that I could coerce the realm.authenticate() to do a cert authentication, because I've read that with that, it basically just tries to do a match of the user string in tomcat-users.xml, but I haven't been able to figure out how to do that (coerce the authentication method) yet. If anyone knows how to do that, please post back.
Thanks,
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Do any of the Tomcat LDAP-type realms support "no password"
authentication?
Posted by oh...@cox.net.
---- "Caldarale wrote:
> > From: ohaya@cox.net [mailto:ohaya@cox.net]
> > Subject: Re: Do any of the Tomcat LDAP-type realms support "no password" authentication?
>
> > In other words, even though my valve code can assert a user
> > into Tomcat, and even if that same user already exists in the
> > Tomcat realm, the asserted user seems to be 'disassociated'
> > from the same user in the Tomcat realm?
>
> Need to get some terminology correct here. A Realm does not normally contain users, roles, or any other authentication or authorization _data_; rather, it is a Java class that embodies rules for examining the credentials supplied by a login attempt and comparing them to credentials and roles stored in some external location. By default (and never meant to be used in production), the external location is the file tomcat-users.xml, and the Realm is UserDatabaseRealm (augmented by LockOutRealm to discourage probing). Several other Realm classes are supplied with Tomcat, to allow access to credentials from LDAP servers, relational databases, JAAS, etc.
>
> I think what you need is essentially a Realm that does no authentication of its own (trusting httpd to do that), but does perform the authorization function. It can then map the userid to whatever set of roles are appropriate for that user, and return the appropriate response when queried. See the doc for details:
>
> http://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html
>
> It would seem likely that someone out there has written a Realm that performs the above functions in conjunction with httpd authentication. (Note: you keep using the word "Apache" - which is a software organization with many products - when you're referring to httpd, a specific Apache product, as is Tomcat.)
>
> - Chuck
>
Hi Chuck,
Corrections understood, and I'll try to be more careful. As you point out, and as I mentioned earlier in the thread, it seems like I've come all the way around to the original subject "...Tomcat LDAP-type realms support "no password" authentication?".
I've been and still am looking around for something like that, but haven't found it yet.
I'm still puzzled by something though. Even if I did find (or implement) a realm that was a "no password realm", how do I tie the two pieces that I end up with, the valve and the no-password realm, together?
In other words, I can pull the userID from the incoming header in the valve, but then I think that the valve code then needs to authenticate against the no-password realm. Is that correct?
And, if so, how to do that?
I've been looking for a way (API?) to programmatically "authenticate the user" against Tomcat, so that I could add that into my valve code, but haven't been find anything yet.
Thanks,
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Do any of the Tomcat LDAP-type realms support "no password"
authentication?
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: ohaya@cox.net [mailto:ohaya@cox.net]
> Subject: Re: Do any of the Tomcat LDAP-type realms support "no password" authentication?
> In other words, even though my valve code can assert a user
> into Tomcat, and even if that same user already exists in the
> Tomcat realm, the asserted user seems to be 'disassociated'
> from the same user in the Tomcat realm?
Need to get some terminology correct here. A Realm does not normally contain users, roles, or any other authentication or authorization _data_; rather, it is a Java class that embodies rules for examining the credentials supplied by a login attempt and comparing them to credentials and roles stored in some external location. By default (and never meant to be used in production), the external location is the file tomcat-users.xml, and the Realm is UserDatabaseRealm (augmented by LockOutRealm to discourage probing). Several other Realm classes are supplied with Tomcat, to allow access to credentials from LDAP servers, relational databases, JAAS, etc.
I think what you need is essentially a Realm that does no authentication of its own (trusting httpd to do that), but does perform the authorization function. It can then map the userid to whatever set of roles are appropriate for that user, and return the appropriate response when queried. See the doc for details:
http://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html
It would seem likely that someone out there has written a Realm that performs the above functions in conjunction with httpd authentication. (Note: you keep using the word "Apache" - which is a software organization with many products - when you're referring to httpd, a specific Apache product, as is Tomcat.)
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
Re: Do any of the Tomcat LDAP-type realms support "no password"
authentication?
Posted by oh...@cox.net.
> > >
> > > Hi,
> > >
> > > I didn't say anything about it before, but I've been, in parallel with our discussion, mucking around both the OAM innards and the Apache source code, as best I can, trying to find out why that internal remote_user string (it is, I believe, only internal to Apache), to see why it isn't being set. Notice also that I said "remote_user string", rather than "remote_user variable".
> > >
> > > The reason is that, in looking through the Apache source code, I haven't (yet) been able to find a variable like that. Rather, it looks like the Apache code just dumps the string representing the user into some buffer that its building to send out via AJP protocol.
> > >
> > > On the OAM side, I haven't been able to find any configuration "tweaks" that would make their webagent populate (or not populate) whatever data structure inside of Apache either.
> > >
> > > I may or may not decide to try to bug Oracle about why their webagent doesn't do appear to do that. Probably not though, as in the past, it's hard to find someone who knows their stuff well enough to answer such an esoteric question. Plus, the valve seems to work at the moment.
> > >
> > > Having said that, and having started to work more with my valve code, I do have a more on-topic question for you and for the list, in general.
> > >
> > > To recall, my test Tomcat is pretty much vanilla, including the default realm that uses the tomcat-users.xml.
> > >
> > > Earlier, you and Chuck said that when my valve code asserts a user into Tomcat (e.g., via the setUserPrincipal()), that that asserted user didn't have to even be in the Tomcat realm.
> > >
> > > I'm finding that that part does work as we've discussed, but the question that I have is what roles in Tomcat would that user have (in Tomcat)?
> > >
> > > In my testing, and as I've mucked around with my valve code, I found that I could assert not only a user, but it looks like I can also assert that user's roles in Tomcat.
> > >
> > > And, I can even assert roles that don't exist in the realm!!
> > >
> > > In other words, suppose my valve gets a request with a userID of "foobar". Then, it appears that my valve code can not only assert the "foobar" user into Tomcat, but can also assert that the "foobar" user has roles "foobarRole1" and "foobarRole2", EVEN when those roles don't exist/aren't defined in the Tomcat realm.
> > >
> > > Is this correct?
> > >
> > >
> > > If it is, I may have a problem.
> > >
> > > Let me explain:
> > >
> > > My original plan/thought/idea/thinking was that if I could get my valve code to assert the user into Tomcat as a principal in the Tomcat environment, then, at least to Tomcat itself, that user/principal would "pick up" the roles that that user would have within the Tomcat realm.
> > >
> > > In other words, if I asserted "foobar" into Tomcat, and if there was already a user named "foobar" in the Tomcat realm, that then the asserted user would have all of the roles within Tomcat that he/she should have, via the realm.
> > >
> > > However, that doesn't appear to be the case :(.
> > >
> > > Rather it appears that even if the user that I'm asserting actually exists in the Tomcat realm, after my valve asserts the user into Tomcat, the user doesn't appear to have any roles in Tomcat. I'm using the security example app in the /examples that comes with Tomcat to check if Tomcat 'believes" that the asserted user has xxxx role.
> > >
> > > In other words, even though my valve code can assert a user into Tomcat, and even if that same user already exists in the Tomcat realm, the asserted user seems to be 'disassociated' from the same user in the Tomcat realm?
> > >
> > > I'm not sure if I'm explaining that clearly, but let me know?
> > >
> > > Here's an example:
> > >
> > > In tomcat-users.xml, I have a user, "0test" with role "manager-gui".
> > >
> > > I send a header into my valve with userID "0test", and it asserts the "0test" user into Tomcat.
> > >
> > > Then I go to the Tomcat security example app, and I search for role of "manager-gui", and the app tells me that user "0test" has not been granted the "manager-gui" role.
> > >
> > > So the question that I really have here is: Can I "connect" the user that my valve asserts into Tomcat with the corresponding user in the Tomcat realm (so that the asserted user can "have" all of the roles in Tomcat that he/she "should" have)?
> > >
> > > Thanks,
> > > Jim
> > >
> > >
> >
> >
> > Hi,
> >
> > I just found the following, which seems to confirm what I'm finding with asserted users, as described above:
> >
> > http://wiki.oss-watch.ac.uk/ShibbolethTomcatIntegration
> >
> > Note where it says:
> >
> > "This requires that any acess to /jsp-examples/snp/* be authenticated to any of
> > the roles declared to Tomcat elsewhere in the web.xml file. The problem with
> > this when receiving authentication information from Apache httpd via mod_jk is
> > that we have not found any way to associate role membership with the
> > authenticated user. As a result, Tomcat refuses access to the servlet, even
> > though we do appear to have successfully conveyed authenticated user information
> > to Tomcat.
> >
> > It appears that when Tomcat's own authentication is bypassed (using
> > tomcatAuthentication="false" noted above), Tomcat's mechanisms for assigning
> > roles to users (e.g. from tomcat-users.xml) are also bypassed, so the
> > authentication is effectively useless for invoking servlets."
> >
> > That is exactly the same problem/behavior that I'm seeing with users that I assert into Tomcat using my valve code...
> >
> > Jim
> >
>
> P.S. Also, the same problem/behavior occurs, even when I'm not using my valve code to do the assertion, when I use mod_jk and AJP and tomcatAuthentication=false. In this case (using mod_jk and AJP), the user that gets asserted into Tomcat via the AJP connector doesn't get any roles within the Tomcat realm :(....
>
>
Hi,
In thinking about the role problem that I described above, I think that this kind of takes me back to my original question in this thread.
With other products that I've worked with (e.g., WebLogic) after the id is asserted, another, authentication provider will take the asserted id and then authenticate the id (into the WebLogic domain, in the case of WebLogic).
In the case here, with Tomcat, it seems like what I need to do to fix this roles problem is, in my valve code, to take the incoming pre-authenticated id, and somehow actually authenticate it into the existing Tomcat realm.
If you recall, that is kind of related to my first question in this thread, i.e., how can I take just the userID, with no additional credentials, and authenticate the user into the Tomcat realm?
Does anyone know how to do that in code? Does Tomcat have an API that I can call in my valve code, something like:
xxxx.authenticate(myUserId);
??
Thanks,
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password"
authentication?
Posted by oh...@cox.net.
---- ohaya@cox.net wrote:
>
> ---- ohaya@cox.net wrote:
> >
> > ---- "André Warnier" <aw...@ice-sa.com> wrote:
> > > ohaya@cox.net wrote:
> > > > ---- "André Warnier" <aw...@ice-sa.com> wrote:
> > > >> ohaya@cox.net wrote:
> > > >>> ---- "André Warnier" <aw...@ice-sa.com> wrote:
> > > >>>> ohaya@cox.net wrote:
> > > >>>>>> Now let me ask another question :
> > > >>>>>> Why do you need to authenticate the user at the Apache level, and pass this user-id to
> > > >>>>>> Tomcat ?
> > > >>>>>> Obviously, from the OAM documentation I scanned, there must exist an OAM module directly
> > > >>>>>> for Tomcat, to authenticate users there. Why are you not using that ?
> > > >>>>> It seems like they should have one, but, unfortunately, they don't.
> > > >>>>>
> > > >>>> Mmm. Browsing the documentation, I seem to remember seeing something about Weblogic, no ?
> > > >>>> Is that not usable ?
> > > >>>>
> > > >>>> (As an aside, send your messages only to the list. I get all messages to the list anyway,
> > > >>>> so if you send them to me too, I get them twice).
> > > >>>
> > > >>> Hi,
> > > >>>
> > > >>> Sorry about the emails.
> > > >>>
> > > >>> Yes, they do support integrating with WebLogic, and we do use that for other cases, but that's probably a bit off-topic here.
> > > >>>
> > > >> We don't mind the competition here. Keeps us on our toes.
> > > >> Just kidding.
> > > >> What I meant to ask (me being the not-so-Java specialist see) was, since Weblogic is a
> > > >> servlet engine, and Tomcat is a servlet engine, both ought to abide by the servlet spec
> > > >> and such, so isn't the Weblogic-oriented module usable with Tomcat ?
> > > >> Or is this too much of a rosy view of the world ?
> > > >>
> > > >> Anyway, the only other thing that comes to mind is, since you seem to be an OAM customer,
> > > >> can you not ask the OAM support people if OAM sets the internal Apache user-id or not ?
> > > >>
> > > >
> > > >
> > > > Hi,
> > > >
> > > > I'll answer the last question first: We have asked, but they don't support integration with Tomcat out-of-the-box. That was why I've been looking into it for our organization.
> > > >
> > >
> > > Ok. But the question here is different : you are not asking if they support Tomcat.
> > > What you are asking is if OAM can set the Apache internal user-id, once the user is
> > > authenticated by OAM.
> > >
> > > The situation is the same as if you had to support, say, some legacy Apache-based
> > > application, and this Apache-based application needs the user-id, and it normally gets it
> > > from Apache.
> > > For example, imagine that your organisation has some pre-existing content-management
> > > system based on Apache and Perl. Now you purchase OAM as a global SSO mechanism, and you
> > > want to use OAM to authenticate the users for your content-management application. For
> > > that, the easiest way is for OAM to just set the Apache user-id, because then you don't
> > > have to change anything to your existing application.
> > >
> >
> > Hi,
> >
> > I didn't say anything about it before, but I've been, in parallel with our discussion, mucking around both the OAM innards and the Apache source code, as best I can, trying to find out why that internal remote_user string (it is, I believe, only internal to Apache), to see why it isn't being set. Notice also that I said "remote_user string", rather than "remote_user variable".
> >
> > The reason is that, in looking through the Apache source code, I haven't (yet) been able to find a variable like that. Rather, it looks like the Apache code just dumps the string representing the user into some buffer that its building to send out via AJP protocol.
> >
> > On the OAM side, I haven't been able to find any configuration "tweaks" that would make their webagent populate (or not populate) whatever data structure inside of Apache either.
> >
> > I may or may not decide to try to bug Oracle about why their webagent doesn't do appear to do that. Probably not though, as in the past, it's hard to find someone who knows their stuff well enough to answer such an esoteric question. Plus, the valve seems to work at the moment.
> >
> > Having said that, and having started to work more with my valve code, I do have a more on-topic question for you and for the list, in general.
> >
> > To recall, my test Tomcat is pretty much vanilla, including the default realm that uses the tomcat-users.xml.
> >
> > Earlier, you and Chuck said that when my valve code asserts a user into Tomcat (e.g., via the setUserPrincipal()), that that asserted user didn't have to even be in the Tomcat realm.
> >
> > I'm finding that that part does work as we've discussed, but the question that I have is what roles in Tomcat would that user have (in Tomcat)?
> >
> > In my testing, and as I've mucked around with my valve code, I found that I could assert not only a user, but it looks like I can also assert that user's roles in Tomcat.
> >
> > And, I can even assert roles that don't exist in the realm!!
> >
> > In other words, suppose my valve gets a request with a userID of "foobar". Then, it appears that my valve code can not only assert the "foobar" user into Tomcat, but can also assert that the "foobar" user has roles "foobarRole1" and "foobarRole2", EVEN when those roles don't exist/aren't defined in the Tomcat realm.
> >
> > Is this correct?
> >
> >
> > If it is, I may have a problem.
> >
> > Let me explain:
> >
> > My original plan/thought/idea/thinking was that if I could get my valve code to assert the user into Tomcat as a principal in the Tomcat environment, then, at least to Tomcat itself, that user/principal would "pick up" the roles that that user would have within the Tomcat realm.
> >
> > In other words, if I asserted "foobar" into Tomcat, and if there was already a user named "foobar" in the Tomcat realm, that then the asserted user would have all of the roles within Tomcat that he/she should have, via the realm.
> >
> > However, that doesn't appear to be the case :(.
> >
> > Rather it appears that even if the user that I'm asserting actually exists in the Tomcat realm, after my valve asserts the user into Tomcat, the user doesn't appear to have any roles in Tomcat. I'm using the security example app in the /examples that comes with Tomcat to check if Tomcat 'believes" that the asserted user has xxxx role.
> >
> > In other words, even though my valve code can assert a user into Tomcat, and even if that same user already exists in the Tomcat realm, the asserted user seems to be 'disassociated' from the same user in the Tomcat realm?
> >
> > I'm not sure if I'm explaining that clearly, but let me know?
> >
> > Here's an example:
> >
> > In tomcat-users.xml, I have a user, "0test" with role "manager-gui".
> >
> > I send a header into my valve with userID "0test", and it asserts the "0test" user into Tomcat.
> >
> > Then I go to the Tomcat security example app, and I search for role of "manager-gui", and the app tells me that user "0test" has not been granted the "manager-gui" role.
> >
> > So the question that I really have here is: Can I "connect" the user that my valve asserts into Tomcat with the corresponding user in the Tomcat realm (so that the asserted user can "have" all of the roles in Tomcat that he/she "should" have)?
> >
> > Thanks,
> > Jim
> >
> >
>
>
> Hi,
>
> I just found the following, which seems to confirm what I'm finding with asserted users, as described above:
>
> http://wiki.oss-watch.ac.uk/ShibbolethTomcatIntegration
>
> Note where it says:
>
> "This requires that any acess to /jsp-examples/snp/* be authenticated to any of
> the roles declared to Tomcat elsewhere in the web.xml file. The problem with
> this when receiving authentication information from Apache httpd via mod_jk is
> that we have not found any way to associate role membership with the
> authenticated user. As a result, Tomcat refuses access to the servlet, even
> though we do appear to have successfully conveyed authenticated user information
> to Tomcat.
>
> It appears that when Tomcat's own authentication is bypassed (using
> tomcatAuthentication="false" noted above), Tomcat's mechanisms for assigning
> roles to users (e.g. from tomcat-users.xml) are also bypassed, so the
> authentication is effectively useless for invoking servlets."
>
> That is exactly the same problem/behavior that I'm seeing with users that I assert into Tomcat using my valve code...
>
> Jim
>
P.S. Also, the same problem/behavior occurs, even when I'm not using my valve code to do the assertion, when I use mod_jk and AJP and tomcatAuthentication=false. In this case (using mod_jk and AJP), the user that gets asserted into Tomcat via the AJP connector doesn't get any roles within the Tomcat realm :(....
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password"
authentication?
Posted by oh...@cox.net.
---- ohaya@cox.net wrote:
>
> ---- "André Warnier" <aw...@ice-sa.com> wrote:
> > ohaya@cox.net wrote:
> > > ---- "André Warnier" <aw...@ice-sa.com> wrote:
> > >> ohaya@cox.net wrote:
> > >>> ---- "André Warnier" <aw...@ice-sa.com> wrote:
> > >>>> ohaya@cox.net wrote:
> > >>>>>> Now let me ask another question :
> > >>>>>> Why do you need to authenticate the user at the Apache level, and pass this user-id to
> > >>>>>> Tomcat ?
> > >>>>>> Obviously, from the OAM documentation I scanned, there must exist an OAM module directly
> > >>>>>> for Tomcat, to authenticate users there. Why are you not using that ?
> > >>>>> It seems like they should have one, but, unfortunately, they don't.
> > >>>>>
> > >>>> Mmm. Browsing the documentation, I seem to remember seeing something about Weblogic, no ?
> > >>>> Is that not usable ?
> > >>>>
> > >>>> (As an aside, send your messages only to the list. I get all messages to the list anyway,
> > >>>> so if you send them to me too, I get them twice).
> > >>>
> > >>> Hi,
> > >>>
> > >>> Sorry about the emails.
> > >>>
> > >>> Yes, they do support integrating with WebLogic, and we do use that for other cases, but that's probably a bit off-topic here.
> > >>>
> > >> We don't mind the competition here. Keeps us on our toes.
> > >> Just kidding.
> > >> What I meant to ask (me being the not-so-Java specialist see) was, since Weblogic is a
> > >> servlet engine, and Tomcat is a servlet engine, both ought to abide by the servlet spec
> > >> and such, so isn't the Weblogic-oriented module usable with Tomcat ?
> > >> Or is this too much of a rosy view of the world ?
> > >>
> > >> Anyway, the only other thing that comes to mind is, since you seem to be an OAM customer,
> > >> can you not ask the OAM support people if OAM sets the internal Apache user-id or not ?
> > >>
> > >
> > >
> > > Hi,
> > >
> > > I'll answer the last question first: We have asked, but they don't support integration with Tomcat out-of-the-box. That was why I've been looking into it for our organization.
> > >
> >
> > Ok. But the question here is different : you are not asking if they support Tomcat.
> > What you are asking is if OAM can set the Apache internal user-id, once the user is
> > authenticated by OAM.
> >
> > The situation is the same as if you had to support, say, some legacy Apache-based
> > application, and this Apache-based application needs the user-id, and it normally gets it
> > from Apache.
> > For example, imagine that your organisation has some pre-existing content-management
> > system based on Apache and Perl. Now you purchase OAM as a global SSO mechanism, and you
> > want to use OAM to authenticate the users for your content-management application. For
> > that, the easiest way is for OAM to just set the Apache user-id, because then you don't
> > have to change anything to your existing application.
> >
>
> Hi,
>
> I didn't say anything about it before, but I've been, in parallel with our discussion, mucking around both the OAM innards and the Apache source code, as best I can, trying to find out why that internal remote_user string (it is, I believe, only internal to Apache), to see why it isn't being set. Notice also that I said "remote_user string", rather than "remote_user variable".
>
> The reason is that, in looking through the Apache source code, I haven't (yet) been able to find a variable like that. Rather, it looks like the Apache code just dumps the string representing the user into some buffer that its building to send out via AJP protocol.
>
> On the OAM side, I haven't been able to find any configuration "tweaks" that would make their webagent populate (or not populate) whatever data structure inside of Apache either.
>
> I may or may not decide to try to bug Oracle about why their webagent doesn't do appear to do that. Probably not though, as in the past, it's hard to find someone who knows their stuff well enough to answer such an esoteric question. Plus, the valve seems to work at the moment.
>
> Having said that, and having started to work more with my valve code, I do have a more on-topic question for you and for the list, in general.
>
> To recall, my test Tomcat is pretty much vanilla, including the default realm that uses the tomcat-users.xml.
>
> Earlier, you and Chuck said that when my valve code asserts a user into Tomcat (e.g., via the setUserPrincipal()), that that asserted user didn't have to even be in the Tomcat realm.
>
> I'm finding that that part does work as we've discussed, but the question that I have is what roles in Tomcat would that user have (in Tomcat)?
>
> In my testing, and as I've mucked around with my valve code, I found that I could assert not only a user, but it looks like I can also assert that user's roles in Tomcat.
>
> And, I can even assert roles that don't exist in the realm!!
>
> In other words, suppose my valve gets a request with a userID of "foobar". Then, it appears that my valve code can not only assert the "foobar" user into Tomcat, but can also assert that the "foobar" user has roles "foobarRole1" and "foobarRole2", EVEN when those roles don't exist/aren't defined in the Tomcat realm.
>
> Is this correct?
>
>
> If it is, I may have a problem.
>
> Let me explain:
>
> My original plan/thought/idea/thinking was that if I could get my valve code to assert the user into Tomcat as a principal in the Tomcat environment, then, at least to Tomcat itself, that user/principal would "pick up" the roles that that user would have within the Tomcat realm.
>
> In other words, if I asserted "foobar" into Tomcat, and if there was already a user named "foobar" in the Tomcat realm, that then the asserted user would have all of the roles within Tomcat that he/she should have, via the realm.
>
> However, that doesn't appear to be the case :(.
>
> Rather it appears that even if the user that I'm asserting actually exists in the Tomcat realm, after my valve asserts the user into Tomcat, the user doesn't appear to have any roles in Tomcat. I'm using the security example app in the /examples that comes with Tomcat to check if Tomcat 'believes" that the asserted user has xxxx role.
>
> In other words, even though my valve code can assert a user into Tomcat, and even if that same user already exists in the Tomcat realm, the asserted user seems to be 'disassociated' from the same user in the Tomcat realm?
>
> I'm not sure if I'm explaining that clearly, but let me know?
>
> Here's an example:
>
> In tomcat-users.xml, I have a user, "0test" with role "manager-gui".
>
> I send a header into my valve with userID "0test", and it asserts the "0test" user into Tomcat.
>
> Then I go to the Tomcat security example app, and I search for role of "manager-gui", and the app tells me that user "0test" has not been granted the "manager-gui" role.
>
> So the question that I really have here is: Can I "connect" the user that my valve asserts into Tomcat with the corresponding user in the Tomcat realm (so that the asserted user can "have" all of the roles in Tomcat that he/she "should" have)?
>
> Thanks,
> Jim
>
>
Hi,
I just found the following, which seems to confirm what I'm finding with asserted users, as described above:
http://wiki.oss-watch.ac.uk/ShibbolethTomcatIntegration
Note where it says:
"This requires that any acess to /jsp-examples/snp/* be authenticated to any of
the roles declared to Tomcat elsewhere in the web.xml file. The problem with
this when receiving authentication information from Apache httpd via mod_jk is
that we have not found any way to associate role membership with the
authenticated user. As a result, Tomcat refuses access to the servlet, even
though we do appear to have successfully conveyed authenticated user information
to Tomcat.
It appears that when Tomcat's own authentication is bypassed (using
tomcatAuthentication="false" noted above), Tomcat's mechanisms for assigning
roles to users (e.g. from tomcat-users.xml) are also bypassed, so the
authentication is effectively useless for invoking servlets."
That is exactly the same problem/behavior that I'm seeing with users that I assert into Tomcat using my valve code...
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password"
authentication?
Posted by oh...@cox.net.
---- "André Warnier" <aw...@ice-sa.com> wrote:
> ohaya@cox.net wrote:
> > ---- "André Warnier" <aw...@ice-sa.com> wrote:
> >> ohaya@cox.net wrote:
> >>> ---- "André Warnier" <aw...@ice-sa.com> wrote:
> >>>> ohaya@cox.net wrote:
> >>>>>> Now let me ask another question :
> >>>>>> Why do you need to authenticate the user at the Apache level, and pass this user-id to
> >>>>>> Tomcat ?
> >>>>>> Obviously, from the OAM documentation I scanned, there must exist an OAM module directly
> >>>>>> for Tomcat, to authenticate users there. Why are you not using that ?
> >>>>> It seems like they should have one, but, unfortunately, they don't.
> >>>>>
> >>>> Mmm. Browsing the documentation, I seem to remember seeing something about Weblogic, no ?
> >>>> Is that not usable ?
> >>>>
> >>>> (As an aside, send your messages only to the list. I get all messages to the list anyway,
> >>>> so if you send them to me too, I get them twice).
> >>>
> >>> Hi,
> >>>
> >>> Sorry about the emails.
> >>>
> >>> Yes, they do support integrating with WebLogic, and we do use that for other cases, but that's probably a bit off-topic here.
> >>>
> >> We don't mind the competition here. Keeps us on our toes.
> >> Just kidding.
> >> What I meant to ask (me being the not-so-Java specialist see) was, since Weblogic is a
> >> servlet engine, and Tomcat is a servlet engine, both ought to abide by the servlet spec
> >> and such, so isn't the Weblogic-oriented module usable with Tomcat ?
> >> Or is this too much of a rosy view of the world ?
> >>
> >> Anyway, the only other thing that comes to mind is, since you seem to be an OAM customer,
> >> can you not ask the OAM support people if OAM sets the internal Apache user-id or not ?
> >>
> >
> >
> > Hi,
> >
> > I'll answer the last question first: We have asked, but they don't support integration with Tomcat out-of-the-box. That was why I've been looking into it for our organization.
> >
>
> Ok. But the question here is different : you are not asking if they support Tomcat.
> What you are asking is if OAM can set the Apache internal user-id, once the user is
> authenticated by OAM.
>
> The situation is the same as if you had to support, say, some legacy Apache-based
> application, and this Apache-based application needs the user-id, and it normally gets it
> from Apache.
> For example, imagine that your organisation has some pre-existing content-management
> system based on Apache and Perl. Now you purchase OAM as a global SSO mechanism, and you
> want to use OAM to authenticate the users for your content-management application. For
> that, the easiest way is for OAM to just set the Apache user-id, because then you don't
> have to change anything to your existing application.
>
Hi,
I didn't say anything about it before, but I've been, in parallel with our discussion, mucking around both the OAM innards and the Apache source code, as best I can, trying to find out why that internal remote_user string (it is, I believe, only internal to Apache), to see why it isn't being set. Notice also that I said "remote_user string", rather than "remote_user variable".
The reason is that, in looking through the Apache source code, I haven't (yet) been able to find a variable like that. Rather, it looks like the Apache code just dumps the string representing the user into some buffer that its building to send out via AJP protocol.
On the OAM side, I haven't been able to find any configuration "tweaks" that would make their webagent populate (or not populate) whatever data structure inside of Apache either.
I may or may not decide to try to bug Oracle about why their webagent doesn't do appear to do that. Probably not though, as in the past, it's hard to find someone who knows their stuff well enough to answer such an esoteric question. Plus, the valve seems to work at the moment.
Having said that, and having started to work more with my valve code, I do have a more on-topic question for you and for the list, in general.
To recall, my test Tomcat is pretty much vanilla, including the default realm that uses the tomcat-users.xml.
Earlier, you and Chuck said that when my valve code asserts a user into Tomcat (e.g., via the setUserPrincipal()), that that asserted user didn't have to even be in the Tomcat realm.
I'm finding that that part does work as we've discussed, but the question that I have is what roles in Tomcat would that user have (in Tomcat)?
In my testing, and as I've mucked around with my valve code, I found that I could assert not only a user, but it looks like I can also assert that user's roles in Tomcat.
And, I can even assert roles that don't exist in the realm!!
In other words, suppose my valve gets a request with a userID of "foobar". Then, it appears that my valve code can not only assert the "foobar" user into Tomcat, but can also assert that the "foobar" user has roles "foobarRole1" and "foobarRole2", EVEN when those roles don't exist/aren't defined in the Tomcat realm.
Is this correct?
If it is, I may have a problem.
Let me explain:
My original plan/thought/idea/thinking was that if I could get my valve code to assert the user into Tomcat as a principal in the Tomcat environment, then, at least to Tomcat itself, that user/principal would "pick up" the roles that that user would have within the Tomcat realm.
In other words, if I asserted "foobar" into Tomcat, and if there was already a user named "foobar" in the Tomcat realm, that then the asserted user would have all of the roles within Tomcat that he/she should have, via the realm.
However, that doesn't appear to be the case :(.
Rather it appears that even if the user that I'm asserting actually exists in the Tomcat realm, after my valve asserts the user into Tomcat, the user doesn't appear to have any roles in Tomcat. I'm using the security example app in the /examples that comes with Tomcat to check if Tomcat 'believes" that the asserted user has xxxx role.
In other words, even though my valve code can assert a user into Tomcat, and even if that same user already exists in the Tomcat realm, the asserted user seems to be 'disassociated' from the same user in the Tomcat realm?
I'm not sure if I'm explaining that clearly, but let me know?
Here's an example:
In tomcat-users.xml, I have a user, "0test" with role "manager-gui".
I send a header into my valve with userID "0test", and it asserts the "0test" user into Tomcat.
Then I go to the Tomcat security example app, and I search for role of "manager-gui", and the app tells me that user "0test" has not been granted the "manager-gui" role.
So the question that I really have here is: Can I "connect" the user that my valve asserts into Tomcat with the corresponding user in the Tomcat realm (so that the asserted user can "have" all of the roles in Tomcat that he/she "should" have)?
Thanks,
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password" authentication?
Posted by André Warnier <aw...@ice-sa.com>.
ohaya@cox.net wrote:
> ---- "André Warnier" <aw...@ice-sa.com> wrote:
>> ohaya@cox.net wrote:
>>> ---- "André Warnier" <aw...@ice-sa.com> wrote:
>>>> ohaya@cox.net wrote:
>>>>>> Now let me ask another question :
>>>>>> Why do you need to authenticate the user at the Apache level, and pass this user-id to
>>>>>> Tomcat ?
>>>>>> Obviously, from the OAM documentation I scanned, there must exist an OAM module directly
>>>>>> for Tomcat, to authenticate users there. Why are you not using that ?
>>>>> It seems like they should have one, but, unfortunately, they don't.
>>>>>
>>>> Mmm. Browsing the documentation, I seem to remember seeing something about Weblogic, no ?
>>>> Is that not usable ?
>>>>
>>>> (As an aside, send your messages only to the list. I get all messages to the list anyway,
>>>> so if you send them to me too, I get them twice).
>>>
>>> Hi,
>>>
>>> Sorry about the emails.
>>>
>>> Yes, they do support integrating with WebLogic, and we do use that for other cases, but that's probably a bit off-topic here.
>>>
>> We don't mind the competition here. Keeps us on our toes.
>> Just kidding.
>> What I meant to ask (me being the not-so-Java specialist see) was, since Weblogic is a
>> servlet engine, and Tomcat is a servlet engine, both ought to abide by the servlet spec
>> and such, so isn't the Weblogic-oriented module usable with Tomcat ?
>> Or is this too much of a rosy view of the world ?
>>
>> Anyway, the only other thing that comes to mind is, since you seem to be an OAM customer,
>> can you not ask the OAM support people if OAM sets the internal Apache user-id or not ?
>>
>
>
> Hi,
>
> I'll answer the last question first: We have asked, but they don't support integration with Tomcat out-of-the-box. That was why I've been looking into it for our organization.
>
Ok. But the question here is different : you are not asking if they support Tomcat.
What you are asking is if OAM can set the Apache internal user-id, once the user is
authenticated by OAM.
The situation is the same as if you had to support, say, some legacy Apache-based
application, and this Apache-based application needs the user-id, and it normally gets it
from Apache.
For example, imagine that your organisation has some pre-existing content-management
system based on Apache and Perl. Now you purchase OAM as a global SSO mechanism, and you
want to use OAM to authenticate the users for your content-management application. For
that, the easiest way is for OAM to just set the Apache user-id, because then you don't
have to change anything to your existing application.
> Re. your 1st question, yes, WebLogic is J2EE, but the integration that Oracle has with WebLogic is based on providers that leverage the (old) WebLogic/BEA security framework, which is/was proprietary to WebLogic, so those providers are not compatible with or usable with anything other than WebLogic.
>
> The situation is similar to Tomcat and valves I guess, i.e., Tomcat is J2EE compliant (for JSPs, servlets, etc., but valves are "proprietary'' to Tomcat.
>
> Jim
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password"
authentication?
Posted by oh...@cox.net.
---- "André Warnier" <aw...@ice-sa.com> wrote:
> ohaya@cox.net wrote:
> > ---- "André Warnier" <aw...@ice-sa.com> wrote:
> >> ohaya@cox.net wrote:
> >>>> Now let me ask another question :
> >>>> Why do you need to authenticate the user at the Apache level, and pass this user-id to
> >>>> Tomcat ?
> >>>> Obviously, from the OAM documentation I scanned, there must exist an OAM module directly
> >>>> for Tomcat, to authenticate users there. Why are you not using that ?
> >>>
> >>> It seems like they should have one, but, unfortunately, they don't.
> >>>
> >> Mmm. Browsing the documentation, I seem to remember seeing something about Weblogic, no ?
> >> Is that not usable ?
> >>
> >> (As an aside, send your messages only to the list. I get all messages to the list anyway,
> >> so if you send them to me too, I get them twice).
> >
> >
> > Hi,
> >
> > Sorry about the emails.
> >
> > Yes, they do support integrating with WebLogic, and we do use that for other cases, but that's probably a bit off-topic here.
> >
> We don't mind the competition here. Keeps us on our toes.
> Just kidding.
> What I meant to ask (me being the not-so-Java specialist see) was, since Weblogic is a
> servlet engine, and Tomcat is a servlet engine, both ought to abide by the servlet spec
> and such, so isn't the Weblogic-oriented module usable with Tomcat ?
> Or is this too much of a rosy view of the world ?
>
> Anyway, the only other thing that comes to mind is, since you seem to be an OAM customer,
> can you not ask the OAM support people if OAM sets the internal Apache user-id or not ?
>
Hi,
I'll answer the last question first: We have asked, but they don't support integration with Tomcat out-of-the-box. That was why I've been looking into it for our organization.
Re. your 1st question, yes, WebLogic is J2EE, but the integration that Oracle has with WebLogic is based on providers that leverage the (old) WebLogic/BEA security framework, which is/was proprietary to WebLogic, so those providers are not compatible with or usable with anything other than WebLogic.
The situation is similar to Tomcat and valves I guess, i.e., Tomcat is J2EE compliant (for JSPs, servlets, etc., but valves are "proprietary'' to Tomcat.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password" authentication?
Posted by André Warnier <aw...@ice-sa.com>.
ohaya@cox.net wrote:
> ---- "André Warnier" <aw...@ice-sa.com> wrote:
>> ohaya@cox.net wrote:
>>>> Now let me ask another question :
>>>> Why do you need to authenticate the user at the Apache level, and pass this user-id to
>>>> Tomcat ?
>>>> Obviously, from the OAM documentation I scanned, there must exist an OAM module directly
>>>> for Tomcat, to authenticate users there. Why are you not using that ?
>>>
>>> It seems like they should have one, but, unfortunately, they don't.
>>>
>> Mmm. Browsing the documentation, I seem to remember seeing something about Weblogic, no ?
>> Is that not usable ?
>>
>> (As an aside, send your messages only to the list. I get all messages to the list anyway,
>> so if you send them to me too, I get them twice).
>
>
> Hi,
>
> Sorry about the emails.
>
> Yes, they do support integrating with WebLogic, and we do use that for other cases, but that's probably a bit off-topic here.
>
We don't mind the competition here. Keeps us on our toes.
Just kidding.
What I meant to ask (me being the not-so-Java specialist see) was, since Weblogic is a
servlet engine, and Tomcat is a servlet engine, both ought to abide by the servlet spec
and such, so isn't the Weblogic-oriented module usable with Tomcat ?
Or is this too much of a rosy view of the world ?
Anyway, the only other thing that comes to mind is, since you seem to be an OAM customer,
can you not ask the OAM support people if OAM sets the internal Apache user-id or not ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password"
authentication?
Posted by oh...@cox.net.
---- "André Warnier" <aw...@ice-sa.com> wrote:
> ohaya@cox.net wrote:
> >> Now let me ask another question :
> >> Why do you need to authenticate the user at the Apache level, and pass this user-id to
> >> Tomcat ?
> >> Obviously, from the OAM documentation I scanned, there must exist an OAM module directly
> >> for Tomcat, to authenticate users there. Why are you not using that ?
> >
> >
> > It seems like they should have one, but, unfortunately, they don't.
> >
> Mmm. Browsing the documentation, I seem to remember seeing something about Weblogic, no ?
> Is that not usable ?
>
> (As an aside, send your messages only to the list. I get all messages to the list anyway,
> so if you send them to me too, I get them twice).
Hi,
Sorry about the emails.
Yes, they do support integrating with WebLogic, and we do use that for other cases, but that's probably a bit off-topic here.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password" authentication?
Posted by André Warnier <aw...@ice-sa.com>.
ohaya@cox.net wrote:
>> Now let me ask another question :
>> Why do you need to authenticate the user at the Apache level, and pass this user-id to
>> Tomcat ?
>> Obviously, from the OAM documentation I scanned, there must exist an OAM module directly
>> for Tomcat, to authenticate users there. Why are you not using that ?
>
>
> It seems like they should have one, but, unfortunately, they don't.
>
Mmm. Browsing the documentation, I seem to remember seeing something about Weblogic, no ?
Is that not usable ?
(As an aside, send your messages only to the list. I get all messages to the list anyway,
so if you send them to me too, I get them twice).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password"
authentication?
Posted by oh...@cox.net.
> Now let me ask another question :
> Why do you need to authenticate the user at the Apache level, and pass this user-id to
> Tomcat ?
> Obviously, from the OAM documentation I scanned, there must exist an OAM module directly
> for Tomcat, to authenticate users there. Why are you not using that ?
It seems like they should have one, but, unfortunately, they don't.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password" authentication?
Posted by André Warnier <aw...@ice-sa.com>.
ohaya@cox.net wrote:
> ---- ohaya@cox.net wrote:
>> ---- "André Warnier" <aw...@ice-sa.com> wrote:
>>> André Warnier wrote:
>>>> 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 ?).
>>>>
>>>>
>>> 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?
>
I did not expect that changing the order of loading of the modules would make a
difference. This is an authentication module, and those get called pretty early in the
cycle, before the content-generating modules. And not all get called, just the one
configured for the scope (here, the <Location>).
I am also about out of my wits.
Obviously, the OAM scheme is not setting the internal Apache user-id.
Maybe it never does, or maybe there is some required OAM setup parameter that we don't know.
Now let me ask another question :
Why do you need to authenticate the user at the Apache level, and pass this user-id to
Tomcat ?
Obviously, from the OAM documentation I scanned, there must exist an OAM module directly
for Tomcat, to authenticate users there. Why are you not using that ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password"
authentication?
Posted by oh...@cox.net.
---- ohaya@cox.net wrote:
>
> ---- "André Warnier" <aw...@ice-sa.com> wrote:
> > André Warnier wrote:
> > > 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 ?).
> > >
> > >
> >
> > 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password"
authentication?
Posted by oh...@cox.net.
---- "André Warnier" <aw...@ice-sa.com> wrote:
> André Warnier wrote:
> > 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 ?).
> >
> >
>
> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password" authentication?
Posted by André Warnier <aw...@ice-sa.com>.
André Warnier wrote:
> 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 ?).
>
>
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password" authentication?
Posted by André Warnier <aw...@ice-sa.com>.
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
Re: Do any of the Tomcat LDAP-type realms support "no password"
authentication?
Posted by oh...@cox.net.
---- 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
000001D0 36 2D 53 48 41 00 09 00 40 35 41 38 35 44 36 33 6-SHA... @5A85D63
000001E0 44 46 33 32 42 35 42 38 36 34 44 42 32 37 31 34 DF32B5B8 64DB2714
000001F0 38 39 37 31 31 31 41 42 34 44 35 30 33 32 30 45 897111AB 4D50320E
00000200 39 41 33 38 41 42 46 36 46 38 37 44 30 46 42 43 9A38ABF6 F87D0FBC
00000210 42 38 36 38 31 35 38 37 30 00 0B 01 00 0A 00 0F B8681587 0.......
b) Not working (w/OAM enabled and ajp: ProxyPass):
00000000 12 34 09 28 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 0E 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 A0 04 00 0E 65 6E 2D 75 73 2C 65 6E 3B 71 3D 30 ...en-u s,en;q=0
00000110 2E 35 00 A0 03 00 0D 67 7A 69 70 2C 20 64 65 66 .5. ...g zip, def
00000120 6C 61 74 65 00 A0 02 00 1E 49 53 4F 2D 38 38 35 late. .. .ISO-885
00000130 39 2D 31 2C 75 74 66 2D 38 3B 71 3D 30 2E 37 2C 9-1,utf- 8;q=0.7,
00000140 2A 3B 71 3D 30 2E 37 00 A0 06 00 0A 6B 65 65 70 *;q=0.7. ...keep
00000150 2D 61 6C 69 76 65 00 A0 09 02 C5 4F 62 53 53 4F -alive. ..ÅObSSO
00000160 43 6F 6F 6B 69 65 3D 6B 30 67 61 31 62 38 62 55 Cookie=k 0ga1b8bU
00000170 25 32 46 51 76 70 35 25 32 46 78 75 38 66 39 67 %2FQvp5% 2Fxu8f9g
00000180 32 31 51 54 69 32 69 67 61 66 66 4B 41 34 78 6F 21QTi2ig affKA4xo
00000190 4F 72 69 71 69 6F 45 69 53 53 72 6A 7A 74 58 6B OriqioEi SSrjztXk
000001A0 68 65 4C 6E 49 72 75 53 4B 52 4B 39 41 38 31 6B heLnIruS KRK9A81k
000001B0 33 70 63 25 32 46 50 44 57 68 4A 74 31 42 70 52 3pc%2FPD WhJt1BpR
000001C0 44 75 57 64 30 65 47 65 79 6A 71 72 65 55 61 4C DuWd0eGe yjqreUaL
000001D0 25 32 46 44 78 6A 63 49 30 4C 54 63 44 25 32 46 %2FDxjcI 0LTcD%2F
000001E0 6E 51 65 36 6D 5A 77 71 50 59 4F 61 34 66 46 42 nQe6mZwq PYOa4fFB
000001F0 77 25 32 42 59 4C 78 36 59 54 54 4F 53 38 25 32 w%2BYLx6 YTTOS8%2
00000200 42 62 78 25 32 46 36 45 44 67 47 45 47 57 6C 57 Bbx%2F6E DgGEGWlW
00000210 72 63 56 72 39 49 25 32 46 47 70 72 7A 6F 4B 72 rcVr9I%2 FGprzoKr
00000220 25 32 42 6F 77 67 68 35 59 6A 62 66 32 78 71 72 %2Bowgh5 Yjbf2xqr
00000230 55 4F 72 32 30 63 77 25 32 42 38 59 63 33 30 68 UOr20cw% 2B8Yc30h
00000240 52 64 39 38 4A 67 56 25 32 42 66 79 69 52 6B 31 Rd98JgV% 2BfyiRk1
00000250 47 52 44 6F 38 6C 69 6D 67 32 4B 34 45 7A 30 45 GRDo8lim g2K4Ez0E
00000260 37 78 73 59 55 61 4A 74 59 4C 62 77 65 53 65 4F 7xsYUaJt YLbweSeO
00000270 77 4A 25 32 42 6D 50 6A 25 32 46 77 32 4C 79 74 wJ%2BmPj %2Fw2Lyt
00000280 31 66 31 4A 69 47 71 66 59 50 71 7A 31 5A 67 6F 1f1JiGqf YPqz1Zgo
00000290 41 73 78 25 32 46 75 75 67 37 34 38 6C 78 5A 34 Asx%2Fuu g748lxZ4
000002A0 6A 67 49 78 6F 33 46 66 66 38 32 35 57 51 5A 54 jgIxo3Ff f825WQZT
000002B0 4D 53 45 6A 6A 64 4B 32 73 4A 65 57 37 43 41 63 MSEjjdK2 sJeW7CAc
000002C0 4F 55 30 44 4A 67 64 36 6A 38 37 41 51 48 63 44 OU0DJgd6 j87AQHcD
000002D0 51 54 59 6B 37 49 61 30 75 25 32 46 41 25 33 44 QTYk7Ia0 u%2FA%3D
000002E0 25 33 44 3B 20 4F 41 4D 5F 52 45 51 3D 69 6E 76 %3D; OAM _REQ=inv
000002F0 61 6C 69 64 3B 20 4F 41 4D 5F 49 44 3D 56 45 52 alid; OA M_ID=VER
00000300 53 49 4F 4E 5F 34 7E 2B 7A 66 38 45 5A 66 54 57 SION_4~+ zf8EZfTW
00000310 63 4F 43 31 77 6B 41 55 53 4E 64 49 67 3D 3D 7E cOC1wkAU SNdIg==~
00000320 30 63 49 38 55 52 78 70 33 30 5A 35 72 7A 43 34 0cI8URxp 30Z5rzC4
00000330 37 4C 67 2B 36 4C 59 66 6F 2F 6A 6B 37 55 4E 55 7Lg+6LYf o/jk7UNU
00000340 50 37 32 58 44 62 6A 38 52 79 2F 65 6A 6D 30 44 P72XDbj8 Ry/ejm0D
00000350 6B 55 65 66 6E 4D 6C 57 76 7A 6A 73 46 32 6F 55 kUefnMlW vzjsF2oU
00000360 46 76 52 2F 39 6D 6E 75 49 47 75 35 2F 37 77 4C FvR/9mnu IGu5/7wL
00000370 55 51 33 52 6A 48 70 59 57 7A 56 30 64 74 76 52 UQ3RjHpY WzV0dtvR
00000380 39 38 37 52 53 4D 31 61 54 73 43 49 75 56 43 59 987RSM1a TsCIuVCY
00000390 67 2B 71 79 75 35 43 4F 46 47 68 51 77 52 41 62 g+qyu5CO FGhQwRAb
000003A0 46 72 2F 6D 67 41 48 36 35 51 33 37 41 6F 6E 45 Fr/mgAH6 5Q37AonE
000003B0 4B 36 67 70 37 65 66 78 5A 5A 36 66 42 79 55 5A K6gp7efx ZZ6fByUZ
000003C0 6D 36 54 57 71 4A 74 5A 52 50 77 68 51 51 56 45 m6TWqJtZ RPwhQQVE
000003D0 72 6D 73 59 35 43 4C 66 54 72 59 50 34 6E 48 6C rmsY5CLf TrYP4nHl
000003E0 2B 43 37 54 76 6D 6C 45 4A 6E 41 6D 6E 48 6C 64 +C7TvmlE JnAmnHld
000003F0 59 38 57 51 59 74 34 6E 4E 72 53 7A 46 48 41 55 Y8WQYt4n NrSzFHAU
00000400 49 69 4E 67 41 73 67 6A 35 2F 6C 43 36 77 74 51 IiNgAsgj 5/lC6wtQ
00000410 63 39 6B 59 43 7A 5A 7A 62 67 79 67 2F 51 37 61 c9kYCzZz bgyg/Q7a
00000420 00 00 15 4F 41 4D 5F 49 4D 50 45 52 53 4F 4E 41 ...OAM_I MPERSONA
You can use the "keepalive" string snippet as a "marker" to try to align the two buffer dumps above, and in the former, you can see "testuser" in there, whereas in the latter, that part is empty.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password"
authentication?
Posted by oh...@cox.net.
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
---- ohaya@cox.net wrote:
>
> ---- ohaya@cox.net wrote:
> >
> > ---- "André Warnier" <aw...@ice-sa.com> wrote:
> > > ohaya@cox.net wrote:
> > > > ---- "André Warnier" <aw...@ice-sa.com> wrote:
> > > >> ohaya@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password"
authentication?
Posted by oh...@cox.net.
---- ohaya@cox.net wrote:
>
> ---- "André Warnier" <aw...@ice-sa.com> wrote:
> > ohaya@cox.net wrote:
> > > ---- "André Warnier" <aw...@ice-sa.com> wrote:
> > >> ohaya@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password"
authentication?
Posted by oh...@cox.net.
---- "André Warnier" <aw...@ice-sa.com> wrote:
> ohaya@cox.net wrote:
> > ---- "André Warnier" <aw...@ice-sa.com> wrote:
> >> ohaya@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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password" authentication?
Posted by André Warnier <aw...@ice-sa.com>.
ohaya@cox.net wrote:
> ---- "André Warnier" <aw...@ice-sa.com> wrote:
>> ohaya@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..
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password"
authentication?
Posted by oh...@cox.net.
---- "André Warnier" <aw...@ice-sa.com> wrote:
> ohaya@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...
Thanks,
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password" authentication?
Posted by André Warnier <aw...@ice-sa.com>.
ohaya@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)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password"
authentication?
Posted by oh...@cox.net.
---- ohaya@cox.net wrote:
>
> ---- Christopher Schultz <ch...@christopherschultz.net> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Jim,
> >
> > On 12/2/11 11:26 AM, ohaya@cox.net wrote:
> > > Sure. Here's the section from httpd.conf. This is testing where I
> > > purposely insert a "REMOTE_USER" HTTP header into the request
> > > being proxied. As I said, I have a sniffer on the line, and I can
> > > see the REMOTE_USER header, but still, when I get to my test JSP
> > > hosted on the Tomcat, getUserPrincipal() is returning null (don't
> > > mind the hostname in the ProxyPass, etc. I just happen to be
> > > hosting Tomcat on that machine, and WebLogic is shutdown there).
> >
> > The problem is that AJP sends the authentication information as part
> > of the AJP protocol, not as a request header. You are setting a
> > request header which is not the mechanism AJP uses to transfer the userid.
> >
> > You might want to check to see if your SSO module works the way that
> > other httpd modules expect -- like the other mod_auth_[xyz], for instance.
> >
> > See http://tomcat.apache.org/connectors-doc/reference/apache.html.
> > Specifically, the JkRemoteUserIndicator directive which allows you to
> > override the environment variable whose value will be used to
> > send-over the username to Tomcat.
> >
> > I wouldn't think you'd have to do that (REMOTE_USER should already be
> > set by your auth module and mod_proxy_jk should already be using
> > that), but you might be able to force it for some testing.
> >
> > - -chris
>
>
> Chris,
>
> FYI, that link you posted give as 404 error.
>
> To be clear, in the discussion before now, I was just using mod_ajp (built into/included with Apache), and NOT mod_jk.
>
> I'm now in the process of trying to switch my Apache conf to use mod_jk. 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. I've been checking, and there's very little (= none) that I can do with trying to change the OAM webgate behavior, and if it's not setting whatever Apache/AJP needs, then I'm stuck, so I'm trying mod_jk, hoping that that'll give me some way to set what AJP needs.
>
> Now that I'm doing that, I'm starting to remember how confusing (to me at least) configuring mod_jk is :) (vs. mod_ajp).
>
> I just got the initial part of the re-configuration done. I got the mod_jk.so (my test Apache is on Windows, BTW), and added the LoadModule. I have the Apache pointed to a new simple workers.properties file, and the Apache comes up, but it doesn't seem to be proxing my test URLs to the Tomcat anymore (/samplesajp/*).
>
> Here's what I added to my Apache httpd.conf:
>
>
> # 2011-12-02 - ADDING MOD_JK
> LoadModule jk_module modules/mod_jk.so
> JkWorkersFile c:/Apache2.2/conf/workers.properties
> # some other configuration
> JkLogFile "c:/Apache2.2/logs/jk.log"
> JkLogLevel debug
> JkShmFile c:/Apache2.2/logs/jk.shm
> JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories
> # forwarding URL prefixes to Tomcat instances
> JkMount /samplesajp/* tomcatA
>
> JkEnvVar REMOTE_USER
>
>
> And, here's the workers.properties:
>
>
> <IfModule mod_jk.c>
> # a list of Tomcat instances
> #JkWorkerProperty worker.list=tomcatA
> worker.list=tomcatA
> # connection properties to instance A on localhost
> # JkWorkerProperty worker.tomcatA.type=ajp13
> # JkWorkerProperty worker.tomcatA.host=weblogic1.whatever.com
> # JkWorkerProperty worker.tomcatA.port=8009
> worker.tomcatA.type=ajp13
> worker.tomcatA.host=weblogic1.whatever.com
> worker.tomcatA.port=8009
>
> </IfModule>
>
>
> And, here's what I'm seeing in jk.log when I try to access my test URL (via the Apache):
>
Hi,
I stripped the jk.log stuff (too long) above.
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?
Thanks,
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password"
authentication?
Posted by oh...@cox.net.
---- Christopher Schultz <ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jim,
>
> On 12/2/11 11:26 AM, ohaya@cox.net wrote:
> > Sure. Here's the section from httpd.conf. This is testing where I
> > purposely insert a "REMOTE_USER" HTTP header into the request
> > being proxied. As I said, I have a sniffer on the line, and I can
> > see the REMOTE_USER header, but still, when I get to my test JSP
> > hosted on the Tomcat, getUserPrincipal() is returning null (don't
> > mind the hostname in the ProxyPass, etc. I just happen to be
> > hosting Tomcat on that machine, and WebLogic is shutdown there).
>
> The problem is that AJP sends the authentication information as part
> of the AJP protocol, not as a request header. You are setting a
> request header which is not the mechanism AJP uses to transfer the userid.
>
> You might want to check to see if your SSO module works the way that
> other httpd modules expect -- like the other mod_auth_[xyz], for instance.
>
> See http://tomcat.apache.org/connectors-doc/reference/apache.html.
> Specifically, the JkRemoteUserIndicator directive which allows you to
> override the environment variable whose value will be used to
> send-over the username to Tomcat.
>
> I wouldn't think you'd have to do that (REMOTE_USER should already be
> set by your auth module and mod_proxy_jk should already be using
> that), but you might be able to force it for some testing.
>
> - -chris
Chris,
FYI, that link you posted give as 404 error.
To be clear, in the discussion before now, I was just using mod_ajp (built into/included with Apache), and NOT mod_jk.
I'm now in the process of trying to switch my Apache conf to use mod_jk. 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. I've been checking, and there's very little (= none) that I can do with trying to change the OAM webgate behavior, and if it's not setting whatever Apache/AJP needs, then I'm stuck, so I'm trying mod_jk, hoping that that'll give me some way to set what AJP needs.
Now that I'm doing that, I'm starting to remember how confusing (to me at least) configuring mod_jk is :) (vs. mod_ajp).
I just got the initial part of the re-configuration done. I got the mod_jk.so (my test Apache is on Windows, BTW), and added the LoadModule. I have the Apache pointed to a new simple workers.properties file, and the Apache comes up, but it doesn't seem to be proxing my test URLs to the Tomcat anymore (/samplesajp/*).
Here's what I added to my Apache httpd.conf:
# 2011-12-02 - ADDING MOD_JK
LoadModule jk_module modules/mod_jk.so
JkWorkersFile c:/Apache2.2/conf/workers.properties
# some other configuration
JkLogFile "c:/Apache2.2/logs/jk.log"
JkLogLevel debug
JkShmFile c:/Apache2.2/logs/jk.shm
JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories
# forwarding URL prefixes to Tomcat instances
JkMount /samplesajp/* tomcatA
JkEnvVar REMOTE_USER
And, here's the workers.properties:
<IfModule mod_jk.c>
# a list of Tomcat instances
#JkWorkerProperty worker.list=tomcatA
worker.list=tomcatA
# connection properties to instance A on localhost
# JkWorkerProperty worker.tomcatA.type=ajp13
# JkWorkerProperty worker.tomcatA.host=weblogic1.whatever.com
# JkWorkerProperty worker.tomcatA.port=8009
worker.tomcatA.type=ajp13
worker.tomcatA.host=weblogic1.whatever.com
worker.tomcatA.port=8009
</IfModule>
And, here's what I'm seeing in jk.log when I try to access my test URL (via the Apache):
[Fri Dec 02 14:04:26.468 2011] [444:1724] [debug] jk_set_time_fmt::jk_util.c (459): Pre-processed log time stamp format is '[%a %b %d %H:%M:%S.000 %Y] '
[Fri Dec 02 14:04:26.468 2011] [444:1724] [debug] uri_worker_map_open::jk_uri_worker_map.c (770): rule map size is 1
[Fri Dec 02 14:04:26.468 2011] [444:1724] [debug] uri_worker_map_add::jk_uri_worker_map.c (720): wildchar rule '/samplesajp/*=tomcatA' source 'JkMount' was added
[Fri Dec 02 14:04:26.468 2011] [444:1724] [debug] uri_worker_map_dump::jk_uri_worker_map.c (171): uri map dump after map open: index=0 file='(null)' reject_unsafe=0 reload=60 modified=0 checked=0
[Fri Dec 02 14:04:26.468 2011] [444:1724] [debug] uri_worker_map_dump::jk_uri_worker_map.c (176): generation 0: size=0 nosize=0 capacity=0
[Fri Dec 02 14:04:26.468 2011] [444:1724] [debug] uri_worker_map_dump::jk_uri_worker_map.c (176): generation 1: size=1 nosize=0 capacity=4
[Fri Dec 02 14:04:26.468 2011] [444:1724] [debug] uri_worker_map_dump::jk_uri_worker_map.c (186): NEXT (1) map #0: uri=/samplesajp/* worker=tomcatA context=/samplesajp/* source=JkMount type=Wildchar len=13
[Fri Dec 02 14:04:26.468 2011] [444:1724] [debug] jk_set_time_fmt::jk_util.c (459): Pre-processed log time stamp format is '[%a %b %d %H:%M:%S.000 %Y] '
[Fri Dec 02 14:04:26.468 2011] [444:1724] [debug] init_jk::mod_jk.c (3179): Not using locking.
[Fri Dec 02 14:04:26.468 2011] [444:1724] [debug] init_jk::mod_jk.c (3191): Setting default connection pool max size to 250
[Fri Dec 02 14:04:26.468 2011] [444:1724] [debug] jk_map_read_property::jk_map.c (491): Adding property 'worker.list' with value 'tomcatA' to map.
[Fri Dec 02 14:04:26.468 2011] [444:1724] [debug] jk_map_read_property::jk_map.c (491): Adding property 'worker.tomcatA.type' with value 'ajp13' to map.
[Fri Dec 02 14:04:26.468 2011] [444:1724] [debug] jk_map_read_property::jk_map.c (491): Adding property 'worker.tomcatA.host' with value 'weblogic1.whatever.com' to map.
[Fri Dec 02 14:04:26.468 2011] [444:1724] [debug] jk_map_read_property::jk_map.c (491): Adding property 'worker.tomcatA.port' with value '8009' to map.
[Fri Dec 02 14:04:26.468 2011] [444:1724] [debug] jk_map_resolve_references::jk_map.c (779): Checking for references with prefix worker. with wildcard (recursion 1)
[Fri Dec 02 14:04:26.468 2011] [444:1724] [debug] jk_shm_calculate_size::jk_shm.c (132): shared memory will contain 1 ajp workers of size 320 and 0 lb workers of size 320 with 0 members of size 384+320
[Fri Dec 02 14:04:26.468 2011] [444:1724] [debug] jk_shm_open::jk_shm.c (254): Initialized shared memory C:/Apache2.2/logs/jk.shm size=448 free=320 addr=0xb10000
[Fri Dec 02 14:04:26.468 2011] [444:1724] [debug] jk_map_dump::jk_map.c (589): Dump of map: 'ServerRoot' -> 'C:/Apache2.2'
[Fri Dec 02 14:04:26.468 2011] [444:1724] [debug] jk_map_dump::jk_map.c (589): Dump of map: 'worker.list' -> 'tomcatA'
[Fri Dec 02 14:04:26.468 2011] [444:1724] [debug] jk_map_dump::jk_map.c (589): Dump of map: 'worker.tomcatA.type' -> 'ajp13'
[Fri Dec 02 14:04:26.468 2011] [444:1724] [debug] jk_map_dump::jk_map.c (589): Dump of map: 'worker.tomcatA.host' -> 'weblogic1.whatever.com'
[Fri Dec 02 14:04:26.468 2011] [444:1724] [debug] jk_map_dump::jk_map.c (589): Dump of map: 'worker.tomcatA.port' -> '8009'
[Fri Dec 02 14:04:26.468 2011] [444:1724] [debug] build_worker_map::jk_worker.c (242): creating worker tomcatA
[Fri Dec 02 14:04:26.468 2011] [444:1724] [debug] wc_create_worker::jk_worker.c (146): about to create instance tomcatA of ajp13
[Fri Dec 02 14:04:26.468 2011] [444:1724] [debug] wc_create_worker::jk_worker.c (159): about to validate and init tomcatA
[Fri Dec 02 14:04:26.468 2011] [444:1724] [debug] ajp_validate::jk_ajp_common.c (2672): worker tomcatA contact is 'weblogic1.whatever.com:8009'
[Fri Dec 02 14:04:26.468 2011] [444:1724] [debug] ajp_init::jk_ajp_common.c (2868): setting endpoint options:
[Fri Dec 02 14:04:26.468 2011] [444:1724] [debug] ajp_init::jk_ajp_common.c (2871): keepalive: 0
[Fri Dec 02 14:04:26.468 2011] [444:1724] [debug] ajp_init::jk_ajp_common.c (2875): socket timeout: 0
[Fri Dec 02 14:04:26.468 2011] [444:1724] [debug] ajp_init::jk_ajp_common.c (2879): socket connect timeout: 0
[Fri Dec 02 14:04:26.468 2011] [444:1724] [debug] ajp_init::jk_ajp_common.c (2883): buffer size: 0
[Fri Dec 02 14:04:26.468 2011] [444:1724] [debug] ajp_init::jk_ajp_common.c (2887): pool timeout: 0
[Fri Dec 02 14:04:26.468 2011] [444:1724] [debug] ajp_init::jk_ajp_common.c (2891): ping timeout: 10000
[Fri Dec 02 14:04:26.468 2011] [444:1724] [debug] ajp_init::jk_ajp_common.c (2895): connect timeout: 0
[Fri Dec 02 14:04:26.468 2011] [444:1724] [debug] ajp_init::jk_ajp_common.c (2899): reply timeout: 0
[Fri Dec 02 14:04:26.468 2011] [444:1724] [debug] ajp_init::jk_ajp_common.c (2903): prepost timeout: 0
[Fri Dec 02 14:04:26.468 2011] [444:1724] [debug] ajp_init::jk_ajp_common.c (2907): recovery options: 0
[Fri Dec 02 14:04:26.468 2011] [444:1724] [debug] ajp_init::jk_ajp_common.c (2911): retries: 2
[Fri Dec 02 14:04:26.468 2011] [444:1724] [debug] ajp_init::jk_ajp_common.c (2915): max packet size: 8192
[Fri Dec 02 14:04:26.468 2011] [444:1724] [debug] ajp_init::jk_ajp_common.c (2919): retry interval: 100
[Fri Dec 02 14:04:26.468 2011] [444:1724] [debug] ajp_create_endpoint_cache::jk_ajp_common.c (2729): setting connection pool size to 250 with min 125 and acquire timeout 200
[Fri Dec 02 14:04:26.478 2011] [444:1724] [info] init_jk::mod_jk.c (3252): mod_jk/1.2.32 () initialized
[Fri Dec 02 14:04:26.478 2011] [444:1724] [debug] wc_get_worker_for_name::jk_worker.c (116): found a worker tomcatA
[Fri Dec 02 14:04:26.478 2011] [444:1724] [debug] wc_get_name_for_type::jk_worker.c (293): Found worker type 'ajp13'
[Fri Dec 02 14:04:26.478 2011] [444:1724] [debug] uri_worker_map_ext::jk_uri_worker_map.c (512): Checking extension for worker 0: tomcatA of type ajp13 (2)
[Fri Dec 02 14:04:26.478 2011] [444:1724] [debug] uri_worker_map_dump::jk_uri_worker_map.c (171): uri map dump after extension stripping: index=0 file='(null)' reject_unsafe=0 reload=60 modified=0 checked=0
[Fri Dec 02 14:04:26.478 2011] [444:1724] [debug] uri_worker_map_dump::jk_uri_worker_map.c (176): generation 0: size=0 nosize=0 capacity=0
[Fri Dec 02 14:04:26.478 2011] [444:1724] [debug] uri_worker_map_dump::jk_uri_worker_map.c (176): generation 1: size=1 nosize=0 capacity=4
[Fri Dec 02 14:04:26.478 2011] [444:1724] [debug] uri_worker_map_dump::jk_uri_worker_map.c (186): NEXT (1) map #0: uri=/samplesajp/* worker=tomcatA context=/samplesajp/* source=JkMount type=Wildchar len=13
[Fri Dec 02 14:04:26.478 2011] [444:1724] [debug] uri_worker_map_switch::jk_uri_worker_map.c (482): Switching uri worker map from index 0 to index 1
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] jk_set_time_fmt::jk_util.c (459): Pre-processed log time stamp format is '[%a %b %d %H:%M:%S.000 %Y] '
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] uri_worker_map_open::jk_uri_worker_map.c (770): rule map size is 1
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] uri_worker_map_add::jk_uri_worker_map.c (720): wildchar rule '/samplesajp/*=tomcatA' source 'JkMount' was added
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] uri_worker_map_dump::jk_uri_worker_map.c (171): uri map dump after map open: index=0 file='(null)' reject_unsafe=0 reload=60 modified=0 checked=0
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] uri_worker_map_dump::jk_uri_worker_map.c (176): generation 0: size=0 nosize=0 capacity=0
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] uri_worker_map_dump::jk_uri_worker_map.c (176): generation 1: size=1 nosize=0 capacity=4
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] uri_worker_map_dump::jk_uri_worker_map.c (186): NEXT (1) map #0: uri=/samplesajp/* worker=tomcatA context=/samplesajp/* source=JkMount type=Wildchar len=13
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] jk_set_time_fmt::jk_util.c (459): Pre-processed log time stamp format is '[%a %b %d %H:%M:%S.000 %Y] '
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] init_jk::mod_jk.c (3179): Not using locking.
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] init_jk::mod_jk.c (3191): Setting default connection pool max size to 250
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] jk_map_read_property::jk_map.c (491): Adding property 'worker.list' with value 'tomcatA' to map.
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] jk_map_read_property::jk_map.c (491): Adding property 'worker.tomcatA.type' with value 'ajp13' to map.
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] jk_map_read_property::jk_map.c (491): Adding property 'worker.tomcatA.host' with value 'weblogic1.whatever.com' to map.
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] jk_map_read_property::jk_map.c (491): Adding property 'worker.tomcatA.port' with value '8009' to map.
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] jk_map_resolve_references::jk_map.c (779): Checking for references with prefix worker. with wildcard (recursion 1)
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] jk_shm_calculate_size::jk_shm.c (132): shared memory will contain 1 ajp workers of size 320 and 0 lb workers of size 320 with 0 members of size 384+320
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] jk_shm_open::jk_shm.c (254): Initialized shared memory C:/Apache2.2/logs/jk.shm size=448 free=320 addr=0x1870000
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] jk_map_dump::jk_map.c (589): Dump of map: 'ServerRoot' -> 'C:/Apache2.2'
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] jk_map_dump::jk_map.c (589): Dump of map: 'worker.list' -> 'tomcatA'
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] jk_map_dump::jk_map.c (589): Dump of map: 'worker.tomcatA.type' -> 'ajp13'
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] jk_map_dump::jk_map.c (589): Dump of map: 'worker.tomcatA.host' -> 'weblogic1.whatever.com'
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] jk_map_dump::jk_map.c (589): Dump of map: 'worker.tomcatA.port' -> '8009'
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] build_worker_map::jk_worker.c (242): creating worker tomcatA
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] wc_create_worker::jk_worker.c (146): about to create instance tomcatA of ajp13
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] wc_create_worker::jk_worker.c (159): about to validate and init tomcatA
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] ajp_validate::jk_ajp_common.c (2672): worker tomcatA contact is 'weblogic1.whatever.com:8009'
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] ajp_init::jk_ajp_common.c (2868): setting endpoint options:
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] ajp_init::jk_ajp_common.c (2871): keepalive: 0
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] ajp_init::jk_ajp_common.c (2875): socket timeout: 0
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] ajp_init::jk_ajp_common.c (2879): socket connect timeout: 0
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] ajp_init::jk_ajp_common.c (2883): buffer size: 0
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] ajp_init::jk_ajp_common.c (2887): pool timeout: 0
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] ajp_init::jk_ajp_common.c (2891): ping timeout: 10000
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] ajp_init::jk_ajp_common.c (2895): connect timeout: 0
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] ajp_init::jk_ajp_common.c (2899): reply timeout: 0
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] ajp_init::jk_ajp_common.c (2903): prepost timeout: 0
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] ajp_init::jk_ajp_common.c (2907): recovery options: 0
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] ajp_init::jk_ajp_common.c (2911): retries: 2
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] ajp_init::jk_ajp_common.c (2915): max packet size: 8192
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] ajp_init::jk_ajp_common.c (2919): retry interval: 100
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] ajp_create_endpoint_cache::jk_ajp_common.c (2729): setting connection pool size to 250 with min 125 and acquire timeout 200
[Fri Dec 02 14:04:26.769 2011] [444:1724] [info] init_jk::mod_jk.c (3252): mod_jk/1.2.32 () initialized
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] wc_get_worker_for_name::jk_worker.c (116): found a worker tomcatA
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] wc_get_name_for_type::jk_worker.c (293): Found worker type 'ajp13'
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] uri_worker_map_ext::jk_uri_worker_map.c (512): Checking extension for worker 0: tomcatA of type ajp13 (2)
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] uri_worker_map_dump::jk_uri_worker_map.c (171): uri map dump after extension stripping: index=0 file='(null)' reject_unsafe=0 reload=60 modified=0 checked=0
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] uri_worker_map_dump::jk_uri_worker_map.c (176): generation 0: size=0 nosize=0 capacity=0
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] uri_worker_map_dump::jk_uri_worker_map.c (176): generation 1: size=1 nosize=0 capacity=4
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] uri_worker_map_dump::jk_uri_worker_map.c (186): NEXT (1) map #0: uri=/samplesajp/* worker=tomcatA context=/samplesajp/* source=JkMount type=Wildchar len=13
[Fri Dec 02 14:04:26.769 2011] [444:1724] [debug] uri_worker_map_switch::jk_uri_worker_map.c (482): Switching uri worker map from index 0 to index 1
[Fri Dec 02 14:04:26.979 2011] [744:732] [debug] jk_set_time_fmt::jk_util.c (459): Pre-processed log time stamp format is '[%a %b %d %H:%M:%S.000 %Y] '
[Fri Dec 02 14:04:26.979 2011] [744:732] [debug] uri_worker_map_open::jk_uri_worker_map.c (770): rule map size is 1
[Fri Dec 02 14:04:26.979 2011] [744:732] [debug] uri_worker_map_add::jk_uri_worker_map.c (720): wildchar rule '/samplesajp/*=tomcatA' source 'JkMount' was added
[Fri Dec 02 14:04:26.979 2011] [744:732] [debug] uri_worker_map_dump::jk_uri_worker_map.c (171): uri map dump after map open: index=0 file='(null)' reject_unsafe=0 reload=60 modified=0 checked=0
[Fri Dec 02 14:04:26.979 2011] [744:732] [debug] uri_worker_map_dump::jk_uri_worker_map.c (176): generation 0: size=0 nosize=0 capacity=0
[Fri Dec 02 14:04:26.979 2011] [744:732] [debug] uri_worker_map_dump::jk_uri_worker_map.c (176): generation 1: size=1 nosize=0 capacity=4
[Fri Dec 02 14:04:26.979 2011] [744:732] [debug] uri_worker_map_dump::jk_uri_worker_map.c (186): NEXT (1) map #0: uri=/samplesajp/* worker=tomcatA context=/samplesajp/* source=JkMount type=Wildchar len=13
[Fri Dec 02 14:04:26.979 2011] [744:732] [debug] jk_set_time_fmt::jk_util.c (459): Pre-processed log time stamp format is '[%a %b %d %H:%M:%S.000 %Y] '
[Fri Dec 02 14:04:26.979 2011] [744:732] [debug] init_jk::mod_jk.c (3179): Not using locking.
[Fri Dec 02 14:04:26.979 2011] [744:732] [debug] init_jk::mod_jk.c (3191): Setting default connection pool max size to 250
[Fri Dec 02 14:04:26.979 2011] [744:732] [debug] jk_map_read_property::jk_map.c (491): Adding property 'worker.list' with value 'tomcatA' to map.
[Fri Dec 02 14:04:26.979 2011] [744:732] [debug] jk_map_read_property::jk_map.c (491): Adding property 'worker.tomcatA.type' with value 'ajp13' to map.
[Fri Dec 02 14:04:26.979 2011] [744:732] [debug] jk_map_read_property::jk_map.c (491): Adding property 'worker.tomcatA.host' with value 'weblogic1.whatever.com' to map.
[Fri Dec 02 14:04:26.979 2011] [744:732] [debug] jk_map_read_property::jk_map.c (491): Adding property 'worker.tomcatA.port' with value '8009' to map.
[Fri Dec 02 14:04:26.979 2011] [744:732] [debug] jk_map_resolve_references::jk_map.c (779): Checking for references with prefix worker. with wildcard (recursion 1)
[Fri Dec 02 14:04:26.979 2011] [744:732] [debug] jk_shm_calculate_size::jk_shm.c (132): shared memory will contain 1 ajp workers of size 320 and 0 lb workers of size 320 with 0 members of size 384+320
[Fri Dec 02 14:04:26.979 2011] [744:732] [debug] jk_shm_open::jk_shm.c (244): Resetting the shared memory for child 2
[Fri Dec 02 14:04:26.979 2011] [744:732] [debug] jk_shm_open::jk_shm.c (254): Attached shared memory C:/Apache2.2/logs/jk.shm size=448 free=320 addr=0xa50000
[Fri Dec 02 14:04:26.979 2011] [744:732] [debug] jk_map_dump::jk_map.c (589): Dump of map: 'ServerRoot' -> 'C:/Apache2.2'
[Fri Dec 02 14:04:26.979 2011] [744:732] [debug] jk_map_dump::jk_map.c (589): Dump of map: 'worker.list' -> 'tomcatA'
[Fri Dec 02 14:04:26.979 2011] [744:732] [debug] jk_map_dump::jk_map.c (589): Dump of map: 'worker.tomcatA.type' -> 'ajp13'
[Fri Dec 02 14:04:26.979 2011] [744:732] [debug] jk_map_dump::jk_map.c (589): Dump of map: 'worker.tomcatA.host' -> 'weblogic1.whatever.com'
[Fri Dec 02 14:04:26.979 2011] [744:732] [debug] jk_map_dump::jk_map.c (589): Dump of map: 'worker.tomcatA.port' -> '8009'
[Fri Dec 02 14:04:26.979 2011] [744:732] [debug] build_worker_map::jk_worker.c (242): creating worker tomcatA
[Fri Dec 02 14:04:26.979 2011] [744:732] [debug] wc_create_worker::jk_worker.c (146): about to create instance tomcatA of ajp13
[Fri Dec 02 14:04:26.979 2011] [744:732] [debug] wc_create_worker::jk_worker.c (159): about to validate and init tomcatA
[Fri Dec 02 14:04:26.979 2011] [744:732] [debug] ajp_validate::jk_ajp_common.c (2672): worker tomcatA contact is 'weblogic1.whatever.com:8009'
[Fri Dec 02 14:04:26.989 2011] [744:732] [debug] ajp_init::jk_ajp_common.c (2868): setting endpoint options:
[Fri Dec 02 14:04:26.989 2011] [744:732] [debug] ajp_init::jk_ajp_common.c (2871): keepalive: 0
[Fri Dec 02 14:04:26.989 2011] [744:732] [debug] ajp_init::jk_ajp_common.c (2875): socket timeout: 0
[Fri Dec 02 14:04:26.989 2011] [744:732] [debug] ajp_init::jk_ajp_common.c (2879): socket connect timeout: 0
[Fri Dec 02 14:04:26.989 2011] [744:732] [debug] ajp_init::jk_ajp_common.c (2883): buffer size: 0
[Fri Dec 02 14:04:26.989 2011] [744:732] [debug] ajp_init::jk_ajp_common.c (2887): pool timeout: 0
[Fri Dec 02 14:04:26.989 2011] [744:732] [debug] ajp_init::jk_ajp_common.c (2891): ping timeout: 10000
[Fri Dec 02 14:04:26.989 2011] [744:732] [debug] ajp_init::jk_ajp_common.c (2895): connect timeout: 0
[Fri Dec 02 14:04:26.989 2011] [744:732] [debug] ajp_init::jk_ajp_common.c (2899): reply timeout: 0
[Fri Dec 02 14:04:26.989 2011] [744:732] [debug] ajp_init::jk_ajp_common.c (2903): prepost timeout: 0
[Fri Dec 02 14:04:26.989 2011] [744:732] [debug] ajp_init::jk_ajp_common.c (2907): recovery options: 0
[Fri Dec 02 14:04:26.989 2011] [744:732] [debug] ajp_init::jk_ajp_common.c (2911): retries: 2
[Fri Dec 02 14:04:26.989 2011] [744:732] [debug] ajp_init::jk_ajp_common.c (2915): max packet size: 8192
[Fri Dec 02 14:04:26.989 2011] [744:732] [debug] ajp_init::jk_ajp_common.c (2919): retry interval: 100
[Fri Dec 02 14:04:26.989 2011] [744:732] [debug] ajp_create_endpoint_cache::jk_ajp_common.c (2729): setting connection pool size to 250 with min 125 and acquire timeout 200
[Fri Dec 02 14:04:26.989 2011] [744:732] [info] init_jk::mod_jk.c (3252): mod_jk/1.2.32 () initialized
[Fri Dec 02 14:04:26.989 2011] [744:732] [debug] wc_get_worker_for_name::jk_worker.c (116): found a worker tomcatA
[Fri Dec 02 14:04:26.989 2011] [744:732] [debug] wc_get_name_for_type::jk_worker.c (293): Found worker type 'ajp13'
[Fri Dec 02 14:04:26.989 2011] [744:732] [debug] uri_worker_map_ext::jk_uri_worker_map.c (512): Checking extension for worker 0: tomcatA of type ajp13 (2)
[Fri Dec 02 14:04:26.989 2011] [744:732] [debug] uri_worker_map_dump::jk_uri_worker_map.c (171): uri map dump after extension stripping: index=0 file='(null)' reject_unsafe=0 reload=60 modified=0 checked=0
[Fri Dec 02 14:04:26.989 2011] [744:732] [debug] uri_worker_map_dump::jk_uri_worker_map.c (176): generation 0: size=0 nosize=0 capacity=0
[Fri Dec 02 14:04:26.989 2011] [744:732] [debug] uri_worker_map_dump::jk_uri_worker_map.c (176): generation 1: size=1 nosize=0 capacity=4
[Fri Dec 02 14:04:26.989 2011] [744:732] [debug] uri_worker_map_dump::jk_uri_worker_map.c (186): NEXT (1) map #0: uri=/samplesajp/* worker=tomcatA context=/samplesajp/* source=JkMount type=Wildchar len=13
[Fri Dec 02 14:04:26.989 2011] [744:732] [debug] uri_worker_map_switch::jk_uri_worker_map.c (482): Switching uri worker map from index 0 to index 1
[Fri Dec 02 14:04:27.139 2011] [744:732] [debug] jk_set_time_fmt::jk_util.c (459): Pre-processed log time stamp format is '[%a %b %d %H:%M:%S.000 %Y] '
[Fri Dec 02 14:04:27.139 2011] [744:732] [debug] uri_worker_map_open::jk_uri_worker_map.c (770): rule map size is 1
[Fri Dec 02 14:04:27.139 2011] [744:732] [debug] uri_worker_map_add::jk_uri_worker_map.c (720): wildchar rule '/samplesajp/*=tomcatA' source 'JkMount' was added
[Fri Dec 02 14:04:27.139 2011] [744:732] [debug] uri_worker_map_dump::jk_uri_worker_map.c (171): uri map dump after map open: index=0 file='(null)' reject_unsafe=0 reload=60 modified=0 checked=0
[Fri Dec 02 14:04:27.139 2011] [744:732] [debug] uri_worker_map_dump::jk_uri_worker_map.c (176): generation 0: size=0 nosize=0 capacity=0
[Fri Dec 02 14:04:27.139 2011] [744:732] [debug] uri_worker_map_dump::jk_uri_worker_map.c (176): generation 1: size=1 nosize=0 capacity=4
[Fri Dec 02 14:04:27.139 2011] [744:732] [debug] uri_worker_map_dump::jk_uri_worker_map.c (186): NEXT (1) map #0: uri=/samplesajp/* worker=tomcatA context=/samplesajp/* source=JkMount type=Wildchar len=13
[Fri Dec 02 14:04:27.139 2011] [744:732] [debug] jk_set_time_fmt::jk_util.c (459): Pre-processed log time stamp format is '[%a %b %d %H:%M:%S.000 %Y] '
[Fri Dec 02 14:04:27.139 2011] [744:732] [debug] init_jk::mod_jk.c (3179): Not using locking.
[Fri Dec 02 14:04:27.139 2011] [744:732] [debug] init_jk::mod_jk.c (3191): Setting default connection pool max size to 250
[Fri Dec 02 14:04:27.139 2011] [744:732] [debug] jk_map_read_property::jk_map.c (491): Adding property 'worker.list' with value 'tomcatA' to map.
[Fri Dec 02 14:04:27.139 2011] [744:732] [debug] jk_map_read_property::jk_map.c (491): Adding property 'worker.tomcatA.type' with value 'ajp13' to map.
[Fri Dec 02 14:04:27.139 2011] [744:732] [debug] jk_map_read_property::jk_map.c (491): Adding property 'worker.tomcatA.host' with value 'weblogic1.whatever.com' to map.
[Fri Dec 02 14:04:27.139 2011] [744:732] [debug] jk_map_read_property::jk_map.c (491): Adding property 'worker.tomcatA.port' with value '8009' to map.
[Fri Dec 02 14:04:27.139 2011] [744:732] [debug] jk_map_resolve_references::jk_map.c (779): Checking for references with prefix worker. with wildcard (recursion 1)
[Fri Dec 02 14:04:27.139 2011] [744:732] [debug] jk_shm_calculate_size::jk_shm.c (132): shared memory will contain 1 ajp workers of size 320 and 0 lb workers of size 320 with 0 members of size 384+320
[Fri Dec 02 14:04:27.139 2011] [744:732] [debug] jk_shm_open::jk_shm.c (244): Resetting the shared memory for child 2
[Fri Dec 02 14:04:27.139 2011] [744:732] [debug] jk_shm_open::jk_shm.c (254): Attached shared memory C:/Apache2.2/logs/jk.shm size=448 free=320 addr=0x17b0000
[Fri Dec 02 14:04:27.139 2011] [744:732] [debug] jk_map_dump::jk_map.c (589): Dump of map: 'ServerRoot' -> 'C:/Apache2.2'
[Fri Dec 02 14:04:27.139 2011] [744:732] [debug] jk_map_dump::jk_map.c (589): Dump of map: 'worker.list' -> 'tomcatA'
[Fri Dec 02 14:04:27.139 2011] [744:732] [debug] jk_map_dump::jk_map.c (589): Dump of map: 'worker.tomcatA.type' -> 'ajp13'
[Fri Dec 02 14:04:27.139 2011] [744:732] [debug] jk_map_dump::jk_map.c (589): Dump of map: 'worker.tomcatA.host' -> 'weblogic1.whatever.com'
[Fri Dec 02 14:04:27.139 2011] [744:732] [debug] jk_map_dump::jk_map.c (589): Dump of map: 'worker.tomcatA.port' -> '8009'
[Fri Dec 02 14:04:27.139 2011] [744:732] [debug] build_worker_map::jk_worker.c (242): creating worker tomcatA
[Fri Dec 02 14:04:27.139 2011] [744:732] [debug] wc_create_worker::jk_worker.c (146): about to create instance tomcatA of ajp13
[Fri Dec 02 14:04:27.139 2011] [744:732] [debug] wc_create_worker::jk_worker.c (159): about to validate and init tomcatA
[Fri Dec 02 14:04:27.139 2011] [744:732] [debug] ajp_validate::jk_ajp_common.c (2672): worker tomcatA contact is 'weblogic1.whatever.com:8009'
[Fri Dec 02 14:04:27.139 2011] [744:732] [debug] ajp_init::jk_ajp_common.c (2868): setting endpoint options:
[Fri Dec 02 14:04:27.139 2011] [744:732] [debug] ajp_init::jk_ajp_common.c (2871): keepalive: 0
[Fri Dec 02 14:04:27.139 2011] [744:732] [debug] ajp_init::jk_ajp_common.c (2875): socket timeout: 0
[Fri Dec 02 14:04:27.139 2011] [744:732] [debug] ajp_init::jk_ajp_common.c (2879): socket connect timeout: 0
[Fri Dec 02 14:04:27.139 2011] [744:732] [debug] ajp_init::jk_ajp_common.c (2883): buffer size: 0
[Fri Dec 02 14:04:27.139 2011] [744:732] [debug] ajp_init::jk_ajp_common.c (2887): pool timeout: 0
[Fri Dec 02 14:04:27.139 2011] [744:732] [debug] ajp_init::jk_ajp_common.c (2891): ping timeout: 10000
[Fri Dec 02 14:04:27.139 2011] [744:732] [debug] ajp_init::jk_ajp_common.c (2895): connect timeout: 0
[Fri Dec 02 14:04:27.139 2011] [744:732] [debug] ajp_init::jk_ajp_common.c (2899): reply timeout: 0
[Fri Dec 02 14:04:27.139 2011] [744:732] [debug] ajp_init::jk_ajp_common.c (2903): prepost timeout: 0
[Fri Dec 02 14:04:27.139 2011] [744:732] [debug] ajp_init::jk_ajp_common.c (2907): recovery options: 0
[Fri Dec 02 14:04:27.139 2011] [744:732] [debug] ajp_init::jk_ajp_common.c (2911): retries: 2
[Fri Dec 02 14:04:27.139 2011] [744:732] [debug] ajp_init::jk_ajp_common.c (2915): max packet size: 8192
[Fri Dec 02 14:04:27.139 2011] [744:732] [debug] ajp_init::jk_ajp_common.c (2919): retry interval: 100
[Fri Dec 02 14:04:27.139 2011] [744:732] [debug] ajp_create_endpoint_cache::jk_ajp_common.c (2729): setting connection pool size to 250 with min 125 and acquire timeout 200
[Fri Dec 02 14:04:27.149 2011] [744:732] [info] init_jk::mod_jk.c (3252): mod_jk/1.2.32 () initialized
[Fri Dec 02 14:04:27.149 2011] [744:732] [debug] wc_get_worker_for_name::jk_worker.c (116): found a worker tomcatA
[Fri Dec 02 14:04:27.149 2011] [744:732] [debug] wc_get_name_for_type::jk_worker.c (293): Found worker type 'ajp13'
[Fri Dec 02 14:04:27.149 2011] [744:732] [debug] uri_worker_map_ext::jk_uri_worker_map.c (512): Checking extension for worker 0: tomcatA of type ajp13 (2)
[Fri Dec 02 14:04:27.149 2011] [744:732] [debug] uri_worker_map_dump::jk_uri_worker_map.c (171): uri map dump after extension stripping: index=0 file='(null)' reject_unsafe=0 reload=60 modified=0 checked=0
[Fri Dec 02 14:04:27.149 2011] [744:732] [debug] uri_worker_map_dump::jk_uri_worker_map.c (176): generation 0: size=0 nosize=0 capacity=0
[Fri Dec 02 14:04:27.149 2011] [744:732] [debug] uri_worker_map_dump::jk_uri_worker_map.c (176): generation 1: size=1 nosize=0 capacity=4
[Fri Dec 02 14:04:27.149 2011] [744:732] [debug] uri_worker_map_dump::jk_uri_worker_map.c (186): NEXT (1) map #0: uri=/samplesajp/* worker=tomcatA context=/samplesajp/* source=JkMount type=Wildchar len=13
[Fri Dec 02 14:04:27.149 2011] [744:732] [debug] uri_worker_map_switch::jk_uri_worker_map.c (482): Switching uri worker map from index 0 to index 1
[Fri Dec 02 14:04:27.149 2011] [744:732] [debug] jk_shm_open::jk_shm.c (158): Shared memory is already opened
[Fri Dec 02 14:04:27.149 2011] [744:732] [debug] jk_child_init::mod_jk.c (3136): Initialized mod_jk/1.2.32 ()
[Fri Dec 02 14:04:50.022 2011] [744:560] [debug] jk_translate::mod_jk.c (3488): missing uri map for apache1.whatever.com:/samplesajp/ssoAMTomcatTest.jsp
[Fri Dec 02 14:04:50.022 2011] [744:560] [debug] jk_map_to_storage::mod_jk.c (3647): missing uri map for apache1.whatever.com:/samplesajp/ssoAMTomcatTest.jsp
[Fri Dec 02 14:05:10.121 2011] [744:560] [debug] jk_translate::mod_jk.c (3488): missing uri map for apache1.whatever.com:/oam/server/obrareq.cgi
[Fri Dec 02 14:05:10.121 2011] [744:560] [debug] jk_map_to_storage::mod_jk.c (3647): missing uri map for apache1.whatever.com:/oam/server/obrareq.cgi
[Fri Dec 02 14:05:10.211 2011] [744:560] [debug] jk_translate::mod_jk.c (3488): missing uri map for apache1.whatever.com:/oam/CredCollectServlet/X509
[Fri Dec 02 14:05:10.211 2011] [744:560] [debug] jk_map_to_storage::mod_jk.c (3647): missing uri map for apache1.whatever.com:/oam/CredCollectServlet/X509
[Fri Dec 02 14:05:10.291 2011] [744:560] [debug] jk_translate::mod_jk.c (3488): missing uri map for apache1.whatever.com:/obrar.cgi
[Fri Dec 02 14:05:10.291 2011] [744:560] [debug] jk_map_to_storage::mod_jk.c (3647): missing uri map for apache1.whatever.com:/obrar.cgi
[Fri Dec 02 14:05:10.361 2011] [744:560] [debug] jk_translate::mod_jk.c (3488): missing uri map for apache1.whatever.com:/samplesajp/ssoAMTomcatTest.jsp
[Fri Dec 02 14:05:10.361 2011] [744:560] [debug] jk_map_to_storage::mod_jk.c (3647): missing uri map for apache1.whatever.com:/samplesajp/ssoAMTomcatTest.jsp
Shouldn't the one "JkMount /samplesajp/*" that I have be enough to proxy through the mod_jk?
Also, why is it appearing to try to process the "/oam/..." URIs?
Sorry again for the longish post :(...
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password" authentication?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jim,
On 12/2/11 11:26 AM, ohaya@cox.net wrote:
> Sure. Here's the section from httpd.conf. This is testing where I
> purposely insert a "REMOTE_USER" HTTP header into the request
> being proxied. As I said, I have a sniffer on the line, and I can
> see the REMOTE_USER header, but still, when I get to my test JSP
> hosted on the Tomcat, getUserPrincipal() is returning null (don't
> mind the hostname in the ProxyPass, etc. I just happen to be
> hosting Tomcat on that machine, and WebLogic is shutdown there).
The problem is that AJP sends the authentication information as part
of the AJP protocol, not as a request header. You are setting a
request header which is not the mechanism AJP uses to transfer the userid.
You might want to check to see if your SSO module works the way that
other httpd modules expect -- like the other mod_auth_[xyz], for instance.
See http://tomcat.apache.org/connectors-doc/reference/apache.html.
Specifically, the JkRemoteUserIndicator directive which allows you to
override the environment variable whose value will be used to
send-over the username to Tomcat.
I wouldn't think you'd have to do that (REMOTE_USER should already be
set by your auth module and mod_proxy_jk should already be using
that), but you might be able to force it for some testing.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7ZCWgACgkQ9CaO5/Lv0PDPWACgt07Uz0jf04GNXI9ws3aUOmnV
33gAoIh992DyrYkydFVdviUy2zlrQtue
=acs6
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password"
authentication?
Posted by oh...@cox.net.
---- Rainer Jung <ra...@kippdata.de> wrote:
> On 05.12.2011 10:42, ohaya@cox.net wrote:
> >
> > ---- "André Warnier"<aw...@ice-sa.com> wrote:
> >> ohaya@cox.net wrote:
> >> ...
> >>> ---- Rainer Jung<ra...@kippdata.de> wrote:
> >>>> Although this thread has moved forward towards the role topic, I want to
> >>>> give some infos about the user forwarding by mod_jk. Some of it was
> >>>> already present in previous posts.
> >>>>
> >>>> 1) In order to let Tomcat accept the user, you need to set
> >>>> tomcatAuthentication to "false"
> >>>>
> >>>> 2) mod_jk will always forward the user as detected by the
> >>>> following logic:
> >>>> - the user as authenticated by Apache
> >>>> - if this doesn't exist it will forward the value of
> >>>> an Apache environment variable. The default name of the
> >>>> variable is "JK_REMOTE_USER", but it can be changed using
> >>>> the configuration directive "JkRemoteUserIndicator"
> >>>>
> >>>> 3) The user ID will *not* be forwarded in the form of a request header
> >>>>
> >>>> 4) The forwarded user id is logged in the JK log file on level debug
> >>>> as the "user" field in the line:
> >>>>
> >>>> Service protocol=%s method=%s ssl=%s host=%s addr=%s name=%s port=%d
> >>>> auth=%s user=%s laddr=%s raddr=%s uri=%s
> >>>>
> >>>> 5) There is no need to use JkEnvVar
> >>>>
> >>>> 6) When not using a real Apache authentication, you can instead
> >>>> set the Apache environment variable JK_REMOTE_USER
> >>>> e.g. via mod_setenvif or the E= syntax of mod_rewrite.
> >>>> If you change the name of the env var using JkRemoteUserIndicator
> >>>> use the variable name given there instead.
> >>>>
> >>>> 7) The Apache authenticated user can be logged in the Apache AccessLog
> >>>> using "%u". Any environment variable XXX can be logged using
> >>>> %{XXX}e.
> >>>>
> >>>> 8) The user can be logged in the Tomcat AccessLog using %u.
> >>>>
> >>>> 9) The user is returned by request.getRemoteUser() on the Tomcat side.
> >>>>
> >>>> Regards,
> >>>>
> >>>> Rainer
> >>>>
> >>>
> >>>
> >>> Hi Rainier,
> >>>
> >>> Thanks for the great info above, esp. re. the JK_REMOTE_USER and JkRemoteUserIndicator.
> >>>
> >>> I'm kind of well along the way with my valve, but I still have mod_jk for one proxy section, so I'll give those a try.
> >>>
> >> Hi Rainer.
> >> Thanks also for the precise information. We've missed you..
> >>
> >> Jim, one more question :
> >> At the Apache httpd level, when the user has been authenticated by OAM, /can/ you get the
> >> authenticated user's user-id ? and how ?
> >>
> >>
> >
> > Hi,
> >
> > On the HTTP connection from Apache httpd to Tomcat, there's an HTTP header that gets populated by the OAM agent, called "OAM_REMOTE_USER".
>
> So if you want mod_jk to use the value of this header as the
> authenticated user name and forward it to Tomcat, you either:
>
> a) have to rely on the Oracle module to correctly set the Apache
> internal request user field
>
> b) or have to find a way to copy the value of this header into the
> environment variable JK_REMOTE_USER
>
> Concerning a): Usually there's %u in the default LogFormat used by
> AccessLog. So have a look at the access log to check, whether Apache
> outputs the correct user name. In that case mod_jk should automatically
> forward it. This in turn can be checked by the mentioned "Service" debug
> log line in the JK log.
>
> If %u in the access log is empty, and the docs of the Oracle module do
> not give a solution how to set the real Apache request user, we are up
> to b).
>
> First add %{OAM_REMOTE_USER} to the format/pattern configuration of your
> Apache and Tomcat access logs, so you can easily check, what both think
> about the value of that header. Check, that it is populated for both
> with the right user id.
>
> Now we try to copy the value of the header OAM_REMOTE_USER to the Apache
> environment variable JK_REMOTE_USER.
>
> As you can see in
>
> http://httpd.apache.org/docs/2.2/mod/mod_setenvif.html#setenvif
>
> It works like this (assuming you have enabled/loaded mod_setenvif):
>
> SetEnvIf OAM_REMOTE_USER (.*) JK_REMOTE_USER=$1
>
> Unfortunately this will only work, if the Oracle module that populates
> the header runs before mod_setenvif.
>
> Check, whether the copying works by adding %{JK_REMOTE_USER}e to the
> format of your Apache AccessLog.
>
> Finally look at the "Service" line in the jk debug log to see, whether
> the right user info is now being forwarded. If so, the rest is to be
> done in Tomcat land.
>
> Set tomcatAuthentication to "false" and check via
> request.getRemoteUser() whether you received the right user id.
>
> I would do all this first using a basic test webapp in Tomcat, not your
> real app.
>
> Finally: this is probably not secure, because
>
> - everyone can send a request which already has a populated
> OAM_REMOTE_USER header. You would rely on the implementation detail,
> that the Oracle module might always overwrite that header. Not sure if
> it does!
>
> - everyone having access to the network port could start talking AJP13
> directly to your Tomcat adding whatever remote user id she likes. The
> protocol is easy to fake.
>
> Regards,
>
> Rainer
>
Hi,
I've tried both SetEnvIf approach, and the setting JkRemoteUserIndicator, and have added the %{JK_REMOTE_USER}e to my Apache log config.
In all cases, that field in the logs is appearing as "", i.e., neither is working.
Also, in the JK log file, the "user=" is always showing up as "null".
So, I think that I'm going to be focusing on the valve approach, which appears to be working, aside from the roles problem (asserted roles vs. roles from Tomcat realm), which I've also been able to workaround by having my valve code authenticate to the realm.
Later,
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password" authentication?
Posted by Rainer Jung <ra...@kippdata.de>.
On 05.12.2011 10:42, ohaya@cox.net wrote:
>
> ---- "André Warnier"<aw...@ice-sa.com> wrote:
>> ohaya@cox.net wrote:
>> ...
>>> ---- Rainer Jung<ra...@kippdata.de> wrote:
>>>> Although this thread has moved forward towards the role topic, I want to
>>>> give some infos about the user forwarding by mod_jk. Some of it was
>>>> already present in previous posts.
>>>>
>>>> 1) In order to let Tomcat accept the user, you need to set
>>>> tomcatAuthentication to "false"
>>>>
>>>> 2) mod_jk will always forward the user as detected by the
>>>> following logic:
>>>> - the user as authenticated by Apache
>>>> - if this doesn't exist it will forward the value of
>>>> an Apache environment variable. The default name of the
>>>> variable is "JK_REMOTE_USER", but it can be changed using
>>>> the configuration directive "JkRemoteUserIndicator"
>>>>
>>>> 3) The user ID will *not* be forwarded in the form of a request header
>>>>
>>>> 4) The forwarded user id is logged in the JK log file on level debug
>>>> as the "user" field in the line:
>>>>
>>>> Service protocol=%s method=%s ssl=%s host=%s addr=%s name=%s port=%d
>>>> auth=%s user=%s laddr=%s raddr=%s uri=%s
>>>>
>>>> 5) There is no need to use JkEnvVar
>>>>
>>>> 6) When not using a real Apache authentication, you can instead
>>>> set the Apache environment variable JK_REMOTE_USER
>>>> e.g. via mod_setenvif or the E= syntax of mod_rewrite.
>>>> If you change the name of the env var using JkRemoteUserIndicator
>>>> use the variable name given there instead.
>>>>
>>>> 7) The Apache authenticated user can be logged in the Apache AccessLog
>>>> using "%u". Any environment variable XXX can be logged using
>>>> %{XXX}e.
>>>>
>>>> 8) The user can be logged in the Tomcat AccessLog using %u.
>>>>
>>>> 9) The user is returned by request.getRemoteUser() on the Tomcat side.
>>>>
>>>> Regards,
>>>>
>>>> Rainer
>>>>
>>>
>>>
>>> Hi Rainier,
>>>
>>> Thanks for the great info above, esp. re. the JK_REMOTE_USER and JkRemoteUserIndicator.
>>>
>>> I'm kind of well along the way with my valve, but I still have mod_jk for one proxy section, so I'll give those a try.
>>>
>> Hi Rainer.
>> Thanks also for the precise information. We've missed you..
>>
>> Jim, one more question :
>> At the Apache httpd level, when the user has been authenticated by OAM, /can/ you get the
>> authenticated user's user-id ? and how ?
>>
>>
>
> Hi,
>
> On the HTTP connection from Apache httpd to Tomcat, there's an HTTP header that gets populated by the OAM agent, called "OAM_REMOTE_USER".
So if you want mod_jk to use the value of this header as the
authenticated user name and forward it to Tomcat, you either:
a) have to rely on the Oracle module to correctly set the Apache
internal request user field
b) or have to find a way to copy the value of this header into the
environment variable JK_REMOTE_USER
Concerning a): Usually there's %u in the default LogFormat used by
AccessLog. So have a look at the access log to check, whether Apache
outputs the correct user name. In that case mod_jk should automatically
forward it. This in turn can be checked by the mentioned "Service" debug
log line in the JK log.
If %u in the access log is empty, and the docs of the Oracle module do
not give a solution how to set the real Apache request user, we are up
to b).
First add %{OAM_REMOTE_USER} to the format/pattern configuration of your
Apache and Tomcat access logs, so you can easily check, what both think
about the value of that header. Check, that it is populated for both
with the right user id.
Now we try to copy the value of the header OAM_REMOTE_USER to the Apache
environment variable JK_REMOTE_USER.
As you can see in
http://httpd.apache.org/docs/2.2/mod/mod_setenvif.html#setenvif
It works like this (assuming you have enabled/loaded mod_setenvif):
SetEnvIf OAM_REMOTE_USER (.*) JK_REMOTE_USER=$1
Unfortunately this will only work, if the Oracle module that populates
the header runs before mod_setenvif.
Check, whether the copying works by adding %{JK_REMOTE_USER}e to the
format of your Apache AccessLog.
Finally look at the "Service" line in the jk debug log to see, whether
the right user info is now being forwarded. If so, the rest is to be
done in Tomcat land.
Set tomcatAuthentication to "false" and check via
request.getRemoteUser() whether you received the right user id.
I would do all this first using a basic test webapp in Tomcat, not your
real app.
Finally: this is probably not secure, because
- everyone can send a request which already has a populated
OAM_REMOTE_USER header. You would rely on the implementation detail,
that the Oracle module might always overwrite that header. Not sure if
it does!
- everyone having access to the network port could start talking AJP13
directly to your Tomcat adding whatever remote user id she likes. The
protocol is easy to fake.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password"
authentication?
Posted by oh...@cox.net.
---- "André Warnier" <aw...@ice-sa.com> wrote:
> ohaya@cox.net wrote:
> ...
> > ---- Rainer Jung <ra...@kippdata.de> wrote:
> >> Although this thread has moved forward towards the role topic, I want to
> >> give some infos about the user forwarding by mod_jk. Some of it was
> >> already present in previous posts.
> >>
> >> 1) In order to let Tomcat accept the user, you need to set
> >> tomcatAuthentication to "false"
> >>
> >> 2) mod_jk will always forward the user as detected by the
> >> following logic:
> >> - the user as authenticated by Apache
> >> - if this doesn't exist it will forward the value of
> >> an Apache environment variable. The default name of the
> >> variable is "JK_REMOTE_USER", but it can be changed using
> >> the configuration directive "JkRemoteUserIndicator"
> >>
> >> 3) The user ID will *not* be forwarded in the form of a request header
> >>
> >> 4) The forwarded user id is logged in the JK log file on level debug
> >> as the "user" field in the line:
> >>
> >> Service protocol=%s method=%s ssl=%s host=%s addr=%s name=%s port=%d
> >> auth=%s user=%s laddr=%s raddr=%s uri=%s
> >>
> >> 5) There is no need to use JkEnvVar
> >>
> >> 6) When not using a real Apache authentication, you can instead
> >> set the Apache environment variable JK_REMOTE_USER
> >> e.g. via mod_setenvif or the E= syntax of mod_rewrite.
> >> If you change the name of the env var using JkRemoteUserIndicator
> >> use the variable name given there instead.
> >>
> >> 7) The Apache authenticated user can be logged in the Apache AccessLog
> >> using "%u". Any environment variable XXX can be logged using
> >> %{XXX}e.
> >>
> >> 8) The user can be logged in the Tomcat AccessLog using %u.
> >>
> >> 9) The user is returned by request.getRemoteUser() on the Tomcat side.
> >>
> >> Regards,
> >>
> >> Rainer
> >>
> >
> >
> > Hi Rainier,
> >
> > Thanks for the great info above, esp. re. the JK_REMOTE_USER and JkRemoteUserIndicator.
> >
> > I'm kind of well along the way with my valve, but I still have mod_jk for one proxy section, so I'll give those a try.
> >
> Hi Rainer.
> Thanks also for the precise information. We've missed you..
>
> Jim, one more question :
> At the Apache httpd level, when the user has been authenticated by OAM, /can/ you get the
> authenticated user's user-id ? and how ?
>
>
Hi,
On the HTTP connection from Apache httpd to Tomcat, there's an HTTP header that gets populated by the OAM agent, called "OAM_REMOTE_USER".
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password" authentication?
Posted by André Warnier <aw...@ice-sa.com>.
ohaya@cox.net wrote:
...
> ---- Rainer Jung <ra...@kippdata.de> wrote:
>> Although this thread has moved forward towards the role topic, I want to
>> give some infos about the user forwarding by mod_jk. Some of it was
>> already present in previous posts.
>>
>> 1) In order to let Tomcat accept the user, you need to set
>> tomcatAuthentication to "false"
>>
>> 2) mod_jk will always forward the user as detected by the
>> following logic:
>> - the user as authenticated by Apache
>> - if this doesn't exist it will forward the value of
>> an Apache environment variable. The default name of the
>> variable is "JK_REMOTE_USER", but it can be changed using
>> the configuration directive "JkRemoteUserIndicator"
>>
>> 3) The user ID will *not* be forwarded in the form of a request header
>>
>> 4) The forwarded user id is logged in the JK log file on level debug
>> as the "user" field in the line:
>>
>> Service protocol=%s method=%s ssl=%s host=%s addr=%s name=%s port=%d
>> auth=%s user=%s laddr=%s raddr=%s uri=%s
>>
>> 5) There is no need to use JkEnvVar
>>
>> 6) When not using a real Apache authentication, you can instead
>> set the Apache environment variable JK_REMOTE_USER
>> e.g. via mod_setenvif or the E= syntax of mod_rewrite.
>> If you change the name of the env var using JkRemoteUserIndicator
>> use the variable name given there instead.
>>
>> 7) The Apache authenticated user can be logged in the Apache AccessLog
>> using "%u". Any environment variable XXX can be logged using
>> %{XXX}e.
>>
>> 8) The user can be logged in the Tomcat AccessLog using %u.
>>
>> 9) The user is returned by request.getRemoteUser() on the Tomcat side.
>>
>> Regards,
>>
>> Rainer
>>
>
>
> Hi Rainier,
>
> Thanks for the great info above, esp. re. the JK_REMOTE_USER and JkRemoteUserIndicator.
>
> I'm kind of well along the way with my valve, but I still have mod_jk for one proxy section, so I'll give those a try.
>
Hi Rainer.
Thanks also for the precise information. We've missed you..
Jim, one more question :
At the Apache httpd level, when the user has been authenticated by OAM, /can/ you get the
authenticated user's user-id ? and how ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password"
authentication?
Posted by oh...@cox.net.
---- Rainer Jung <ra...@kippdata.de> wrote:
> On 02.12.2011 17:49, André Warnier wrote:
> > ohaya@cox.net wrote:
> >> ---- ohaya@cox.net wrote:
> >>> ---- "André Warnier" <aw...@ice-sa.com> wrote:
> >>>> ohaya@cox.net wrote:
> >>>> ...
> >>>>> <Connector port="8009" protocol="AJP/1.3" redirectPort="8443"
> >>>>> tomcatAuthentication="false" />
> >>>>>
> >>>> That is correct. The "false" means that Tomcat will not do it's own
> >>>> authentication, and will instead rely on the authenticated user-id
> >>>> passed by the front-end server.
> >>>>
> >>>> Now could you also show us the section of your Apache front-end
> >>>> configuration, containing the directives which forward the requests
> >>>> to Tomcat ?
> >>>> (proxy or rewrite stanzas)
> >>>>
> >>>> Note: the fact that the Apache/Tomcat connector (the one at the
> >>>> Apache level) passes the authenticated user-id to Tomcat along with
> >>>> the proxied request, depends on the fact that within Apache (more
> >>>> precisely within the internal Apache "request record"), the request
> >>>> is really authenticated (*).
> >>>> I am saying this because in an earlier post, you mentioned that you
> >>>> were using a third-party authentication package at the Apache httpd
> >>>> level.
> >>>> It is unlikely, but possible, that this authentication package would
> >>>> use its own logic, and never "populate" the internal Apache request
> >>>> record with this user-id (**).
> >>>> In such a case, the automatic forwarding of the user-id by the
> >>>> Apache-level connector module (mod_proxy_ajp or mod_jk) would of
> >>>> course not work, because they check the internal Apache request
> >>>> record, and have no knowledge of another user-id source.
> >>>>
> >>>>
> >>>> (*) in Tomcat terms, the equivalent of populating the userPrincipal
> >>>> object
> >>>> (**) for example, it may act as a filter, and rely on each request
> >>>> always containing a cookie which "authenticates" the request, and do
> >>>> its own access control independently of Apache httpd itself
> >>>>
> >>>
> >>> Andre,
> >>>
> >>> Sure. Here's the section from httpd.conf. This is testing where I
> >>> purposely insert a "REMOTE_USER" HTTP header into the request being
> >>> proxied. As I said, I have a sniffer on the line, and I can see the
> >>> REMOTE_USER header, but still, when I get to my test JSP hosted on
> >>> the Tomcat, getUserPrincipal() is returning null (don't mind the
> >>> hostname in the ProxyPass, etc. I just happen to be hosting Tomcat on
> >>> that machine, and WebLogic is shutdown there).
> >>>
> >>>
> >>> # Proxy to Tomcat on weblogic1 machine, using AJP
> >>> <Location /samplesajp>
> >>> RequestHeader set "REMOTE_USER" "222222229test111111111111"
> >>> ProxyPass ajp://weblogic1.whatever.com:8009/samplesajp
> >>> ProxyPassReverse ajp://weblogic1.whatever.com:8009/samplesajp
> >>> </Location>
> >>>
> >>> Jim
> >>>
> >>>
> >>
> >> Hi,
> >>
> >> BTW, I asked about this earlier, but is it possible to turn on some
> >> debugging on the Tomcat side, that might help diagnose why the AJP
> >> connector is not working the expected way? I'm not that familiar with
> >> Tomcat or AJP logging, but I've only been able to set logging in
> >> logging.properties so that there's either almost no logging or it
> >> generated a ton of logging (but not stuff on AJP
> >> connection/processing) :(...
> >>
> > Sorry, dunno. Logging is not my favorite area in Tomcat..
> >
> > Also, to tell the truth, I do not know exactly /how/ the Apache user-id
> > is passed to Tomcat. I strongly suspect that the "REMOTE_USER" HTTP
> > header may not be it, and that it may be via what Tomcat calls "request
> > attributes", and Apache calls "environment variables" (but not in the
> > usual shell sense). But I don't know how this particular one may be named.
> > Since you seem better at Java that I am, you may be able to find it in
> > the Tomcat AJP Connector code somewhere. I would start looking for
> > "request attribute" rather than "header".
> >
> > This page : http://tomcat.apache.org/connectors-doc/ajp/ajpv13a.html
> > seems to hint at ditto, and even mentions a request attribute named
> > "remote_user" (lowercase).
> >
> > Maybe you could try to set this "environment variable" in Apache, and
> > see where it leads you ?
> > In this page :
> > http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html#rewriterule
> > it shows how to do that (but there it calls them "server variables").
> > The terminology is not very consistent..
>
> Although this thread has moved forward towards the role topic, I want to
> give some infos about the user forwarding by mod_jk. Some of it was
> already present in previous posts.
>
> 1) In order to let Tomcat accept the user, you need to set
> tomcatAuthentication to "false"
>
> 2) mod_jk will always forward the user as detected by the
> following logic:
> - the user as authenticated by Apache
> - if this doesn't exist it will forward the value of
> an Apache environment variable. The default name of the
> variable is "JK_REMOTE_USER", but it can be changed using
> the configuration directive "JkRemoteUserIndicator"
>
> 3) The user ID will *not* be forwarded in the form of a request header
>
> 4) The forwarded user id is logged in the JK log file on level debug
> as the "user" field in the line:
>
> Service protocol=%s method=%s ssl=%s host=%s addr=%s name=%s port=%d
> auth=%s user=%s laddr=%s raddr=%s uri=%s
>
> 5) There is no need to use JkEnvVar
>
> 6) When not using a real Apache authentication, you can instead
> set the Apache environment variable JK_REMOTE_USER
> e.g. via mod_setenvif or the E= syntax of mod_rewrite.
> If you change the name of the env var using JkRemoteUserIndicator
> use the variable name given there instead.
>
> 7) The Apache authenticated user can be logged in the Apache AccessLog
> using "%u". Any environment variable XXX can be logged using
> %{XXX}e.
>
> 8) The user can be logged in the Tomcat AccessLog using %u.
>
> 9) The user is returned by request.getRemoteUser() on the Tomcat side.
>
> Regards,
>
> Rainer
>
Hi Rainier,
Thanks for the great info above, esp. re. the JK_REMOTE_USER and JkRemoteUserIndicator.
I'm kind of well along the way with my valve, but I still have mod_jk for one proxy section, so I'll give those a try.
Thanks again,
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password" authentication?
Posted by Rainer Jung <ra...@kippdata.de>.
On 02.12.2011 17:49, André Warnier wrote:
> ohaya@cox.net wrote:
>> ---- ohaya@cox.net wrote:
>>> ---- "André Warnier" <aw...@ice-sa.com> wrote:
>>>> ohaya@cox.net wrote:
>>>> ...
>>>>> <Connector port="8009" protocol="AJP/1.3" redirectPort="8443"
>>>>> tomcatAuthentication="false" />
>>>>>
>>>> That is correct. The "false" means that Tomcat will not do it's own
>>>> authentication, and will instead rely on the authenticated user-id
>>>> passed by the front-end server.
>>>>
>>>> Now could you also show us the section of your Apache front-end
>>>> configuration, containing the directives which forward the requests
>>>> to Tomcat ?
>>>> (proxy or rewrite stanzas)
>>>>
>>>> Note: the fact that the Apache/Tomcat connector (the one at the
>>>> Apache level) passes the authenticated user-id to Tomcat along with
>>>> the proxied request, depends on the fact that within Apache (more
>>>> precisely within the internal Apache "request record"), the request
>>>> is really authenticated (*).
>>>> I am saying this because in an earlier post, you mentioned that you
>>>> were using a third-party authentication package at the Apache httpd
>>>> level.
>>>> It is unlikely, but possible, that this authentication package would
>>>> use its own logic, and never "populate" the internal Apache request
>>>> record with this user-id (**).
>>>> In such a case, the automatic forwarding of the user-id by the
>>>> Apache-level connector module (mod_proxy_ajp or mod_jk) would of
>>>> course not work, because they check the internal Apache request
>>>> record, and have no knowledge of another user-id source.
>>>>
>>>>
>>>> (*) in Tomcat terms, the equivalent of populating the userPrincipal
>>>> object
>>>> (**) for example, it may act as a filter, and rely on each request
>>>> always containing a cookie which "authenticates" the request, and do
>>>> its own access control independently of Apache httpd itself
>>>>
>>>
>>> Andre,
>>>
>>> Sure. Here's the section from httpd.conf. This is testing where I
>>> purposely insert a "REMOTE_USER" HTTP header into the request being
>>> proxied. As I said, I have a sniffer on the line, and I can see the
>>> REMOTE_USER header, but still, when I get to my test JSP hosted on
>>> the Tomcat, getUserPrincipal() is returning null (don't mind the
>>> hostname in the ProxyPass, etc. I just happen to be hosting Tomcat on
>>> that machine, and WebLogic is shutdown there).
>>>
>>>
>>> # Proxy to Tomcat on weblogic1 machine, using AJP
>>> <Location /samplesajp>
>>> RequestHeader set "REMOTE_USER" "222222229test111111111111"
>>> ProxyPass ajp://weblogic1.whatever.com:8009/samplesajp
>>> ProxyPassReverse ajp://weblogic1.whatever.com:8009/samplesajp
>>> </Location>
>>>
>>> Jim
>>>
>>>
>>
>> Hi,
>>
>> BTW, I asked about this earlier, but is it possible to turn on some
>> debugging on the Tomcat side, that might help diagnose why the AJP
>> connector is not working the expected way? I'm not that familiar with
>> Tomcat or AJP logging, but I've only been able to set logging in
>> logging.properties so that there's either almost no logging or it
>> generated a ton of logging (but not stuff on AJP
>> connection/processing) :(...
>>
> Sorry, dunno. Logging is not my favorite area in Tomcat..
>
> Also, to tell the truth, I do not know exactly /how/ the Apache user-id
> is passed to Tomcat. I strongly suspect that the "REMOTE_USER" HTTP
> header may not be it, and that it may be via what Tomcat calls "request
> attributes", and Apache calls "environment variables" (but not in the
> usual shell sense). But I don't know how this particular one may be named.
> Since you seem better at Java that I am, you may be able to find it in
> the Tomcat AJP Connector code somewhere. I would start looking for
> "request attribute" rather than "header".
>
> This page : http://tomcat.apache.org/connectors-doc/ajp/ajpv13a.html
> seems to hint at ditto, and even mentions a request attribute named
> "remote_user" (lowercase).
>
> Maybe you could try to set this "environment variable" in Apache, and
> see where it leads you ?
> In this page :
> http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html#rewriterule
> it shows how to do that (but there it calls them "server variables").
> The terminology is not very consistent..
Although this thread has moved forward towards the role topic, I want to
give some infos about the user forwarding by mod_jk. Some of it was
already present in previous posts.
1) In order to let Tomcat accept the user, you need to set
tomcatAuthentication to "false"
2) mod_jk will always forward the user as detected by the
following logic:
- the user as authenticated by Apache
- if this doesn't exist it will forward the value of
an Apache environment variable. The default name of the
variable is "JK_REMOTE_USER", but it can be changed using
the configuration directive "JkRemoteUserIndicator"
3) The user ID will *not* be forwarded in the form of a request header
4) The forwarded user id is logged in the JK log file on level debug
as the "user" field in the line:
Service protocol=%s method=%s ssl=%s host=%s addr=%s name=%s port=%d
auth=%s user=%s laddr=%s raddr=%s uri=%s
5) There is no need to use JkEnvVar
6) When not using a real Apache authentication, you can instead
set the Apache environment variable JK_REMOTE_USER
e.g. via mod_setenvif or the E= syntax of mod_rewrite.
If you change the name of the env var using JkRemoteUserIndicator
use the variable name given there instead.
7) The Apache authenticated user can be logged in the Apache AccessLog
using "%u". Any environment variable XXX can be logged using
%{XXX}e.
8) The user can be logged in the Tomcat AccessLog using %u.
9) The user is returned by request.getRemoteUser() on the Tomcat side.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password"
authentication?
Posted by oh...@cox.net.
---- "André Warnier" <aw...@ice-sa.com> wrote:
> ohaya@cox.net wrote:
> > ---- ohaya@cox.net wrote:
> >> ---- "André Warnier" <aw...@ice-sa.com> wrote:
> >>> ohaya@cox.net wrote:
> >>> ...
> >>>> <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" tomcatAuthentication="false" />
> >>>>
> >>> That is correct. The "false" means that Tomcat will not do it's own authentication, and
> >>> will instead rely on the authenticated user-id passed by the front-end server.
> >>>
> >>> Now could you also show us the section of your Apache front-end configuration, containing
> >>> the directives which forward the requests to Tomcat ?
> >>> (proxy or rewrite stanzas)
> >>>
> >>> Note: the fact that the Apache/Tomcat connector (the one at the Apache level) passes the
> >>> authenticated user-id to Tomcat along with the proxied request, depends on the fact that
> >>> within Apache (more precisely within the internal Apache "request record"), the request is
> >>> really authenticated (*).
> >>> I am saying this because in an earlier post, you mentioned that you were using a
> >>> third-party authentication package at the Apache httpd level.
> >>> It is unlikely, but possible, that this authentication package would use its own logic,
> >>> and never "populate" the internal Apache request record with this user-id (**).
> >>> In such a case, the automatic forwarding of the user-id by the Apache-level connector
> >>> module (mod_proxy_ajp or mod_jk) would of course not work, because they check the internal
> >>> Apache request record, and have no knowledge of another user-id source.
> >>>
> >>>
> >>> (*) in Tomcat terms, the equivalent of populating the userPrincipal object
> >>> (**) for example, it may act as a filter, and rely on each request always containing a
> >>> cookie which "authenticates" the request, and do its own access control independently of
> >>> Apache httpd itself
> >>>
> >>
> >> Andre,
> >>
> >> Sure. Here's the section from httpd.conf. This is testing where I purposely insert a "REMOTE_USER" HTTP header into the request being proxied. As I said, I have a sniffer on the line, and I can see the REMOTE_USER header, but still, when I get to my test JSP hosted on the Tomcat, getUserPrincipal() is returning null (don't mind the hostname in the ProxyPass, etc. I just happen to be hosting Tomcat on that machine, and WebLogic is shutdown there).
> >>
> >>
> >> # Proxy to Tomcat on weblogic1 machine, using AJP
> >> <Location /samplesajp>
> >> RequestHeader set "REMOTE_USER" "222222229test111111111111"
> >> ProxyPass ajp://weblogic1.whatever.com:8009/samplesajp
> >> ProxyPassReverse ajp://weblogic1.whatever.com:8009/samplesajp
> >> </Location>
> >>
> >> Jim
> >>
> >>
> >
> > Hi,
> >
> > BTW, I asked about this earlier, but is it possible to turn on some debugging on the Tomcat side, that might help diagnose why the AJP connector is not working the expected way? I'm not that familiar with Tomcat or AJP logging, but I've only been able to set logging in logging.properties so that there's either almost no logging or it generated a ton of logging (but not stuff on AJP connection/processing) :(...
> >
> Sorry, dunno. Logging is not my favorite area in Tomcat..
>
> Also, to tell the truth, I do not know exactly /how/ the Apache user-id is passed to
> Tomcat. I strongly suspect that the "REMOTE_USER" HTTP header may not be it, and that it
> may be via what Tomcat calls "request attributes", and Apache calls "environment
> variables" (but not in the usual shell sense). But I don't know how this particular one
> may be named.
> Since you seem better at Java that I am, you may be able to find it in the Tomcat AJP
> Connector code somewhere. I would start looking for "request attribute" rather than "header".
>
> This page : http://tomcat.apache.org/connectors-doc/ajp/ajpv13a.html
> seems to hint at ditto, and even mentions a request attribute named "remote_user" (lowercase).
>
> Maybe you could try to set this "environment variable" in Apache, and see where it leads you ?
> In this page : http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html#rewriterule
> it shows how to do that (but there it calls them "server variables").
> The terminology is not very consistent..
>
>
>
>
Hi,
Ok, I'll take a look at those. FYI, I have debug level on the Apache side, and there is some stuff there, which I think confirms that I am indeed including REMOTE_USER in the requests to Tomcat/AJP:
[Fri Dec 02 02:55:41 2011] [debug] mod_proxy_ajp.c(44): proxy: AJP: canonicalising URL //weblogic1.whatever.com:8009/samplesajp/ssoAMTomcatTest.jsp
[Fri Dec 02 02:55:41 2011] [debug] proxy_util.c(1412): [client 192.168.0.7] proxy: ajp: found worker ajp://weblogic1.whatever.com:8009/samplesajp for ajp://weblogic1.whatever.com:8009/samplesajp/ssoAMTomcatTest.jsp
[Fri Dec 02 02:55:41 2011] [debug] mod_proxy.c(819): Running scheme ajp handler (attempt 0)
[Fri Dec 02 02:55:41 2011] [debug] mod_proxy_http.c(1683): proxy: HTTP: declining URL ajp://weblogic1.whatever.com:8009/samplesajp/ssoAMTomcatTest.jsp
[Fri Dec 02 02:55:41 2011] [debug] mod_proxy_ajp.c(520): proxy: AJP: serving URL ajp://weblogic1.whatever.com:8009/samplesajp/ssoAMTomcatTest.jsp
[Fri Dec 02 02:55:41 2011] [debug] proxy_util.c(1790): proxy: AJP: retrying the worker for (weblogic1.whatever.com)
[Fri Dec 02 02:55:41 2011] [debug] proxy_util.c(1796): proxy: AJP: worker for (weblogic1.whatever.com) has been marked for retry
[Fri Dec 02 02:55:41 2011] [debug] proxy_util.c(1852): proxy: AJP: has acquired connection for (weblogic1.whatever.com)
[Fri Dec 02 02:55:41 2011] [debug] proxy_util.c(1913): proxy: connecting ajp://weblogic1.whatever.com:8009/samplesajp/ssoAMTomcatTest.jsp to weblogic1.whatever.com:8009
[Fri Dec 02 02:55:41 2011] [debug] proxy_util.c(2012): proxy: connected /samplesajp/ssoAMTomcatTest.jsp to weblogic1.whatever.com:8009
[Fri Dec 02 02:55:41 2011] [debug] proxy_util.c(2169): proxy: AJP: fam 2 socket created to connect to weblogic1.whatever.com
[Fri Dec 02 02:55:41 2011] [debug] ajp_header.c(218): Into ajp_marshal_into_msgb
[Fri Dec 02 02:55:41 2011] [debug] ajp_header.c(284): ajp_marshal_into_msgb: Header[0] [Host] = [apache1.whatever.com]
[Fri Dec 02 02:55:41 2011] [debug] ajp_header.c(284): ajp_marshal_into_msgb: Header[1] [User-Agent] = [Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20100101 Firefox/8.0]
[Fri Dec 02 02:55:41 2011] [debug] ajp_header.c(284): ajp_marshal_into_msgb: Header[2] [Accept] = [text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8]
[Fri Dec 02 02:55:41 2011] [debug] ajp_header.c(284): ajp_marshal_into_msgb: Header[3] [Accept-Language] = [en-us,en;q=0.5]
[Fri Dec 02 02:55:41 2011] [debug] ajp_header.c(284): ajp_marshal_into_msgb: Header[4] [Accept-Encoding] = [gzip, deflate]
[Fri Dec 02 02:55:41 2011] [debug] ajp_header.c(284): ajp_marshal_into_msgb: Header[5] [Accept-Charset] = [ISO-8859-1,utf-8;q=0.7,*;q=0.7]
[Fri Dec 02 02:55:41 2011] [debug] ajp_header.c(284): ajp_marshal_into_msgb: Header[6] [Connection] = [keep-alive]
[Fri Dec 02 02:55:41 2011] [debug] ajp_header.c(284): ajp_marshal_into_msgb: Header[11] [REMOTE_USER] = [222222229test111111111111]
[Fri Dec 02 02:55:41 2011] [debug] ajp_header.c(284): ajp_marshal_into_msgb: Header[12] [Max-Forwards] = [10]
[Fri Dec 02 02:55:41 2011] [debug] ajp_header.c(424): ajp_marshal_into_msgb: Done
[Fri Dec 02 02:55:41 2011] [debug] mod_proxy_ajp.c(201): proxy: APR_BUCKET_IS_EOS
[Fri Dec 02 02:55:41 2011] [debug] mod_proxy_ajp.c(206): proxy: data to read (max 8186 at 4)
[Fri Dec 02 02:55:41 2011] [debug] mod_proxy_ajp.c(221): proxy: got 0 bytes of data
[Fri Dec 02 02:55:41 2011] [debug] ajp_header.c(646): ajp_read_header: ajp_ilink_received 04
[Fri Dec 02 02:55:41 2011] [debug] ajp_header.c(656): ajp_parse_type: got 04
[Fri Dec 02 02:55:41 2011] [debug] ajp_header.c(485): ajp_unmarshal_response: status = 200
[Fri Dec 02 02:55:41 2011] [debug] ajp_header.c(496): ajp_unmarshal_response: Number of headers is = 3
[Fri Dec 02 02:55:41 2011] [debug] ajp_header.c(558): ajp_unmarshal_response: Header[0] [Set-Cookie] = [JSESSIONID=887932DFF778B68B9BA3A43C85E8A4F2; Path=/samplesajp; Secure]
[Fri Dec 02 02:55:41 2011] [debug] ajp_header.c(558): ajp_unmarshal_response: Header[1] [Content-Type] = [text/html;charset=ISO-8859-1]
[Fri Dec 02 02:55:41 2011] [debug] ajp_header.c(568): ajp_unmarshal_response: ap_set_content_type done
[Fri Dec 02 02:55:41 2011] [debug] ajp_header.c(558): ajp_unmarshal_response: Header[2] [Content-Length] = [1132]
[Fri Dec 02 02:55:41 2011] [debug] ajp_header.c(646): ajp_read_header: ajp_ilink_received 03
[Fri Dec 02 02:55:41 2011] [debug] ajp_header.c(656): ajp_parse_type: got 03
[Fri Dec 02 02:55:41 2011] [debug] ajp_header.c(646): ajp_read_header: ajp_ilink_received 05
[Fri Dec 02 02:55:41 2011] [debug] ajp_header.c(656): ajp_parse_type: got 05
[Fri Dec 02 02:55:41 2011] [debug] mod_proxy_ajp.c(439): proxy: got response from 192.168.0.211:8009 (weblogic1.whatever.com)
[Fri Dec 02 02:55:41 2011] [debug] proxy_util.c(1870): proxy: AJP: has released connection for (weblogic1.whatever.com)
As you can see, there is a REMOTE_USER header:
[Fri Dec 02 02:55:41 2011] [debug] ajp_header.c(284): ajp_marshal_into_msgb: Header[11] [REMOTE_USER] = [222222229test111111111111]
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password" authentication?
Posted by André Warnier <aw...@ice-sa.com>.
ohaya@cox.net wrote:
> ---- ohaya@cox.net wrote:
>> ---- "André Warnier" <aw...@ice-sa.com> wrote:
>>> ohaya@cox.net wrote:
>>> ...
>>>> <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" tomcatAuthentication="false" />
>>>>
>>> That is correct. The "false" means that Tomcat will not do it's own authentication, and
>>> will instead rely on the authenticated user-id passed by the front-end server.
>>>
>>> Now could you also show us the section of your Apache front-end configuration, containing
>>> the directives which forward the requests to Tomcat ?
>>> (proxy or rewrite stanzas)
>>>
>>> Note: the fact that the Apache/Tomcat connector (the one at the Apache level) passes the
>>> authenticated user-id to Tomcat along with the proxied request, depends on the fact that
>>> within Apache (more precisely within the internal Apache "request record"), the request is
>>> really authenticated (*).
>>> I am saying this because in an earlier post, you mentioned that you were using a
>>> third-party authentication package at the Apache httpd level.
>>> It is unlikely, but possible, that this authentication package would use its own logic,
>>> and never "populate" the internal Apache request record with this user-id (**).
>>> In such a case, the automatic forwarding of the user-id by the Apache-level connector
>>> module (mod_proxy_ajp or mod_jk) would of course not work, because they check the internal
>>> Apache request record, and have no knowledge of another user-id source.
>>>
>>>
>>> (*) in Tomcat terms, the equivalent of populating the userPrincipal object
>>> (**) for example, it may act as a filter, and rely on each request always containing a
>>> cookie which "authenticates" the request, and do its own access control independently of
>>> Apache httpd itself
>>>
>>
>> Andre,
>>
>> Sure. Here's the section from httpd.conf. This is testing where I purposely insert a "REMOTE_USER" HTTP header into the request being proxied. As I said, I have a sniffer on the line, and I can see the REMOTE_USER header, but still, when I get to my test JSP hosted on the Tomcat, getUserPrincipal() is returning null (don't mind the hostname in the ProxyPass, etc. I just happen to be hosting Tomcat on that machine, and WebLogic is shutdown there).
>>
>>
>> # Proxy to Tomcat on weblogic1 machine, using AJP
>> <Location /samplesajp>
>> RequestHeader set "REMOTE_USER" "222222229test111111111111"
>> ProxyPass ajp://weblogic1.whatever.com:8009/samplesajp
>> ProxyPassReverse ajp://weblogic1.whatever.com:8009/samplesajp
>> </Location>
>>
>> Jim
>>
>>
>
> Hi,
>
> BTW, I asked about this earlier, but is it possible to turn on some debugging on the Tomcat side, that might help diagnose why the AJP connector is not working the expected way? I'm not that familiar with Tomcat or AJP logging, but I've only been able to set logging in logging.properties so that there's either almost no logging or it generated a ton of logging (but not stuff on AJP connection/processing) :(...
>
Sorry, dunno. Logging is not my favorite area in Tomcat..
Also, to tell the truth, I do not know exactly /how/ the Apache user-id is passed to
Tomcat. I strongly suspect that the "REMOTE_USER" HTTP header may not be it, and that it
may be via what Tomcat calls "request attributes", and Apache calls "environment
variables" (but not in the usual shell sense). But I don't know how this particular one
may be named.
Since you seem better at Java that I am, you may be able to find it in the Tomcat AJP
Connector code somewhere. I would start looking for "request attribute" rather than "header".
This page : http://tomcat.apache.org/connectors-doc/ajp/ajpv13a.html
seems to hint at ditto, and even mentions a request attribute named "remote_user" (lowercase).
Maybe you could try to set this "environment variable" in Apache, and see where it leads you ?
In this page : http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html#rewriterule
it shows how to do that (but there it calls them "server variables").
The terminology is not very consistent..
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password"
authentication?
Posted by oh...@cox.net.
---- ohaya@cox.net wrote:
>
> ---- "André Warnier" <aw...@ice-sa.com> wrote:
> > ohaya@cox.net wrote:
> > >
> > ...
> > >
> > > <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" tomcatAuthentication="false" />
> > >
> > That is correct. The "false" means that Tomcat will not do it's own authentication, and
> > will instead rely on the authenticated user-id passed by the front-end server.
> >
> > Now could you also show us the section of your Apache front-end configuration, containing
> > the directives which forward the requests to Tomcat ?
> > (proxy or rewrite stanzas)
> >
> > Note: the fact that the Apache/Tomcat connector (the one at the Apache level) passes the
> > authenticated user-id to Tomcat along with the proxied request, depends on the fact that
> > within Apache (more precisely within the internal Apache "request record"), the request is
> > really authenticated (*).
> > I am saying this because in an earlier post, you mentioned that you were using a
> > third-party authentication package at the Apache httpd level.
> > It is unlikely, but possible, that this authentication package would use its own logic,
> > and never "populate" the internal Apache request record with this user-id (**).
> > In such a case, the automatic forwarding of the user-id by the Apache-level connector
> > module (mod_proxy_ajp or mod_jk) would of course not work, because they check the internal
> > Apache request record, and have no knowledge of another user-id source.
> >
> >
> > (*) in Tomcat terms, the equivalent of populating the userPrincipal object
> > (**) for example, it may act as a filter, and rely on each request always containing a
> > cookie which "authenticates" the request, and do its own access control independently of
> > Apache httpd itself
> >
>
>
> Andre,
>
> Sure. Here's the section from httpd.conf. This is testing where I purposely insert a "REMOTE_USER" HTTP header into the request being proxied. As I said, I have a sniffer on the line, and I can see the REMOTE_USER header, but still, when I get to my test JSP hosted on the Tomcat, getUserPrincipal() is returning null (don't mind the hostname in the ProxyPass, etc. I just happen to be hosting Tomcat on that machine, and WebLogic is shutdown there).
>
>
> # Proxy to Tomcat on weblogic1 machine, using AJP
> <Location /samplesajp>
> RequestHeader set "REMOTE_USER" "222222229test111111111111"
> ProxyPass ajp://weblogic1.whatever.com:8009/samplesajp
> ProxyPassReverse ajp://weblogic1.whatever.com:8009/samplesajp
> </Location>
>
> Jim
>
>
Hi,
BTW, I asked about this earlier, but is it possible to turn on some debugging on the Tomcat side, that might help diagnose why the AJP connector is not working the expected way? I'm not that familiar with Tomcat or AJP logging, but I've only been able to set logging in logging.properties so that there's either almost no logging or it generated a ton of logging (but not stuff on AJP connection/processing) :(...
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password"
authentication?
Posted by oh...@cox.net.
---- "André Warnier" <aw...@ice-sa.com> wrote:
> ohaya@cox.net wrote:
> >
> ...
> >
> > <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" tomcatAuthentication="false" />
> >
> That is correct. The "false" means that Tomcat will not do it's own authentication, and
> will instead rely on the authenticated user-id passed by the front-end server.
>
> Now could you also show us the section of your Apache front-end configuration, containing
> the directives which forward the requests to Tomcat ?
> (proxy or rewrite stanzas)
>
> Note: the fact that the Apache/Tomcat connector (the one at the Apache level) passes the
> authenticated user-id to Tomcat along with the proxied request, depends on the fact that
> within Apache (more precisely within the internal Apache "request record"), the request is
> really authenticated (*).
> I am saying this because in an earlier post, you mentioned that you were using a
> third-party authentication package at the Apache httpd level.
> It is unlikely, but possible, that this authentication package would use its own logic,
> and never "populate" the internal Apache request record with this user-id (**).
> In such a case, the automatic forwarding of the user-id by the Apache-level connector
> module (mod_proxy_ajp or mod_jk) would of course not work, because they check the internal
> Apache request record, and have no knowledge of another user-id source.
>
>
> (*) in Tomcat terms, the equivalent of populating the userPrincipal object
> (**) for example, it may act as a filter, and rely on each request always containing a
> cookie which "authenticates" the request, and do its own access control independently of
> Apache httpd itself
>
Andre,
Sure. Here's the section from httpd.conf. This is testing where I purposely insert a "REMOTE_USER" HTTP header into the request being proxied. As I said, I have a sniffer on the line, and I can see the REMOTE_USER header, but still, when I get to my test JSP hosted on the Tomcat, getUserPrincipal() is returning null (don't mind the hostname in the ProxyPass, etc. I just happen to be hosting Tomcat on that machine, and WebLogic is shutdown there).
# Proxy to Tomcat on weblogic1 machine, using AJP
<Location /samplesajp>
RequestHeader set "REMOTE_USER" "222222229test111111111111"
ProxyPass ajp://weblogic1.whatever.com:8009/samplesajp
ProxyPassReverse ajp://weblogic1.whatever.com:8009/samplesajp
</Location>
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password" authentication?
Posted by André Warnier <aw...@ice-sa.com>.
ohaya@cox.net wrote:
>
...
>
> <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" tomcatAuthentication="false" />
>
That is correct. The "false" means that Tomcat will not do it's own authentication, and
will instead rely on the authenticated user-id passed by the front-end server.
Now could you also show us the section of your Apache front-end configuration, containing
the directives which forward the requests to Tomcat ?
(proxy or rewrite stanzas)
Note: the fact that the Apache/Tomcat connector (the one at the Apache level) passes the
authenticated user-id to Tomcat along with the proxied request, depends on the fact that
within Apache (more precisely within the internal Apache "request record"), the request is
really authenticated (*).
I am saying this because in an earlier post, you mentioned that you were using a
third-party authentication package at the Apache httpd level.
It is unlikely, but possible, that this authentication package would use its own logic,
and never "populate" the internal Apache request record with this user-id (**).
In such a case, the automatic forwarding of the user-id by the Apache-level connector
module (mod_proxy_ajp or mod_jk) would of course not work, because they check the internal
Apache request record, and have no knowledge of another user-id source.
(*) in Tomcat terms, the equivalent of populating the userPrincipal object
(**) for example, it may act as a filter, and rely on each request always containing a
cookie which "authenticates" the request, and do its own access control independently of
Apache httpd itself
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Do any of the Tomcat LDAP-type realms support "no password"
authentication?
Posted by oh...@cox.net.
---- "Caldarale wrote:
> > From: ohaya@cox.net [mailto:ohaya@cox.net]
> > Subject: Re: Do any of the Tomcat LDAP-type realms support "no password" authentication?
>
> > In my sniffer, I can see the REMOTE_USER set to the hard-coded
> > string, but in my test JSP on Tomcat, there getUserPrincipal()
> > is returning null. I've tried this test with 'tomcatAuthentication'
> > attribute in server.xml set to both "true" and "false", with the
> > same results :(...
>
> You might want to post (not attach) your server.xml so we can see exactly what you're setting. Simple typos are often difficult for the author to see. Please remove comments beforehand to reduce the amount of crud we have to wade through.
>
> - Chuck
>
>
Chuck,
Thanks for the suggestion. Here it is, minus most of "the curd" :). It's basically vanilla Tomcat (note: what I posted below has "false" for "tomcatAuthentication", but I tried with both "true" and "false").
<?xml version='1.0' encoding='utf-8'?>
<Server port="8005" shutdown="SHUTDOWN">
<!--APR library loader. Documentation at /docs/apr.html -->
<Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
<!--Initialize Jasper prior to webapps are loaded. Documentation at /docs/jasper-howto.html -->
<Listener className="org.apache.catalina.core.JasperListener" />
<!-- Prevent memory leaks due to use of particular java/javax APIs-->
<Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
<!-- JMX Support for the Tomcat server. Documentation at /docs/non-existent.html -->
<Listener className="org.apache.catalina.mbeans.ServerLifecycleListener" />
<Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
<GlobalNamingResources>
<Resource name="UserDatabase" auth="Container"
type="org.apache.catalina.UserDatabase"
description="User database that can be updated and saved"
factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
pathname="conf/tomcat-users.xml" />
</GlobalNamingResources>
<Service name="Catalina">
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" tomcatAuthentication="false" />
<Engine name="Catalina" defaultHost="localhost">
<Realm className="org.apache.catalina.realm.UserDatabaseRealm"
resourceName="UserDatabase"/>
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true"
xmlValidation="false" xmlNamespaceAware="false">
</Host>
</Engine>
</Service>
</Server>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Do any of the Tomcat LDAP-type realms support "no password"
authentication?
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: ohaya@cox.net [mailto:ohaya@cox.net]
> Subject: Re: Do any of the Tomcat LDAP-type realms support "no password" authentication?
> In my sniffer, I can see the REMOTE_USER set to the hard-coded
> string, but in my test JSP on Tomcat, there getUserPrincipal()
> is returning null. I've tried this test with 'tomcatAuthentication'
> attribute in server.xml set to both "true" and "false", with the
> same results :(...
You might want to post (not attach) your server.xml so we can see exactly what you're setting. Simple typos are often difficult for the author to see. Please remove comments beforehand to reduce the amount of crud we have to wade through.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
Re: Do any of the Tomcat LDAP-type realms support "no password" authentication?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 12/1/11 11:29 PM, ohaya@cox.net wrote:
> Also, BTW, I just did a test where, in the Apache httpd.conf, I
> hard-coded REMOTE_USER header using RequestHeader.
>
> In my sniffer, I can see the REMOTE_USER set to the hard-coded
> string, but in my test JSP on Tomcat, there getUserPrincipal() is
> returning null. I've tried this test with 'tomcatAuthentication'
> attribute in server.xml set to both "true" and "false", with the
> same results :(...
That rings a bell. I seem to recall that if the resource isn't
protected by a <security-constraint> then getUserPrincipal will return
null during that request.
That may only be when Tomcat is doing it's own authentication, though.
I suspect that if you (or the AJP connector) sets the principal in the
request, it's there regardless of the authentication settings of Tomcat.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7ZB4IACgkQ9CaO5/Lv0PD4+wCfYUpbHjASjkZ1NNSwRj1X1B2g
yUUAoKs9V0PXp05T4hp6lucrcBAfNfdh
=UwDd
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password"
authentication?
Posted by oh...@cox.net.
---- ohaya@cox.net wrote:
>
> ---- ohaya@cox.net wrote:
> >
> > ---- "André Warnier" <aw...@ice-sa.com> wrote:
> > > ohaya@cox.net wrote:
> > > > ---- "André Warnier" <aw...@ice-sa.com> wrote:
> > > >> ohaya@cox.net wrote:
> > > >>> Hi,
> > > >>>
> > > >>> I'm new here, and hope that someone can help.
> > > >>>
> > > >>> I was wondering if any of the LDAP-type realms (e.g., JNDIRealm, etc.) support an authentication mode where no password or credentials are required? In other words, where just a userID/username is presented, and if that userID/username is present in the LDAP, then the user gets authenticated?
> > > >>>
> > > >> You have to be VERY specific here about what you mean, because this is a very delicate area.
> > > >>
> > > >> If you mean : "does there exist any way by which Tomcat can authenticate a user, without
> > > >> forcing this user to go through a login dialog with userid and password ?"
> > > >> then the answer is : yes, several (*). But the applicability of each depends very much on
> > > >> the exact circumstances.
> > > >>
> > > >> If you mean : "does there exist any /standard/ authentication mechanism in Tomcat whereby,
> > > >> /with/ a login dialog, the user could be authenticated without providing a password,
> > > >> although the authentication back-end (e.g. LDAP) has a non-empty password registered for
> > > >> that user ?"
> > > >> then the answer is no, definitely. Because such a mechanism would be a HUGE security
> > > >> hole, so it is certainly not provided as any standard authentication framework.
> > > >> (which does not mean that you could not invent your own mechanism).
> > > >>
> > > >> Also, when you are mentioning LDAP, do you really mean the standard LDAP (which is just
> > > >> basically a database, and is not per se an "authentication mechanism"), or do you mean
> > > >> "Windows domain authentication, backed up by an Active Directory server" ?
> > > >> Or something else ?
> > > >>
> > > >> There is so much variation possible here, that it may be better to describe what you want
> > > >> to achieve really, rather than asking questions about this or that mechanism right away.
> > > >>
> > > >>
> > > >> (*) for example, look here :
> > > >> http://tomcat.apache.org/tomcat-7.0-doc/windows-auth-howto.html
> > > >> http://waffle.codeplex.com/
> > > >> http://www.ioplex.com/jespa.html
> > > >>
> > > >
> > > >
> > > > Hi Andre,
> > > >
> > > > Sorry. I should have been clearer in my explanation and my question, so let me try again.
> > > >
> > > > Our configuration has an Apache in front of the Tomcat, with the Apache reverse-proxying (using mod_proxy, for now) to the Tomcat.
> > > >
> > > > In the Apache proxy, we do client-authenticated certificate authentication, and we also have a web agent/module that authenticates the user into a commercial SSO product. After the user is authenticated, the requests that go to/get proxied to the Tomcat have some HTTP headers, including a header containing the userID of the user that got authenticated by the SSO product.
> > > >
> > > > I've been working on Tomcat valve that does "ID assertion", i.e., when the code in my valve sees the HTTP header with the authenticated userID, it "asserts" the user into Tomcat.
> > > >
> > > > Specifically, my valve code calls org.apache.catalina.connector.Request.setUserPrincipal(getPrincipal(paramRequest)), where "paramRequest" is the org.apache.catalina.connector.Request object.
> > > >
> > > >
> > > > When I posted my message, I had just started on my valve code. As I said, I'm kind of new to Tomcat security, but at that time, I *thought* that after my valve did the setUserPrincipal(), that the user had to somehow be authenticated into the Tomcat realm (i.e., that the asserted userID had to actually exist in the Tomcat realm).
> > > >
> > > >
> > > > I've since gotten an initial version of my valve code kind of working, but I'm still a little.
> > > >
> > > > I can get the userID from the request header and call the setUserPrincipal() in the valve code successfully, and from some test JSP pages I use, I can see that when the JSP calls request.getUserPrincipal(), it appears to return the asserted user.
> > > >
> > > >
> > > > The thing that is puzzling me is that, on my test Tomcat, I just have the default realm (the one that uses tomcat-user.xml for the user base), with only the default set of dummy users.
> > > >
> > > >
> > > > And yet, when I test with my valve and the test JSP, it appears that everything just works, even when the userID that I assert is not in the Tomcat realm!
> > > >
> > > >
> > > > For example, I guess in the default realm, there's only a comple of users (tomcat, etc.), but if I send a request into the Tomcat with a header with a userID of "foobar" (and even though there is no user "foobar" in the Tomcat realm), things seem to work ok, i.e., my JSP displays "foobar" for request.getUserPrincipal().
> > > >
> > > >
> > > > Having said all of that, I guess that my question has changed somewhat. Specifically, now I'm wondering: With what I described above, and with my valve as described above, does the asserted user NOT have to be in the Tomcat realm at all?
> > > >
> > > >
> > > > It's almost like, with Tomcat, when my valve code calls setUserPrincipal(), Tomcat doesn't "care" whether the user that I'm asserting actually exists or doesn't exist in the Tomcat realm?
> > > >
> > > >
> > > > Again, as I said, I'm new, so I may (and probably am) misunderstanding something about how Tomcat security works...
> > > >
> > > >
> > > > Sorry for the longish post, but I hope that things are clearer now?
> > > >
> > >
> > > Better a long and clear post, than a short and obscure one.
> > >
> > > Two things :
> > >
> > > I am not really a Tomcat expert, and this will need to be corroborated by one of them, but
> > > it seems that I remember a not-too-long-ago thread in this same forum, in which it came
> > > out that if there is already a user-id known to Tomcat, it will not even bother to run its
> > > own authentication code. That is said in non-expert terms, but I'm sure someone here will
> > > correct that if need be.
> > >
> > > The other thing is that you may be doing a lot of work for nothing.
> > > If you would use either one of the mod_proxy_ajp or the mod_jk Apache module as a
> > > connector to Tomcat, then this connector will automatically pass the authenticated Apache
> > > user to Tomcat with every request, and you would not need your Valve.
> > > Have a look at the TomcatAJP <Connector> description, attribute "tomcatAuthentication".
> > > http://tomcat.apache.org/tomcat-7.0-doc/config/ajp.html
> > >
> > > This being said, make sure that the connection between Apache and Tomcat is reasonably
> > > secure (for example, within the same host or over an internal network), because the AJP
> > > protocol (although in part binary) is not itself encrypted.
> > > No user password is passed over it (only the user-id), but a hacker could in theory
> > > intercept the packets, and replace one user-id by another.
> > >
> >
> >
> > Hi Andre,
> >
> > Thanks for that info re. AJP. I will definitely take a look (test) that, as even if I/we pursue the valve I'm working on, it'd be a nice thing to have as an option (e.g., if someone doesn't want to use mod_ajp, they could use my valve, but if they use mod_ajp, then they wouldn't need the valve!
> >
> > If you can remember, can you either provide a link or maybe the subject for that thread you referenced? I'd be very interested in reviewing it.
> >
> > Thanks again for all the great info!
> >
> > Jim
> >
>
>
> Hi Andre (et al),
>
> I've been testing with AJP and Tomcat. From what I've read, it looks like that tomcatAuthentication looks for an HTTP header, "REMOTE_USER" that contains the userID that it will authenticate/assert into Tomcat.
>
> At this point, I can proxy to Tomcat using AJP fine, but it looks like the user is not being authenticated within Tomcat. It looks like to me, the "REMOTE_USER" HTTP header is "(null)", instead of containing a userID.
>
> I've tried a bunch of stuff in my Apache httpd.conf, using RequestHeader and also several different rewrite rules, but still can't get this to work.
>
> Does anyone have a reliable way to populate the REMOTE_USER header, when using AJP connector?
>
> Also, I'm a little unclear about whether the "tomcatAuthentication" in the AJP connector should be set to "true" or "false"?
>
> Finally, is there a way to configure Tomcat so that it outputs some debug logging for the AJP connector, e.g., so I can see exactly what headers it IS seeing? I have a sniffer on, but it's hard to see what's in the AJP connection protocol.
>
> Thanks, and sorry for all of the questions!
>
> Jim
Hi,
Also, BTW, I just did a test where, in the Apache httpd.conf, I hard-coded REMOTE_USER header using RequestHeader.
In my sniffer, I can see the REMOTE_USER set to the hard-coded string, but in my test JSP on Tomcat, there getUserPrincipal() is returning null. I've tried this test with 'tomcatAuthentication' attribute in server.xml set to both "true" and "false", with the same results :(...
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password"
authentication?
Posted by oh...@cox.net.
---- ohaya@cox.net wrote:
>
> ---- "André Warnier" <aw...@ice-sa.com> wrote:
> > ohaya@cox.net wrote:
> > > ---- "André Warnier" <aw...@ice-sa.com> wrote:
> > >> ohaya@cox.net wrote:
> > >>> Hi,
> > >>>
> > >>> I'm new here, and hope that someone can help.
> > >>>
> > >>> I was wondering if any of the LDAP-type realms (e.g., JNDIRealm, etc.) support an authentication mode where no password or credentials are required? In other words, where just a userID/username is presented, and if that userID/username is present in the LDAP, then the user gets authenticated?
> > >>>
> > >> You have to be VERY specific here about what you mean, because this is a very delicate area.
> > >>
> > >> If you mean : "does there exist any way by which Tomcat can authenticate a user, without
> > >> forcing this user to go through a login dialog with userid and password ?"
> > >> then the answer is : yes, several (*). But the applicability of each depends very much on
> > >> the exact circumstances.
> > >>
> > >> If you mean : "does there exist any /standard/ authentication mechanism in Tomcat whereby,
> > >> /with/ a login dialog, the user could be authenticated without providing a password,
> > >> although the authentication back-end (e.g. LDAP) has a non-empty password registered for
> > >> that user ?"
> > >> then the answer is no, definitely. Because such a mechanism would be a HUGE security
> > >> hole, so it is certainly not provided as any standard authentication framework.
> > >> (which does not mean that you could not invent your own mechanism).
> > >>
> > >> Also, when you are mentioning LDAP, do you really mean the standard LDAP (which is just
> > >> basically a database, and is not per se an "authentication mechanism"), or do you mean
> > >> "Windows domain authentication, backed up by an Active Directory server" ?
> > >> Or something else ?
> > >>
> > >> There is so much variation possible here, that it may be better to describe what you want
> > >> to achieve really, rather than asking questions about this or that mechanism right away.
> > >>
> > >>
> > >> (*) for example, look here :
> > >> http://tomcat.apache.org/tomcat-7.0-doc/windows-auth-howto.html
> > >> http://waffle.codeplex.com/
> > >> http://www.ioplex.com/jespa.html
> > >>
> > >
> > >
> > > Hi Andre,
> > >
> > > Sorry. I should have been clearer in my explanation and my question, so let me try again.
> > >
> > > Our configuration has an Apache in front of the Tomcat, with the Apache reverse-proxying (using mod_proxy, for now) to the Tomcat.
> > >
> > > In the Apache proxy, we do client-authenticated certificate authentication, and we also have a web agent/module that authenticates the user into a commercial SSO product. After the user is authenticated, the requests that go to/get proxied to the Tomcat have some HTTP headers, including a header containing the userID of the user that got authenticated by the SSO product.
> > >
> > > I've been working on Tomcat valve that does "ID assertion", i.e., when the code in my valve sees the HTTP header with the authenticated userID, it "asserts" the user into Tomcat.
> > >
> > > Specifically, my valve code calls org.apache.catalina.connector.Request.setUserPrincipal(getPrincipal(paramRequest)), where "paramRequest" is the org.apache.catalina.connector.Request object.
> > >
> > >
> > > When I posted my message, I had just started on my valve code. As I said, I'm kind of new to Tomcat security, but at that time, I *thought* that after my valve did the setUserPrincipal(), that the user had to somehow be authenticated into the Tomcat realm (i.e., that the asserted userID had to actually exist in the Tomcat realm).
> > >
> > >
> > > I've since gotten an initial version of my valve code kind of working, but I'm still a little.
> > >
> > > I can get the userID from the request header and call the setUserPrincipal() in the valve code successfully, and from some test JSP pages I use, I can see that when the JSP calls request.getUserPrincipal(), it appears to return the asserted user.
> > >
> > >
> > > The thing that is puzzling me is that, on my test Tomcat, I just have the default realm (the one that uses tomcat-user.xml for the user base), with only the default set of dummy users.
> > >
> > >
> > > And yet, when I test with my valve and the test JSP, it appears that everything just works, even when the userID that I assert is not in the Tomcat realm!
> > >
> > >
> > > For example, I guess in the default realm, there's only a comple of users (tomcat, etc.), but if I send a request into the Tomcat with a header with a userID of "foobar" (and even though there is no user "foobar" in the Tomcat realm), things seem to work ok, i.e., my JSP displays "foobar" for request.getUserPrincipal().
> > >
> > >
> > > Having said all of that, I guess that my question has changed somewhat. Specifically, now I'm wondering: With what I described above, and with my valve as described above, does the asserted user NOT have to be in the Tomcat realm at all?
> > >
> > >
> > > It's almost like, with Tomcat, when my valve code calls setUserPrincipal(), Tomcat doesn't "care" whether the user that I'm asserting actually exists or doesn't exist in the Tomcat realm?
> > >
> > >
> > > Again, as I said, I'm new, so I may (and probably am) misunderstanding something about how Tomcat security works...
> > >
> > >
> > > Sorry for the longish post, but I hope that things are clearer now?
> > >
> >
> > Better a long and clear post, than a short and obscure one.
> >
> > Two things :
> >
> > I am not really a Tomcat expert, and this will need to be corroborated by one of them, but
> > it seems that I remember a not-too-long-ago thread in this same forum, in which it came
> > out that if there is already a user-id known to Tomcat, it will not even bother to run its
> > own authentication code. That is said in non-expert terms, but I'm sure someone here will
> > correct that if need be.
> >
> > The other thing is that you may be doing a lot of work for nothing.
> > If you would use either one of the mod_proxy_ajp or the mod_jk Apache module as a
> > connector to Tomcat, then this connector will automatically pass the authenticated Apache
> > user to Tomcat with every request, and you would not need your Valve.
> > Have a look at the TomcatAJP <Connector> description, attribute "tomcatAuthentication".
> > http://tomcat.apache.org/tomcat-7.0-doc/config/ajp.html
> >
> > This being said, make sure that the connection between Apache and Tomcat is reasonably
> > secure (for example, within the same host or over an internal network), because the AJP
> > protocol (although in part binary) is not itself encrypted.
> > No user password is passed over it (only the user-id), but a hacker could in theory
> > intercept the packets, and replace one user-id by another.
> >
>
>
> Hi Andre,
>
> Thanks for that info re. AJP. I will definitely take a look (test) that, as even if I/we pursue the valve I'm working on, it'd be a nice thing to have as an option (e.g., if someone doesn't want to use mod_ajp, they could use my valve, but if they use mod_ajp, then they wouldn't need the valve!
>
> If you can remember, can you either provide a link or maybe the subject for that thread you referenced? I'd be very interested in reviewing it.
>
> Thanks again for all the great info!
>
> Jim
>
Hi Andre (et al),
I've been testing with AJP and Tomcat. From what I've read, it looks like that tomcatAuthentication looks for an HTTP header, "REMOTE_USER" that contains the userID that it will authenticate/assert into Tomcat.
At this point, I can proxy to Tomcat using AJP fine, but it looks like the user is not being authenticated within Tomcat. It looks like to me, the "REMOTE_USER" HTTP header is "(null)", instead of containing a userID.
I've tried a bunch of stuff in my Apache httpd.conf, using RequestHeader and also several different rewrite rules, but still can't get this to work.
Does anyone have a reliable way to populate the REMOTE_USER header, when using AJP connector?
Also, I'm a little unclear about whether the "tomcatAuthentication" in the AJP connector should be set to "true" or "false"?
Finally, is there a way to configure Tomcat so that it outputs some debug logging for the AJP connector, e.g., so I can see exactly what headers it IS seeing? I have a sniffer on, but it's hard to see what's in the AJP connection protocol.
Thanks, and sorry for all of the questions!
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password"
authentication?
Posted by oh...@cox.net.
---- "André Warnier" <aw...@ice-sa.com> wrote:
> ohaya@cox.net wrote:
> > ---- "André Warnier" <aw...@ice-sa.com> wrote:
> >> ohaya@cox.net wrote:
> >>> Hi,
> >>>
> >>> I'm new here, and hope that someone can help.
> >>>
> >>> I was wondering if any of the LDAP-type realms (e.g., JNDIRealm, etc.) support an authentication mode where no password or credentials are required? In other words, where just a userID/username is presented, and if that userID/username is present in the LDAP, then the user gets authenticated?
> >>>
> >> You have to be VERY specific here about what you mean, because this is a very delicate area.
> >>
> >> If you mean : "does there exist any way by which Tomcat can authenticate a user, without
> >> forcing this user to go through a login dialog with userid and password ?"
> >> then the answer is : yes, several (*). But the applicability of each depends very much on
> >> the exact circumstances.
> >>
> >> If you mean : "does there exist any /standard/ authentication mechanism in Tomcat whereby,
> >> /with/ a login dialog, the user could be authenticated without providing a password,
> >> although the authentication back-end (e.g. LDAP) has a non-empty password registered for
> >> that user ?"
> >> then the answer is no, definitely. Because such a mechanism would be a HUGE security
> >> hole, so it is certainly not provided as any standard authentication framework.
> >> (which does not mean that you could not invent your own mechanism).
> >>
> >> Also, when you are mentioning LDAP, do you really mean the standard LDAP (which is just
> >> basically a database, and is not per se an "authentication mechanism"), or do you mean
> >> "Windows domain authentication, backed up by an Active Directory server" ?
> >> Or something else ?
> >>
> >> There is so much variation possible here, that it may be better to describe what you want
> >> to achieve really, rather than asking questions about this or that mechanism right away.
> >>
> >>
> >> (*) for example, look here :
> >> http://tomcat.apache.org/tomcat-7.0-doc/windows-auth-howto.html
> >> http://waffle.codeplex.com/
> >> http://www.ioplex.com/jespa.html
> >>
> >
> >
> > Hi Andre,
> >
> > Sorry. I should have been clearer in my explanation and my question, so let me try again.
> >
> > Our configuration has an Apache in front of the Tomcat, with the Apache reverse-proxying (using mod_proxy, for now) to the Tomcat.
> >
> > In the Apache proxy, we do client-authenticated certificate authentication, and we also have a web agent/module that authenticates the user into a commercial SSO product. After the user is authenticated, the requests that go to/get proxied to the Tomcat have some HTTP headers, including a header containing the userID of the user that got authenticated by the SSO product.
> >
> > I've been working on Tomcat valve that does "ID assertion", i.e., when the code in my valve sees the HTTP header with the authenticated userID, it "asserts" the user into Tomcat.
> >
> > Specifically, my valve code calls org.apache.catalina.connector.Request.setUserPrincipal(getPrincipal(paramRequest)), where "paramRequest" is the org.apache.catalina.connector.Request object.
> >
> >
> > When I posted my message, I had just started on my valve code. As I said, I'm kind of new to Tomcat security, but at that time, I *thought* that after my valve did the setUserPrincipal(), that the user had to somehow be authenticated into the Tomcat realm (i.e., that the asserted userID had to actually exist in the Tomcat realm).
> >
> >
> > I've since gotten an initial version of my valve code kind of working, but I'm still a little.
> >
> > I can get the userID from the request header and call the setUserPrincipal() in the valve code successfully, and from some test JSP pages I use, I can see that when the JSP calls request.getUserPrincipal(), it appears to return the asserted user.
> >
> >
> > The thing that is puzzling me is that, on my test Tomcat, I just have the default realm (the one that uses tomcat-user.xml for the user base), with only the default set of dummy users.
> >
> >
> > And yet, when I test with my valve and the test JSP, it appears that everything just works, even when the userID that I assert is not in the Tomcat realm!
> >
> >
> > For example, I guess in the default realm, there's only a comple of users (tomcat, etc.), but if I send a request into the Tomcat with a header with a userID of "foobar" (and even though there is no user "foobar" in the Tomcat realm), things seem to work ok, i.e., my JSP displays "foobar" for request.getUserPrincipal().
> >
> >
> > Having said all of that, I guess that my question has changed somewhat. Specifically, now I'm wondering: With what I described above, and with my valve as described above, does the asserted user NOT have to be in the Tomcat realm at all?
> >
> >
> > It's almost like, with Tomcat, when my valve code calls setUserPrincipal(), Tomcat doesn't "care" whether the user that I'm asserting actually exists or doesn't exist in the Tomcat realm?
> >
> >
> > Again, as I said, I'm new, so I may (and probably am) misunderstanding something about how Tomcat security works...
> >
> >
> > Sorry for the longish post, but I hope that things are clearer now?
> >
>
> Better a long and clear post, than a short and obscure one.
>
> Two things :
>
> I am not really a Tomcat expert, and this will need to be corroborated by one of them, but
> it seems that I remember a not-too-long-ago thread in this same forum, in which it came
> out that if there is already a user-id known to Tomcat, it will not even bother to run its
> own authentication code. That is said in non-expert terms, but I'm sure someone here will
> correct that if need be.
>
> The other thing is that you may be doing a lot of work for nothing.
> If you would use either one of the mod_proxy_ajp or the mod_jk Apache module as a
> connector to Tomcat, then this connector will automatically pass the authenticated Apache
> user to Tomcat with every request, and you would not need your Valve.
> Have a look at the TomcatAJP <Connector> description, attribute "tomcatAuthentication".
> http://tomcat.apache.org/tomcat-7.0-doc/config/ajp.html
>
> This being said, make sure that the connection between Apache and Tomcat is reasonably
> secure (for example, within the same host or over an internal network), because the AJP
> protocol (although in part binary) is not itself encrypted.
> No user password is passed over it (only the user-id), but a hacker could in theory
> intercept the packets, and replace one user-id by another.
>
Hi Andre,
Thanks for that info re. AJP. I will definitely take a look (test) that, as even if I/we pursue the valve I'm working on, it'd be a nice thing to have as an option (e.g., if someone doesn't want to use mod_ajp, they could use my valve, but if they use mod_ajp, then they wouldn't need the valve!
If you can remember, can you either provide a link or maybe the subject for that thread you referenced? I'd be very interested in reviewing it.
Thanks again for all the great info!
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password" authentication?
Posted by André Warnier <aw...@ice-sa.com>.
ohaya@cox.net wrote:
> ---- "André Warnier" <aw...@ice-sa.com> wrote:
>> ohaya@cox.net wrote:
>>> Hi,
>>>
>>> I'm new here, and hope that someone can help.
>>>
>>> I was wondering if any of the LDAP-type realms (e.g., JNDIRealm, etc.) support an authentication mode where no password or credentials are required? In other words, where just a userID/username is presented, and if that userID/username is present in the LDAP, then the user gets authenticated?
>>>
>> You have to be VERY specific here about what you mean, because this is a very delicate area.
>>
>> If you mean : "does there exist any way by which Tomcat can authenticate a user, without
>> forcing this user to go through a login dialog with userid and password ?"
>> then the answer is : yes, several (*). But the applicability of each depends very much on
>> the exact circumstances.
>>
>> If you mean : "does there exist any /standard/ authentication mechanism in Tomcat whereby,
>> /with/ a login dialog, the user could be authenticated without providing a password,
>> although the authentication back-end (e.g. LDAP) has a non-empty password registered for
>> that user ?"
>> then the answer is no, definitely. Because such a mechanism would be a HUGE security
>> hole, so it is certainly not provided as any standard authentication framework.
>> (which does not mean that you could not invent your own mechanism).
>>
>> Also, when you are mentioning LDAP, do you really mean the standard LDAP (which is just
>> basically a database, and is not per se an "authentication mechanism"), or do you mean
>> "Windows domain authentication, backed up by an Active Directory server" ?
>> Or something else ?
>>
>> There is so much variation possible here, that it may be better to describe what you want
>> to achieve really, rather than asking questions about this or that mechanism right away.
>>
>>
>> (*) for example, look here :
>> http://tomcat.apache.org/tomcat-7.0-doc/windows-auth-howto.html
>> http://waffle.codeplex.com/
>> http://www.ioplex.com/jespa.html
>>
>
>
> Hi Andre,
>
> Sorry. I should have been clearer in my explanation and my question, so let me try again.
>
> Our configuration has an Apache in front of the Tomcat, with the Apache reverse-proxying (using mod_proxy, for now) to the Tomcat.
>
> In the Apache proxy, we do client-authenticated certificate authentication, and we also have a web agent/module that authenticates the user into a commercial SSO product. After the user is authenticated, the requests that go to/get proxied to the Tomcat have some HTTP headers, including a header containing the userID of the user that got authenticated by the SSO product.
>
> I've been working on Tomcat valve that does "ID assertion", i.e., when the code in my valve sees the HTTP header with the authenticated userID, it "asserts" the user into Tomcat.
>
> Specifically, my valve code calls org.apache.catalina.connector.Request.setUserPrincipal(getPrincipal(paramRequest)), where "paramRequest" is the org.apache.catalina.connector.Request object.
>
>
> When I posted my message, I had just started on my valve code. As I said, I'm kind of new to Tomcat security, but at that time, I *thought* that after my valve did the setUserPrincipal(), that the user had to somehow be authenticated into the Tomcat realm (i.e., that the asserted userID had to actually exist in the Tomcat realm).
>
>
> I've since gotten an initial version of my valve code kind of working, but I'm still a little.
>
> I can get the userID from the request header and call the setUserPrincipal() in the valve code successfully, and from some test JSP pages I use, I can see that when the JSP calls request.getUserPrincipal(), it appears to return the asserted user.
>
>
> The thing that is puzzling me is that, on my test Tomcat, I just have the default realm (the one that uses tomcat-user.xml for the user base), with only the default set of dummy users.
>
>
> And yet, when I test with my valve and the test JSP, it appears that everything just works, even when the userID that I assert is not in the Tomcat realm!
>
>
> For example, I guess in the default realm, there's only a comple of users (tomcat, etc.), but if I send a request into the Tomcat with a header with a userID of "foobar" (and even though there is no user "foobar" in the Tomcat realm), things seem to work ok, i.e., my JSP displays "foobar" for request.getUserPrincipal().
>
>
> Having said all of that, I guess that my question has changed somewhat. Specifically, now I'm wondering: With what I described above, and with my valve as described above, does the asserted user NOT have to be in the Tomcat realm at all?
>
>
> It's almost like, with Tomcat, when my valve code calls setUserPrincipal(), Tomcat doesn't "care" whether the user that I'm asserting actually exists or doesn't exist in the Tomcat realm?
>
>
> Again, as I said, I'm new, so I may (and probably am) misunderstanding something about how Tomcat security works...
>
>
> Sorry for the longish post, but I hope that things are clearer now?
>
Better a long and clear post, than a short and obscure one.
Two things :
I am not really a Tomcat expert, and this will need to be corroborated by one of them, but
it seems that I remember a not-too-long-ago thread in this same forum, in which it came
out that if there is already a user-id known to Tomcat, it will not even bother to run its
own authentication code. That is said in non-expert terms, but I'm sure someone here will
correct that if need be.
The other thing is that you may be doing a lot of work for nothing.
If you would use either one of the mod_proxy_ajp or the mod_jk Apache module as a
connector to Tomcat, then this connector will automatically pass the authenticated Apache
user to Tomcat with every request, and you would not need your Valve.
Have a look at the TomcatAJP <Connector> description, attribute "tomcatAuthentication".
http://tomcat.apache.org/tomcat-7.0-doc/config/ajp.html
This being said, make sure that the connection between Apache and Tomcat is reasonably
secure (for example, within the same host or over an internal network), because the AJP
protocol (although in part binary) is not itself encrypted.
No user password is passed over it (only the user-id), but a hacker could in theory
intercept the packets, and replace one user-id by another.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password"
authentication?
Posted by oh...@cox.net.
---- "André Warnier" <aw...@ice-sa.com> wrote:
> ohaya@cox.net wrote:
> > Hi,
> >
> > I'm new here, and hope that someone can help.
> >
> > I was wondering if any of the LDAP-type realms (e.g., JNDIRealm, etc.) support an authentication mode where no password or credentials are required? In other words, where just a userID/username is presented, and if that userID/username is present in the LDAP, then the user gets authenticated?
> >
>
> You have to be VERY specific here about what you mean, because this is a very delicate area.
>
> If you mean : "does there exist any way by which Tomcat can authenticate a user, without
> forcing this user to go through a login dialog with userid and password ?"
> then the answer is : yes, several (*). But the applicability of each depends very much on
> the exact circumstances.
>
> If you mean : "does there exist any /standard/ authentication mechanism in Tomcat whereby,
> /with/ a login dialog, the user could be authenticated without providing a password,
> although the authentication back-end (e.g. LDAP) has a non-empty password registered for
> that user ?"
> then the answer is no, definitely. Because such a mechanism would be a HUGE security
> hole, so it is certainly not provided as any standard authentication framework.
> (which does not mean that you could not invent your own mechanism).
>
> Also, when you are mentioning LDAP, do you really mean the standard LDAP (which is just
> basically a database, and is not per se an "authentication mechanism"), or do you mean
> "Windows domain authentication, backed up by an Active Directory server" ?
> Or something else ?
>
> There is so much variation possible here, that it may be better to describe what you want
> to achieve really, rather than asking questions about this or that mechanism right away.
>
>
> (*) for example, look here :
> http://tomcat.apache.org/tomcat-7.0-doc/windows-auth-howto.html
> http://waffle.codeplex.com/
> http://www.ioplex.com/jespa.html
>
Hi Andre,
Sorry. I should have been clearer in my explanation and my question, so let me try again.
Our configuration has an Apache in front of the Tomcat, with the Apache reverse-proxying (using mod_proxy, for now) to the Tomcat.
In the Apache proxy, we do client-authenticated certificate authentication, and we also have a web agent/module that authenticates the user into a commercial SSO product. After the user is authenticated, the requests that go to/get proxied to the Tomcat have some HTTP headers, including a header containing the userID of the user that got authenticated by the SSO product.
I've been working on Tomcat valve that does "ID assertion", i.e., when the code in my valve sees the HTTP header with the authenticated userID, it "asserts" the user into Tomcat.
Specifically, my valve code calls org.apache.catalina.connector.Request.setUserPrincipal(getPrincipal(paramRequest)), where "paramRequest" is the org.apache.catalina.connector.Request object.
When I posted my message, I had just started on my valve code. As I said, I'm kind of new to Tomcat security, but at that time, I *thought* that after my valve did the setUserPrincipal(), that the user had to somehow be authenticated into the Tomcat realm (i.e., that the asserted userID had to actually exist in the Tomcat realm).
I've since gotten an initial version of my valve code kind of working, but I'm still a little.
I can get the userID from the request header and call the setUserPrincipal() in the valve code successfully, and from some test JSP pages I use, I can see that when the JSP calls request.getUserPrincipal(), it appears to return the asserted user.
The thing that is puzzling me is that, on my test Tomcat, I just have the default realm (the one that uses tomcat-user.xml for the user base), with only the default set of dummy users.
And yet, when I test with my valve and the test JSP, it appears that everything just works, even when the userID that I assert is not in the Tomcat realm!
For example, I guess in the default realm, there's only a comple of users (tomcat, etc.), but if I send a request into the Tomcat with a header with a userID of "foobar" (and even though there is no user "foobar" in the Tomcat realm), things seem to work ok, i.e., my JSP displays "foobar" for request.getUserPrincipal().
Having said all of that, I guess that my question has changed somewhat. Specifically, now I'm wondering: With what I described above, and with my valve as described above, does the asserted user NOT have to be in the Tomcat realm at all?
It's almost like, with Tomcat, when my valve code calls setUserPrincipal(), Tomcat doesn't "care" whether the user that I'm asserting actually exists or doesn't exist in the Tomcat realm?
Again, as I said, I'm new, so I may (and probably am) misunderstanding something about how Tomcat security works...
Sorry for the longish post, but I hope that things are clearer now?
Thanks,
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support "no password" authentication?
Posted by André Warnier <aw...@ice-sa.com>.
ohaya@cox.net wrote:
> Hi,
>
> I'm new here, and hope that someone can help.
>
> I was wondering if any of the LDAP-type realms (e.g., JNDIRealm, etc.) support an authentication mode where no password or credentials are required? In other words, where just a userID/username is presented, and if that userID/username is present in the LDAP, then the user gets authenticated?
>
You have to be VERY specific here about what you mean, because this is a very delicate area.
If you mean : "does there exist any way by which Tomcat can authenticate a user, without
forcing this user to go through a login dialog with userid and password ?"
then the answer is : yes, several (*). But the applicability of each depends very much on
the exact circumstances.
If you mean : "does there exist any /standard/ authentication mechanism in Tomcat whereby,
/with/ a login dialog, the user could be authenticated without providing a password,
although the authentication back-end (e.g. LDAP) has a non-empty password registered for
that user ?"
then the answer is no, definitely. Because such a mechanism would be a HUGE security
hole, so it is certainly not provided as any standard authentication framework.
(which does not mean that you could not invent your own mechanism).
Also, when you are mentioning LDAP, do you really mean the standard LDAP (which is just
basically a database, and is not per se an "authentication mechanism"), or do you mean
"Windows domain authentication, backed up by an Active Directory server" ?
Or something else ?
There is so much variation possible here, that it may be better to describe what you want
to achieve really, rather than asking questions about this or that mechanism right away.
(*) for example, look here :
http://tomcat.apache.org/tomcat-7.0-doc/windows-auth-howto.html
http://waffle.codeplex.com/
http://www.ioplex.com/jespa.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org