Re: Does Tomcat 9 still support AJP connections, REMOTE_USER, and tomcatAuthentication="false"?
Hi Andre (and Christopher and Olaf),
I think that that is a good summary of where this is at this point.
Thanks!
Jim
On Saturday, May 16, 2020, 08:23:54 AM EDT, André Warnier (tomcat/perl)
wrote:
In summary, yes, I think you're right in your final conclusion below.
If the tomcat access log shows the authenticated user, it means that tomcat got
it, and I
see no other way than from Apache and through that "tomcatAuthentication=false"
option of
the tomcat AJP connector.
And that in turn means that, for Apache, this request was authenticated, which
in turn
means that OAM /did/ also set the Apache-internal R->user variable.
The values printed by your Apache cgi-bin script are maybe a bit confusing
regarding what
is going on, because they are the result of a different (and parallel) process
: when
Apache runs a cgi-bin script, it does this in a separate child process, and
when it
creates this process, it provides it with an environment. And that is what your
cgi-bin
script is showing (it's own environment values).
That in this environment, Apache creates a "remote-user" variable and populates
it with
the Apache authenticated user-id, is fortuitous but unrelated to the fact that
Apache+mod_proxy_ajp *also* passes this authenticated user-id via AJP to tomcat.
So now indeed, you have to figure out why this tomcat webapp wants the browser
to retrieve
a login page, despite the fact that this access is already authenticated.
But indeed this is no longer an Apache or a tomcat or tomcat Connector issue,
it is a
webapp logic or configuration issue.
On 16.05.2020 08:40, ohaya wrote:
> Hi,
>
> When I configure the OAM protection, they have the ability to configure
> values that go into HTTP headers (among other things) upon successful
> authentication (to OAM).
>
> I usually test this by protecting /cgi-bin/printenv on the Apache. printenv
> has this :
>
> ##
> ## printenv -- demo CGI program which just prints its environment
> ##
> use strict;
> use warnings;
>
> print "Content-type: text/plain; charset=iso-8859-1\n\n";
> foreach my $var (sort(keys(%ENV))) {
> my $val = $ENV{$var};
> $val =~ s|\n|\\n|g;
> $val =~ s|"|\\"|g;
> print "${var}=\"${val}\"\n";
>
> and when do that test, it does dump out remote_user (among others).
>
> Also FYI, I was just looking at the Tomcat localhost_access_log..txt
> file, and I am seeing lines like:
>
> xx.0.xx.xx - [16/May/2020:06:18:41 +] "GET /xxx/login
> HTTP/1.1" 302 -
>
> where is the username of the user that authenticated to
> OAM.
>
> I am not 100% about the format of that log, but does that line say that
> Tomcat thinks that the user that is logged INTO TOMCAT is that
> ?
>
> If so, then does that mean that I am already passing that user from Apache
> into Tomcat successfully?
>
> If so, I have thinking that maybe the webapp that I am trying to get logged
> into (it is Apache Syncope) is not leveraging the authentication mechanisms
> that are inbuilt in Tomcat?
>
> That kind of makes sense, because I know that I didn't have to add that user
> to the tomcat-users.xml.
>
> Finally if that is the case, this is no longer just a Tomcat-related issue.
>
> Jim
>
>
> On Friday, May 15, 2020, 09:38:19 AM EDT, Christopher Schultz
> wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Jim,
>
> On 5/15/20 08:42, ohaya wrote:
>> Yes, I am using Oracle Access Manager (OAM) so we have what they
>> call an "OAM webgate" that is integrated with the Apache. That
>> webgate automatically populates an HTTP header named "remote_user"
>> with the user that OAM authenticated.
>>
>> So the problem I having is trying to figure out how to "integrate"
>> that with Tomcat.
>
> Okay.
>
>> So we have:
>>
>> Browser <==> Apache+webgate <==> Tomcat (webapp)
>
> Good.
>
> First thing's first: Do you get your pages from Tomcat, but you aren't
> authenticated, or do you get some other kind of error? Sounds like you
> see your application, just no authentication.
>
> If this is your first time doing this, I assume you mean you're trying
> to figure out how to get it done, not trying to move a working
> configuration from another environment./version to Tomcat 9, right?
>
> There is nothing in the configuration you have posted so far that
> leads me to believe you'll be sending any REMOTE_USER HTTP header to
> Tomcat. Apache httpd doesn't (usually) auto-forward anything to
> Tomcat. Your OAS module is more likely setting an environment variable
> (remote_user) than an HTTP header. But it might be s
Re: Does Tomcat 9 still support AJP connections, REMOTE_USER, and tomcatAuthentication="false"?
Hi,
When I configure the OAM protection, they have the ability to configure values
that go into HTTP headers (among other things) upon successful authentication
(to OAM).
I usually test this by protecting /cgi-bin/printenv on the Apache. printenv has
this :
##
## printenv -- demo CGI program which just prints its environment
##
use strict;
use warnings;
print "Content-type: text/plain; charset=iso-8859-1\n\n";
foreach my $var (sort(keys(%ENV))) {
my $val = $ENV{$var};
$val =~ s|\n|\\n|g;
$val =~ s|"|\\"|g;
print "${var}=\"${val}\"\n";
and when do that test, it does dump out remote_user (among others).
Also FYI, I was just looking at the Tomcat localhost_access_log..txt
file, and I am seeing lines like:
xx.0.xx.xx - [16/May/2020:06:18:41 +] "GET /xxx/login
HTTP/1.1" 302 -
where is the username of the user that authenticated to OAM.
I am not 100% about the format of that log, but does that line say that Tomcat
thinks that the user that is logged INTO TOMCAT is that ?
If so, then does that mean that I am already passing that user from Apache into
Tomcat successfully?
If so, I have thinking that maybe the webapp that I am trying to get logged
into (it is Apache Syncope) is not leveraging the authentication mechanisms
that are inbuilt in Tomcat?
That kind of makes sense, because I know that I didn't have to add that user to
the tomcat-users.xml.
Finally if that is the case, this is no longer just a Tomcat-related issue.
Jim
On Friday, May 15, 2020, 09:38:19 AM EDT, Christopher Schultz
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Jim,
On 5/15/20 08:42, ohaya wrote:
> Yes, I am using Oracle Access Manager (OAM) so we have what they
> call an "OAM webgate" that is integrated with the Apache. That
> webgate automatically populates an HTTP header named "remote_user"
> with the user that OAM authenticated.
>
> So the problem I having is trying to figure out how to "integrate"
> that with Tomcat.
Okay.
> So we have:
>
> Browser <==> Apache+webgate <==> Tomcat (webapp)
Good.
First thing's first: Do you get your pages from Tomcat, but you aren't
authenticated, or do you get some other kind of error? Sounds like you
see your application, just no authentication.
If this is your first time doing this, I assume you mean you're trying
to figure out how to get it done, not trying to move a working
configuration from another environment./version to Tomcat 9, right?
There is nothing in the configuration you have posted so far that
leads me to believe you'll be sending any REMOTE_USER HTTP header to
Tomcat. Apache httpd doesn't (usually) auto-forward anything to
Tomcat. Your OAS module is more likely setting an environment variable
(remote_user) than an HTTP header. But it might be setting a header.
That would be good information to know.
To send arbitrary headers (etc.) to Tomcat via mod_proxy_ajp, you need
to configuration to do that. Let's take a look at the Tomcat
documentation to see how tomcatAuthentication="false" works.
Awesome, the documentation says nothing about how to tie-into it.
Well, the code says that tomcatAuthentication="false" means that AJP
can accept the REMOTE_USER /request attribute/ which is a special
servlet-thing which isn't the same as a header. So you have to arrange
for mod_proxy_ajp to send your "remote_user" (header or environment
variable) to Tomcat as a request attribute.
Here's how to do that. According to the mod_proxy_ajp docs:
"
Environment Variables
Environment variables whose names have the prefix AJP_ are forwarded
to the origin server as AJP request attributes (with the AJP_ prefix
removed from the name of the key).
"
Cool, so we just need to set an environment variable AJP_REMOTE_USER
and it will be sent as an attribute. So I think we have all the
pieces, now. So try this:
# Copy OAS's REMOTE_USER env variable -> AJP_REMOTE_USER for Tomcat
SetEnv AJP_REMOTE_USER "%{REMOTE_USER}e"
Just before your ProxyPass and friends.
I'm not entirely sure that will work. SetEnv doesn't say what "value"
can be; I'm hoping it will see that token and understand it's an
environment variable.
If that works, you're all set. Another option would be to tell OAS
that the environment variable you want is actually AJP_REMOTE_USER,
but if you want to use the environment variable "remote_user" for
other things, maybe making a copy like this is a better idea.
If that doesn't work, it may be that OAS is really setting an HTTP
header, which would be weird but, hey, Oracle is weird.
If you have to deal with HTTP headers, you'll want to do this:
# Disallow any random client from masquerading as any user
RequestHeader unset REMOTE_USER early
# Copy OAS's REMOTE_USER header -> AJP_REMOTE_USER for Tomcat
SetEnv AJP_REM
Re: Does Tomcat 9 still support AJP connections, REMOTE_USER, and tomcatAuthentication="false"?
Hi, Yes, I am using Oracle Access Manager (OAM) so we have what they call an "OAM webgate" that is integrated with the Apache. That webgate automatically populates an HTTP header named "remote_user" with the user that OAM authenticated. So the problem I having is trying to figure out how to "integrate" that with Tomcat. So we have: Browser <==> Apache+webgate <==> Tomcat (webapp) Jim On Friday, May 15, 2020, 08:36:18 AM EDT, André Warnier (tomcat/perl) wrote: Let me give my 5 cent. In the tomcat AJP Connector Tomcat, you use the tomcatAuthentication attribute : This setting has the effect that tomcat will "believe" the authenticated user-id that Apache is passing to it in the AJP protocol messages that Apache sends to tomcat, and not try to re-authenticate again at the tomcat level. (Note : this is not done by a "REMOTE_USER" HTTP header added by Apache; it happens via some internal variable specific to the AJP protocol). Of course, for this, the request needs to be first authenticated in Apache (so that it has a user-id to pass to tomcat). So do you have anything at the Apache httpd side, which authenticates the user before the request gets passed to tomcat (via AJP) ? On 15.05.2020 14:08, ohaya wrote: > Hi Olaf, > > Thanks. I do appreciate that! I will do more digging. > > Jim > > > On Friday, May 15, 2020, 07:41:50 AM EDT, Olaf Kock >wrote: > > > On 15.05.20 13:23, ohaya wrote: >> Hi, >> >> I just tried adding the secret to the Apache side: >> >> ProxyPass ajp://192.168.218.XXX:8009 secret="123" >> ProxyPassReverse ajp://192.168.218.XXX:8009 secret="123" >> >> and I get an error when I try to start Apache: >> >> AH00526: Syntax error on line 554 of /apps/oracle/apache/conf/httpd.conf: >> ProxyPass unknown Worker parameter >> >> I am currently using Apache 2.4.39. Is there another way to specify the >> "secret"? > > With 9.0.20 you do not yet need to pass a secret - that came along later > (somewhere around 30-33 AFAIR). However, you'll need to make sure that > your AJP port is only available for the reverse proxy and nobody else - > there was a recent security disclosure, which led to the change of many > default settings for the AJP connector in the current releases. > > It boils down to the last sentence of my previous answer: I've never > used REMOTE_USER headers for authentication, and there's no indicator in > your setup that you're allowing Tomcat to trust such a header. I might > be completely off here, but as nobody else answered yet, I thought I'd > give it a try. > > Olaf > >> Thanks, >> Jim >> >> >> On Friday, May 15, 2020, 07:04:44 AM EDT, ohaya >> wrote: >> >> Hi, >> >> The Tomcat version I am using is 9.0.20. I will take a look at the changelog. >> >> This is the first time I have tried this, and I couldn't find much info, so >> I appreciate the feedback. I will look for info about "secret". >> >> I wasn't sure about the format on the Apache side for the >> ProxyPass/ProxyPassReverse - does what I posted look all right? >> >> Also, when I was searching around for info, I saw some comments that seem to >> be saying that the "tomcatAuthentication" parameter on the Tomcat connection >> was no longer supported or something like that? >> >> Also re. "secret" on the Tomcat side: If that is set to, for example, >> "mysecret", how do I pass that on the Apache side? >> >> Thanks again, >> Jim >> >> >> On Friday, May 15, 2020, 03:33:19 AM EDT, Olaf Kock >> wrote: >> >> >> On 15.05.20 09:06, oh...@yahoo.com.INVALID wrote: >>> Hi, >>> >>> I am using an Apache proxy in front of Tomcat 9, and I am using AJP >>> connection to connect from the Apache to Tomcat, and I have the Apache >>> sending a username to the Tomcat in a REMOTE_USER header. >>> >>> In the Tomcat server.xml I have: >>> >>> >>tomcatAuthentication="false"/> >>> >>> In the Apache httpd.conf, to test, this I have: >>> >>> >>> ProxyPass ajp://192.168.218.XX:8009 >>> ProxyPassReverse ajp://192.168.XX.224:8009 >>> >>> >>> But when I access the app via the Apache, it is not automatically logging >>> me into the app. >>> >>> Is there anything else that I have to do to get this to work besides what I >>> did above? Is there something
Re: Does Tomcat 9 still support AJP connections, REMOTE_USER, and tomcatAuthentication="false"?
Hi Olaf, Thanks. I do appreciate that! I will do more digging. Jim On Friday, May 15, 2020, 07:41:50 AM EDT, Olaf Kock wrote: On 15.05.20 13:23, ohaya wrote: > Hi, > > I just tried adding the secret to the Apache side: > > ProxyPass ajp://192.168.218.XXX:8009 secret="123" > ProxyPassReverse ajp://192.168.218.XXX:8009 secret="123" > > and I get an error when I try to start Apache: > > AH00526: Syntax error on line 554 of /apps/oracle/apache/conf/httpd.conf: > ProxyPass unknown Worker parameter > > I am currently using Apache 2.4.39. Is there another way to specify the > "secret"? With 9.0.20 you do not yet need to pass a secret - that came along later (somewhere around 30-33 AFAIR). However, you'll need to make sure that your AJP port is only available for the reverse proxy and nobody else - there was a recent security disclosure, which led to the change of many default settings for the AJP connector in the current releases. It boils down to the last sentence of my previous answer: I've never used REMOTE_USER headers for authentication, and there's no indicator in your setup that you're allowing Tomcat to trust such a header. I might be completely off here, but as nobody else answered yet, I thought I'd give it a try. Olaf > Thanks, > Jim > > > On Friday, May 15, 2020, 07:04:44 AM EDT, ohaya > wrote: > > Hi, > > The Tomcat version I am using is 9.0.20. I will take a look at the changelog. > > This is the first time I have tried this, and I couldn't find much info, so I > appreciate the feedback. I will look for info about "secret". > > I wasn't sure about the format on the Apache side for the > ProxyPass/ProxyPassReverse - does what I posted look all right? > > Also, when I was searching around for info, I saw some comments that seem to > be saying that the "tomcatAuthentication" parameter on the Tomcat connection > was no longer supported or something like that? > > Also re. "secret" on the Tomcat side: If that is set to, for example, > "mysecret", how do I pass that on the Apache side? > > Thanks again, > Jim > > > On Friday, May 15, 2020, 03:33:19 AM EDT, Olaf Kock > wrote: > > > On 15.05.20 09:06, oh...@yahoo.com.INVALID wrote: >> Hi, >> >> I am using an Apache proxy in front of Tomcat 9, and I am using AJP >> connection to connect from the Apache to Tomcat, and I have the Apache >> sending a username to the Tomcat in a REMOTE_USER header. >> >> In the Tomcat server.xml I have: >> >> > tomcatAuthentication="false"/> >> >> In the Apache httpd.conf, to test, this I have: >> >> >> ProxyPass ajp://192.168.218.XX:8009 >> ProxyPassReverse ajp://192.168.XX.224:8009 >> >> >> But when I access the app via the Apache, it is not automatically logging me >> into the app. >> >> Is there anything else that I have to do to get this to work besides what I >> did above? Is there something that I have to modify in the app itself to >> get this to work? > Hi Jim, > > which exact version of Tomcat 9 are you using? Note that there were > significant changes for the default and required configuration for the > AJP connector, in order to use it. Best to find all of them: Search for > AJP in the change log tomcat.apache.org/tomcat-9.0-doc/changelog.html > > Notable among them: Everything to do with "secret", and the default bind > address, "localhost", for the AJP connector. i.e. I'd expect this > configuration to be insufficient for any of the latest releases. > > I haven't ever used this REMOTE_USER authentication, but nothing in the > configuration that you've posted gives any clue about what you do and > what you send. I would expect Tomcat to *not* blindly accept any > REMOTE_USER header by default, unless it's whitelisted and explicitly > asked for - it otherwise would be a great way to exploit servers that > don't have a remote proxy (or one where the remote proxy is configured > to remove this header). Nothing in the configuration you post gives me a > hint about what you do to make tomcat accept and trust this header. > > Olaf > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Does Tomcat 9 still support AJP connections, REMOTE_USER, and tomcatAuthentication="false"?
Hi, I just tried adding the secret to the Apache side: ProxyPass ajp://192.168.218.XXX:8009 secret="123" ProxyPassReverse ajp://192.168.218.XXX:8009 secret="123" and I get an error when I try to start Apache: AH00526: Syntax error on line 554 of /apps/oracle/apache/conf/httpd.conf: ProxyPass unknown Worker parameter I am currently using Apache 2.4.39. Is there another way to specify the "secret"? Thanks, Jim On Friday, May 15, 2020, 07:04:44 AM EDT, ohaya wrote: Hi, The Tomcat version I am using is 9.0.20. I will take a look at the changelog. This is the first time I have tried this, and I couldn't find much info, so I appreciate the feedback. I will look for info about "secret". I wasn't sure about the format on the Apache side for the ProxyPass/ProxyPassReverse - does what I posted look all right? Also, when I was searching around for info, I saw some comments that seem to be saying that the "tomcatAuthentication" parameter on the Tomcat connection was no longer supported or something like that? Also re. "secret" on the Tomcat side: If that is set to, for example, "mysecret", how do I pass that on the Apache side? Thanks again, Jim On Friday, May 15, 2020, 03:33:19 AM EDT, Olaf Kock wrote: On 15.05.20 09:06, oh...@yahoo.com.INVALID wrote: > Hi, > > I am using an Apache proxy in front of Tomcat 9, and I am using AJP > connection to connect from the Apache to Tomcat, and I have the Apache > sending a username to the Tomcat in a REMOTE_USER header. > > In the Tomcat server.xml I have: > > tomcatAuthentication="false"/> > > In the Apache httpd.conf, to test, this I have: > > > ProxyPass ajp://192.168.218.XX:8009 > ProxyPassReverse ajp://192.168.XX.224:8009 > > > But when I access the app via the Apache, it is not automatically logging me > into the app. > > Is there anything else that I have to do to get this to work besides what I > did above? Is there something that I have to modify in the app itself to get > this to work? Hi Jim, which exact version of Tomcat 9 are you using? Note that there were significant changes for the default and required configuration for the AJP connector, in order to use it. Best to find all of them: Search for AJP in the change log tomcat.apache.org/tomcat-9.0-doc/changelog.html Notable among them: Everything to do with "secret", and the default bind address, "localhost", for the AJP connector. i.e. I'd expect this configuration to be insufficient for any of the latest releases. I haven't ever used this REMOTE_USER authentication, but nothing in the configuration that you've posted gives any clue about what you do and what you send. I would expect Tomcat to *not* blindly accept any REMOTE_USER header by default, unless it's whitelisted and explicitly asked for - it otherwise would be a great way to exploit servers that don't have a remote proxy (or one where the remote proxy is configured to remove this header). Nothing in the configuration you post gives me a hint about what you do to make tomcat accept and trust this header. Olaf - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Does Tomcat 9 still support AJP connections, REMOTE_USER, and tomcatAuthentication="false"?
Hi, The Tomcat version I am using is 9.0.20. I will take a look at the changelog. This is the first time I have tried this, and I couldn't find much info, so I appreciate the feedback. I will look for info about "secret". I wasn't sure about the format on the Apache side for the ProxyPass/ProxyPassReverse - does what I posted look all right? Also, when I was searching around for info, I saw some comments that seem to be saying that the "tomcatAuthentication" parameter on the Tomcat connection was no longer supported or something like that? Also re. "secret" on the Tomcat side: If that is set to, for example, "mysecret", how do I pass that on the Apache side? Thanks again, Jim On Friday, May 15, 2020, 03:33:19 AM EDT, Olaf Kock wrote: On 15.05.20 09:06, oh...@yahoo.com.INVALID wrote: > Hi, > > I am using an Apache proxy in front of Tomcat 9, and I am using AJP > connection to connect from the Apache to Tomcat, and I have the Apache > sending a username to the Tomcat in a REMOTE_USER header. > > In the Tomcat server.xml I have: > > tomcatAuthentication="false"/> > > In the Apache httpd.conf, to test, this I have: > > > ProxyPass ajp://192.168.218.XX:8009 > ProxyPassReverse ajp://192.168.XX.224:8009 > > > But when I access the app via the Apache, it is not automatically logging me > into the app. > > Is there anything else that I have to do to get this to work besides what I > did above? Is there something that I have to modify in the app itself to get > this to work? Hi Jim, which exact version of Tomcat 9 are you using? Note that there were significant changes for the default and required configuration for the AJP connector, in order to use it. Best to find all of them: Search for AJP in the change log tomcat.apache.org/tomcat-9.0-doc/changelog.html Notable among them: Everything to do with "secret", and the default bind address, "localhost", for the AJP connector. i.e. I'd expect this configuration to be insufficient for any of the latest releases. I haven't ever used this REMOTE_USER authentication, but nothing in the configuration that you've posted gives any clue about what you do and what you send. I would expect Tomcat to *not* blindly accept any REMOTE_USER header by default, unless it's whitelisted and explicitly asked for - it otherwise would be a great way to exploit servers that don't have a remote proxy (or one where the remote proxy is configured to remove this header). Nothing in the configuration you post gives me a hint about what you do to make tomcat accept and trust this header. Olaf - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Does Tomcat 9 still support AJP connections, REMOTE_USER, and tomcatAuthentication="false"?
Hi, I am using an Apache proxy in front of Tomcat 9, and I am using AJP connection to connect from the Apache to Tomcat, and I have the Apache sending a username to the Tomcat in a REMOTE_USER header. In the Tomcat server.xml I have: In the Apache httpd.conf, to test, this I have: ProxyPass ajp://192.168.218.XX:8009 ProxyPassReverse ajp://192.168.XX.224:8009 But when I access the app via the Apache, it is not automatically logging me into the app. Is there anything else that I have to do to get this to work besides what I did above? Is there something that I have to modify in the app itself to get this to work? Thanks, Jim - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: NullPointerException/java.util.logging.ErrorManager: 5 when have load-on-startup
oh...@cox.net wrote: Mark Thomas ma...@apache.org wrote: On 07/07/2012 17:33, oh...@cox.net wrote: Trace A: java.util.logging.ErrorManager: 5 java.lang.NullPointerException at java.util.ListResourceBundle.handleGetObject(ListResourceBundle.java:109) at java.util.ResourceBundle.getObject(ResourceBundle.java:368) at java.util.ResourceBundle.getString(ResourceBundle.java:334) at java.util.logging.Formatter.formatMessage(Formatter.java:108) at java.util.logging.SimpleFormatter.format(SimpleFormatter.java:63) at org.apache.juli.FileHandler.publish(FileHandler.java:198) at java.util.logging.Logger.log(Logger.java:478) at java.util.logging.Logger.doLog(Logger.java:501) at java.util.logging.Logger.log(Logger.java:524) at oracle.security.am.common.nap.util.NAPLogger.log(NAPLogger.java:60) at oracle.security.am.common.nap.util.pool.ObjectPoolManager.shutdown(ObjectPoolManager.java:267) at oracle.security.am.common.aaaclient.ObAAAServiceClient.close(ObAAAServiceClient.java:1239) at oracle.security.am.common.aaaclient.ObAAAServiceClient.finalize(ObAAAServiceClient.java:2548) at jrockit.memory.Finalizer.doFinalize(Finalizer.java:29) at jrockit.memory.Finalizer.access$300(Finalizer.java:12) at jrockit.memory.Finalizer$4.run(Finalizer.java:186) at java.lang.Thread.run(Thread.java:662) java.util.logging.ErrorManager: 5 Trace B: java.lang.NullPointerException at java.util.ListResourceBundle.handleGetObject(ListResourceBundle.java:109) at java.util.ResourceBundle.getObject(ResourceBundle.java:368) at java.util.ResourceBundle.getString(ResourceBundle.java:334) at java.util.logging.Formatter.formatMessage(Formatter.java:108) at java.util.logging.SimpleFormatter.format(SimpleFormatter.java:63) at java.util.logging.StreamHandler.publish(StreamHandler.java:179) at java.util.logging.ConsoleHandler.publish(ConsoleHandler.java:88) at java.util.logging.Logger.log(Logger.java:478) at java.util.logging.Logger.doLog(Logger.java:501) at java.util.logging.Logger.log(Logger.java:524) at oracle.security.am.common.nap.util.NAPLogger.log(NAPLogger.java:60) at oracle.security.am.common.nap.util.pool.ObjectPoolManager.shutdown(ObjectPoolManager.java:267) at oracle.security.am.common.aaaclient.ObAAAServiceClient.close(ObAAAServiceClient.java:1239) at oracle.security.am.common.aaaclient.ObAAAServiceClient.finalize(ObAAAServiceClient.java:2548) at jrockit.memory.Finalizer.doFinalize(Finalizer.java:29) at jrockit.memory.Finalizer.access$300(Finalizer.java:12) at jrockit.memory.Finalizer$4.run(Finalizer.java:186) at java.lang.Thread.run(Thread.java:662) Do you see any Tomcat code in Trace B? No? Neither do I. So what makes you think there is a Tomcat problem here? Given the only difference in Trace A is that you are using a Tomcat Handler rather than the console I don't see anything here to suggest a Tomcat bug. Looking at the source for java.util.ListResourceBundle, the key or the value being used for the log message is null. That makes this an OAM bug, not a Tomcat one. Mark Hi Mark, Just to be clear, I wasn't pointing to a Tomcat bug :(... I'm just trying to figure out why the NullPointerException doesn't happen when I don't have load-on-startup in my servlet's web.xml, but does happen when I have load-on-startup in the web.xml. Also, BTW, if I stop then start the servlet app using the Tomcat manager app, I don't get the NullPointerException. What might the difference be between when the load-on-startup is in the web.xml vs. not being in the web.xml? Doesn't Tomcat just load and call the servlet's init() method when the load-on-startup is present? I'm kind of guessing it may be a timing type issue, as in my servlet's init() method, I initialize the Oracle stuff. My initialization call returns, but it may be that there's still something going on behind-the-scenes that's not quite done. Thanks, Jim - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Mark, For the record, it turned that there was a bug in the Oracle SDK, as you suggested. I got a patched SDK JAR, and the problem got fixed. Thanks, Jim - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
NullPointerException/java.util.logging.ErrorManager: 5 when have load-on-startup
Hi, I have a simple servlet deployed to Tomcat 6.0.35, and when I enable load-on-startup in the web.xml, so that the servlet's init() method gets run when Tomcat starts up, I get: . . In LoginServlet.init: Returned from calling CreateDefaultInstance... In LoginServlet.init: FINISHED initializing!! Jul 7, 2012 8:21:31 AM org.apache.catalina.startup.HostConfig deployDirectory INFO: Deploying web application directory showhdrs Jul 7, 2012 8:21:31 AM org.apache.catalina.startup.HostConfig deployDirectory INFO: Deploying web application directory docs Jul 7, 2012 8:21:31 AM org.apache.catalina.startup.HostConfig deployDirectory INFO: Deploying web application directory ROOT Jul 7, 2012 8:21:31 AM org.apache.catalina.startup.HostConfig deployDirectory INFO: Deploying web application directory examples java.util.logging.ErrorManager: 5 java.lang.NullPointerException at java.util.ListResourceBundle.handleGetObject(ListResourceBundle.java:109) at java.util.ResourceBundle.getObject(ResourceBundle.java:368) at java.util.ResourceBundle.getString(ResourceBundle.java:334) at java.util.logging.Formatter.formatMessage(Formatter.java:108) at java.util.logging.SimpleFormatter.format(SimpleFormatter.java:63) at org.apache.juli.FileHandler.publish(FileHandler.java:198) at java.util.logging.Logger.log(Logger.java:478) at java.util.logging.Logger.doLog(Logger.java:501) at java.util.logging.Logger.log(Logger.java:524) . . i.e., It appears that my servlet's init() method completes successfully, but then later in the startup, Tomcat throws this exception (actually twice). If I remove the load-on-startup from the servlet's web.xml, Tomcat starts fine, and processing in my servlet works ok (the init() method runs on first request, and service() method processes requests ok). I think that that 5 indicates a format error in the (Tomcat) logging, but I'm not currently using/invoking any logger in my servlet. Can anyone tell me what might be causing the error, and how I can eliminate the problem? Thanks, Jim - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: NullPointerException/java.util.logging.ErrorManager: 5 when have load-on-startup
Mark Thomas ma...@apache.org wrote: On 07/07/2012 13:40, oh...@cox.net wrote: Can anyone tell me what might be causing the error, and how I can eliminate the problem? Since you have removed the part of the stack trace that might tell use what the cause is, no. Mark Hi Mark, Sorry about that. Here's part of the catalina.out again, with the rest of the stack trace, plus showing it happens twice In LoginServlet.init: FINISHED initializing!! Jul 7, 2012 8:21:31 AM org.apache.catalina.startup.HostConfig deployDirectory INFO: Deploying web application directory showhdrs Jul 7, 2012 8:21:31 AM org.apache.catalina.startup.HostConfig deployDirectory INFO: Deploying web application directory docs Jul 7, 2012 8:21:31 AM org.apache.catalina.startup.HostConfig deployDirectory INFO: Deploying web application directory ROOT Jul 7, 2012 8:21:31 AM org.apache.catalina.startup.HostConfig deployDirectory INFO: Deploying web application directory examples java.util.logging.ErrorManager: 5 java.lang.NullPointerException at java.util.ListResourceBundle.handleGetObject(ListResourceBundle.java:109) at java.util.ResourceBundle.getObject(ResourceBundle.java:368) at java.util.ResourceBundle.getString(ResourceBundle.java:334) at java.util.logging.Formatter.formatMessage(Formatter.java:108) at java.util.logging.SimpleFormatter.format(SimpleFormatter.java:63) at org.apache.juli.FileHandler.publish(FileHandler.java:198) at java.util.logging.Logger.log(Logger.java:478) at java.util.logging.Logger.doLog(Logger.java:501) at java.util.logging.Logger.log(Logger.java:524) at oracle.security.am.common.nap.util.NAPLogger.log(NAPLogger.java:60) at oracle.security.am.common.nap.util.pool.ObjectPoolManager.shutdown(ObjectPoolManager.java:267) at oracle.security.am.common.aaaclient.ObAAAServiceClient.close(ObAAAServiceClient.java:1239) at oracle.security.am.common.aaaclient.ObAAAServiceClient.finalize(ObAAAServiceClient.java:2548) at jrockit.memory.Finalizer.doFinalize(Finalizer.java:29) at jrockit.memory.Finalizer.access$300(Finalizer.java:12) at jrockit.memory.Finalizer$4.run(Finalizer.java:186) at java.lang.Thread.run(Thread.java:662) java.util.logging.ErrorManager: 5 java.lang.NullPointerException at java.util.ListResourceBundle.handleGetObject(ListResourceBundle.java:109) at java.util.ResourceBundle.getObject(ResourceBundle.java:368) at java.util.ResourceBundle.getString(ResourceBundle.java:334) at java.util.logging.Formatter.formatMessage(Formatter.java:108) at java.util.logging.SimpleFormatter.format(SimpleFormatter.java:63) at java.util.logging.StreamHandler.publish(StreamHandler.java:179) at java.util.logging.ConsoleHandler.publish(ConsoleHandler.java:88) at java.util.logging.Logger.log(Logger.java:478) at java.util.logging.Logger.doLog(Logger.java:501) at java.util.logging.Logger.log(Logger.java:524) at oracle.security.am.common.nap.util.NAPLogger.log(NAPLogger.java:60) at oracle.security.am.common.nap.util.pool.ObjectPoolManager.shutdown(ObjectPoolManager.java:267) at oracle.security.am.common.aaaclient.ObAAAServiceClient.close(ObAAAServiceClient.java:1239) at oracle.security.am.common.aaaclient.ObAAAServiceClient.finalize(ObAAAServiceClient.java:2548) at jrockit.memory.Finalizer.doFinalize(Finalizer.java:29) at jrockit.memory.Finalizer.access$300(Finalizer.java:12) at jrockit.memory.Finalizer$4.run(Finalizer.java:186) at java.lang.Thread.run(Thread.java:662) Jul 7, 2012 8:21:31 AM org.apache.coyote.http11.Http11Protocol start INFO: Starting Coyote HTTP/1.1 on http-8080 The oracle ones are because I'm using stuff from the Oracle OAM SDK, and I am initializing the SDK in the servlet init() method (which appears to be working). Jim - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: NullPointerException/java.util.logging.ErrorManager: 5 when have load-on-startup
Mark Thomas ma...@apache.org wrote: On 07/07/2012 17:33, oh...@cox.net wrote: Trace A: java.util.logging.ErrorManager: 5 java.lang.NullPointerException at java.util.ListResourceBundle.handleGetObject(ListResourceBundle.java:109) at java.util.ResourceBundle.getObject(ResourceBundle.java:368) at java.util.ResourceBundle.getString(ResourceBundle.java:334) at java.util.logging.Formatter.formatMessage(Formatter.java:108) at java.util.logging.SimpleFormatter.format(SimpleFormatter.java:63) at org.apache.juli.FileHandler.publish(FileHandler.java:198) at java.util.logging.Logger.log(Logger.java:478) at java.util.logging.Logger.doLog(Logger.java:501) at java.util.logging.Logger.log(Logger.java:524) at oracle.security.am.common.nap.util.NAPLogger.log(NAPLogger.java:60) at oracle.security.am.common.nap.util.pool.ObjectPoolManager.shutdown(ObjectPoolManager.java:267) at oracle.security.am.common.aaaclient.ObAAAServiceClient.close(ObAAAServiceClient.java:1239) at oracle.security.am.common.aaaclient.ObAAAServiceClient.finalize(ObAAAServiceClient.java:2548) at jrockit.memory.Finalizer.doFinalize(Finalizer.java:29) at jrockit.memory.Finalizer.access$300(Finalizer.java:12) at jrockit.memory.Finalizer$4.run(Finalizer.java:186) at java.lang.Thread.run(Thread.java:662) java.util.logging.ErrorManager: 5 Trace B: java.lang.NullPointerException at java.util.ListResourceBundle.handleGetObject(ListResourceBundle.java:109) at java.util.ResourceBundle.getObject(ResourceBundle.java:368) at java.util.ResourceBundle.getString(ResourceBundle.java:334) at java.util.logging.Formatter.formatMessage(Formatter.java:108) at java.util.logging.SimpleFormatter.format(SimpleFormatter.java:63) at java.util.logging.StreamHandler.publish(StreamHandler.java:179) at java.util.logging.ConsoleHandler.publish(ConsoleHandler.java:88) at java.util.logging.Logger.log(Logger.java:478) at java.util.logging.Logger.doLog(Logger.java:501) at java.util.logging.Logger.log(Logger.java:524) at oracle.security.am.common.nap.util.NAPLogger.log(NAPLogger.java:60) at oracle.security.am.common.nap.util.pool.ObjectPoolManager.shutdown(ObjectPoolManager.java:267) at oracle.security.am.common.aaaclient.ObAAAServiceClient.close(ObAAAServiceClient.java:1239) at oracle.security.am.common.aaaclient.ObAAAServiceClient.finalize(ObAAAServiceClient.java:2548) at jrockit.memory.Finalizer.doFinalize(Finalizer.java:29) at jrockit.memory.Finalizer.access$300(Finalizer.java:12) at jrockit.memory.Finalizer$4.run(Finalizer.java:186) at java.lang.Thread.run(Thread.java:662) Do you see any Tomcat code in Trace B? No? Neither do I. So what makes you think there is a Tomcat problem here? Given the only difference in Trace A is that you are using a Tomcat Handler rather than the console I don't see anything here to suggest a Tomcat bug. Looking at the source for java.util.ListResourceBundle, the key or the value being used for the log message is null. That makes this an OAM bug, not a Tomcat one. Mark Hi Mark, Just to be clear, I wasn't pointing to a Tomcat bug :(... I'm just trying to figure out why the NullPointerException doesn't happen when I don't have load-on-startup in my servlet's web.xml, but does happen when I have load-on-startup in the web.xml. Also, BTW, if I stop then start the servlet app using the Tomcat manager app, I don't get the NullPointerException. What might the difference be between when the load-on-startup is in the web.xml vs. not being in the web.xml? Doesn't Tomcat just load and call the servlet's init() method when the load-on-startup is present? I'm kind of guessing it may be a timing type issue, as in my servlet's init() method, I initialize the Oracle stuff. My initialization call returns, but it may be that there's still something going on behind-the-scenes that's not quite done. Thanks, Jim - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Followup old thread(s) about Apache, AJP, and tomcatAuthentication, and roles
Hi, Awhile ago, I had this thread, where I originally trying to see if I could get Tomcat, using the AJP connector and tomcatAuthentication to work, when I had an OAM webgate installed on the Apache proxy fronting the Tomcat: http://tomcat.10.n6.nabble.com/Do-any-of-the-Tomcat-LDAP-type-realms-support-quot-no-password-quot-authentication-td2055999.html The bottom line at the time was that it didn't seem to work, probably because the user name wasn't being populated in the AJP packet. I'm picking this subject up again, from scratch, because I happened to find out that mod_ssl has a directive, SSLUserName that is suppose to populate the user name after 2-way SSL authentication. So, I set up a new Apache and Tomcat, and I added that SSLUserName directive to the Apache httpd-ssl.conf, but not with the OAM agent yet, and did some tests, and it looks like it ALMOST worked, i.e., it looks like *A* user name is being passed to Tomcat (in Tomcat logs, I see already authenticated and the username from the SSL client cert. However, I get a 403/access denied on my test web app. This is even though I have a role in the realm (the original/default flatfile realm), so it looks like even though the tomcatAuthentication=false is kind of working, the user is not picking up the Tomcat roles. So, I've been googling, and found this: http://tomcat.10.n6.nabble.com/Container-managed-security-and-Proxy-support-td2168081.html which seems to describes the problem I'm encountering, but that thread didn't seem to conclude. So, does anyway know, when a user is asserted into Tomcat via tomcatAuthentication='false', does that authenticated user pickup the Tomcat roles from the realm? There's one msg in the thread from Pid saying that a custom realm is needed, and then Andre Warnier seemed to think that wasn't the case, but then nothing after that. Thanks, Jim - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
How to get debug output from JNDIRealm.java?
Hi,
I'm trying to debug some problems while enabling JNDIRealm in Tomcat 6.0.33.
I've gotten Tomcat itself to output debug logging, but looking at the
JNDIRealm.java code, e.g.:
http://www.docjar.com/html/api/org/apache/catalina/realm/JNDIRealm.java.html
It looks like there's a bunch of debug output that the Java code *can* output.
The problem is that I don't know how to enable that debug output/logging?
I'm assuming that something needs to be added to the Tomcat logging.properties,
but can anyone tell me what that should be to get the messages such as would be
output by the following code in JNDIRealm.java:
1044 if (username == null || username.equals()
1045 || credentials == null || credentials.equals()) {
1046 if (containerLog.isDebugEnabled())
1047 containerLog.debug(username null or empty: returning
null principal.);
1048 return (null);
??
Thanks,
Jim
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to get debug output from JNDIRealm.java?
Konstantin Kolinko knst.koli...@gmail.com wrote:
2012/5/17 oh...@cox.net:
Hi,
I'm trying to debug some problems while enabling JNDIRealm in Tomcat 6.0.33.
I've gotten Tomcat itself to output debug logging, but looking at the
JNDIRealm.java code, e.g.:
http://www.docjar.com/html/api/org/apache/catalina/realm/JNDIRealm.java.html
It looks like there's a bunch of debug output that the Java code *can*
output.
The problem is that I don't know how to enable that debug output/logging?
I'm assuming that something needs to be added to the Tomcat
logging.properties, but can anyone tell me what that should be to get the
messages such as would be output by the following code in JNDIRealm.java:
1044 if (username == null || username.equals()
1045 || credentials == null || credentials.equals()) {
1046 if (containerLog.isDebugEnabled())
1047 containerLog.debug(username null or empty:
returning null principal.);
1048 return (null);
See
http://tomcat.apache.org/tomcat-6.0-doc/logging.html#Servlets_logging_API
The containerLog writes to a category that has name similar to the
following:
org.apache.catalina.core.ContainerBase.[${engine}].[${host}].[${context}]
If your realm in in Context, then you will get the full name.
If it is in Host, you will get [engine][host] only,
and so on.
You may also want to run under debugger,
http://wiki.apache.org/tomcat/FAQ/Developing#Debugging
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Konstantin,
Here's a partial stripped down version of my server.xml, to show the JNDIRealm
part in context. I guess that it's in the Engine?
So, how do I enable the output from the JNDIRealm?
I checked the link you included, but it reflected what you said, but I'm
unclear about exactly what I need to do (e.g., add to logging.properties) to
get the debug output?
Thanks,
Jim
P.S. Per other responses, if you could help explain, it might clarify things
for others on the mailing list, who also appear to not know how to do this?
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to get debug output from JNDIRealm.java?
oh...@cox.net wrote:
Konstantin Kolinko knst.koli...@gmail.com wrote:
2012/5/17 oh...@cox.net:
Hi,
I'm trying to debug some problems while enabling JNDIRealm in Tomcat
6.0.33.
I've gotten Tomcat itself to output debug logging, but looking at the
JNDIRealm.java code, e.g.:
http://www.docjar.com/html/api/org/apache/catalina/realm/JNDIRealm.java.html
It looks like there's a bunch of debug output that the Java code *can*
output.
The problem is that I don't know how to enable that debug output/logging?
I'm assuming that something needs to be added to the Tomcat
logging.properties, but can anyone tell me what that should be to get the
messages such as would be output by the following code in JNDIRealm.java:
1044 if (username == null || username.equals()
1045 || credentials == null || credentials.equals()) {
1046 if (containerLog.isDebugEnabled())
1047 containerLog.debug(username null or empty:
returning null principal.);
1048 return (null);
See
http://tomcat.apache.org/tomcat-6.0-doc/logging.html#Servlets_logging_API
The containerLog writes to a category that has name similar to the
following:
org.apache.catalina.core.ContainerBase.[${engine}].[${host}].[${context}]
If your realm in in Context, then you will get the full name.
If it is in Host, you will get [engine][host] only,
and so on.
You may also want to run under debugger,
http://wiki.apache.org/tomcat/FAQ/Developing#Debugging
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Konstantin,
Here's a partial stripped down version of my server.xml, to show the
JNDIRealm part in context. I guess that it's in the Engine?
So, how do I enable the output from the JNDIRealm?
I checked the link you included, but it reflected what you said, but I'm
unclear about exactly what I need to do (e.g., add to logging.properties) to
get the debug output?
Thanks,
Jim
P.S. Per other responses, if you could help explain, it might clarify things
for others on the mailing list, who also appear to not know how to do this?
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
P.P.S. In case it helps, here is my current logging.properties:
# Licensed to the Apache Software Foundation (ASF) under one or more
# contributor license agreements. See the NOTICE file distributed with
# this work for additional information regarding copyright ownership.
# The ASF licenses this file to You under the Apache License, Version 2.0
# (the License); you may not use this file except in compliance with
# the License. You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an AS IS BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
handlers = 1catalina.org.apache.juli.FileHandler,
2localhost.org.apache.juli.FileHandler, 3manager.org.apache.juli.FileHandler,
4host-manager.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
.handlers = 1catalina.org.apache.juli.FileHandler,
java.util.logging.ConsoleHandler
# Handler specific properties.
# Describes specific configuration info for Handlers.
1catalina.org.apache.juli.FileHandler.level = FINE
1catalina.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
1catalina.org.apache.juli.FileHandler.prefix = catalina.
# JL - FOLLOWING ADDED FOR DEBUG PER:
http://dev-answers.blogspot.com/2010/03/enable-debugtrace-level-logging-for.html
1catalina.org.apache.juli.FileHandler.bufferSize = -1
2localhost.org.apache.juli.FileHandler.level = FINE
2localhost.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
2localhost.org.apache.juli.FileHandler.prefix = localhost.
3manager.org.apache.juli.FileHandler.level = FINE
3manager.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
3manager.org.apache.juli.FileHandler.prefix = manager.
4host-manager.org.apache.juli.FileHandler.level = FINE
4host-manager.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
4host-manager.org.apache.juli.FileHandler.prefix = host-manager.
java.util.logging.ConsoleHandler.level = FINE
java.util.logging.ConsoleHandler.formatter =
Re: How to get debug output from JNDIRealm.java?
oh...@cox.net wrote:
oh...@cox.net wrote:
Konstantin Kolinko knst.koli...@gmail.com wrote:
2012/5/17 oh...@cox.net:
Hi,
I'm trying to debug some problems while enabling JNDIRealm in Tomcat
6.0.33.
I've gotten Tomcat itself to output debug logging, but looking at the
JNDIRealm.java code, e.g.:
http://www.docjar.com/html/api/org/apache/catalina/realm/JNDIRealm.java.html
It looks like there's a bunch of debug output that the Java code *can*
output.
The problem is that I don't know how to enable that debug
output/logging?
I'm assuming that something needs to be added to the Tomcat
logging.properties, but can anyone tell me what that should be to get
the messages such as would be output by the following code in
JNDIRealm.java:
1044 if (username == null || username.equals()
1045 || credentials == null || credentials.equals()) {
1046 if (containerLog.isDebugEnabled())
1047 containerLog.debug(username null or empty:
returning null principal.);
1048 return (null);
See
http://tomcat.apache.org/tomcat-6.0-doc/logging.html#Servlets_logging_API
The containerLog writes to a category that has name similar to the
following:
org.apache.catalina.core.ContainerBase.[${engine}].[${host}].[${context}]
If your realm in in Context, then you will get the full name.
If it is in Host, you will get [engine][host] only,
and so on.
You may also want to run under debugger,
http://wiki.apache.org/tomcat/FAQ/Developing#Debugging
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Konstantin,
Here's a partial stripped down version of my server.xml, to show the
JNDIRealm part in context. I guess that it's in the Engine?
So, how do I enable the output from the JNDIRealm?
I checked the link you included, but it reflected what you said, but I'm
unclear about exactly what I need to do (e.g., add to logging.properties)
to get the debug output?
Thanks,
Jim
P.S. Per other responses, if you could help explain, it might clarify
things for others on the mailing list, who also appear to not know how to
do this?
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
P.P.S. In case it helps, here is my current logging.properties:
# Licensed to the Apache Software Foundation (ASF) under one or more
# contributor license agreements. See the NOTICE file distributed with
# this work for additional information regarding copyright ownership.
# The ASF licenses this file to You under the Apache License, Version 2.0
# (the License); you may not use this file except in compliance with
# the License. You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an AS IS BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
handlers = 1catalina.org.apache.juli.FileHandler,
2localhost.org.apache.juli.FileHandler, 3manager.org.apache.juli.FileHandler,
4host-manager.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
.handlers = 1catalina.org.apache.juli.FileHandler,
java.util.logging.ConsoleHandler
# Handler specific properties.
# Describes specific configuration info for Handlers.
1catalina.org.apache.juli.FileHandler.level = FINE
1catalina.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
1catalina.org.apache.juli.FileHandler.prefix = catalina.
# JL - FOLLOWING ADDED FOR DEBUG PER:
http://dev-answers.blogspot.com/2010/03/enable-debugtrace-level-logging-for.html
1catalina.org.apache.juli.FileHandler.bufferSize = -1
2localhost.org.apache.juli.FileHandler.level = FINE
2localhost.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
2localhost.org.apache.juli.FileHandler.prefix = localhost.
3manager.org.apache.juli.FileHandler.level = FINE
3manager.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
3manager.org.apache.juli.FileHandler.prefix = manager.
4host-manager.org.apache.juli.FileHandler.level = FINE
4host-manager.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
Re: How to get debug output from JNDIRealm.java?
Konstantin Kolinko knst.koli...@gmail.com wrote:
2012/5/17 oh...@cox.net:
See
http://tomcat.apache.org/tomcat-6.0-doc/logging.html#Servlets_logging_API
Here's a partial stripped down version of my server.xml, to show the
JNDIRealm part in context. I guess that it's in the Engine?
So, how do I enable the output from the JNDIRealm?
I checked the link you included, but it reflected what you said, but I'm
unclear about exactly what I need to do (e.g., add to logging.properties)
to get the debug output?
Thanks,
Jim
P.S. Per other responses, if you could help explain, it might clarify
things for others on the mailing list, who also appear to not know how to
do this?
\
P.P.S. In case it helps, here is my current logging.properties:
# For example, to log debug messages in ContextConfig and HostConfig
# classes and to log only warnings and errors in other
# org.apache.catalina.** classes, uncomment these lines:
#org.apache.catalina.startup.ContextConfig.level = FINE
#org.apache.catalina.startup.HostConfig.level = FINE
#org.apache.catalina.level = WARNING
I have not see your server.xml, but let's suppose that your Realm is
in the Engine.
The logging category for engine will be
org.apache.catalina.core.ContainerBase.[Catalina]
To enable debug logging for it you have to
1. add the following line to logging.properties file and
2. restart Tomcat:
org.apache.catalina.core.ContainerBase.[Catalina].level = FINE
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Hi,
FYI, I posted a msg with the server.xml snippet, which I had forgotten.
Also, I just tried adding the line you suggested to logging.properties, then
bounced Tomcat.
On startup, I do see some new messages:
May 17, 2012 1:40:48 PM org.apache.catalina.realm.RealmBase init
FINE: Register Realm Catalina:type=Realm,realmPath=/realm0
May 17, 2012 1:40:48 PM org.apache.catalina.realm.JNDIRealm
getDirectoryContextEnvironment
FINE: Connecting to URL ldap://oidoif:6501
but, just to test if the logging was outputing anything, I access Tomcat
/manager, with incorrect username/password, and I don't see anything from
JNDIRealm in the logs.
Looking at JNDIRealm.java code, I see this code:
944 // Authenticate the specified username if possible
945 principal = authenticate(context, username,
credentials);
946
947 } catch (NullPointerException e) {
948 /* BZ 42449 - Kludge Sun's LDAP provider
949 with broken SSL
950 */
951 // log the exception so we know it's there.
952 containerLog.warn(sm.getString(jndiRealm.exception),
e);
Shouldn't the logs show some kind of exception message for the above lines?
Thanks,
Jim
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to get debug output from JNDIRealm.java?
oh...@cox.net wrote:
Konstantin Kolinko knst.koli...@gmail.com wrote:
2012/5/17 oh...@cox.net:
See
http://tomcat.apache.org/tomcat-6.0-doc/logging.html#Servlets_logging_API
Here's a partial stripped down version of my server.xml, to show the
JNDIRealm part in context. I guess that it's in the Engine?
So, how do I enable the output from the JNDIRealm?
I checked the link you included, but it reflected what you said, but I'm
unclear about exactly what I need to do (e.g., add to
logging.properties) to get the debug output?
Thanks,
Jim
P.S. Per other responses, if you could help explain, it might clarify
things for others on the mailing list, who also appear to not know how
to do this?
\
P.P.S. In case it helps, here is my current logging.properties:
# For example, to log debug messages in ContextConfig and HostConfig
# classes and to log only warnings and errors in other
# org.apache.catalina.** classes, uncomment these lines:
#org.apache.catalina.startup.ContextConfig.level = FINE
#org.apache.catalina.startup.HostConfig.level = FINE
#org.apache.catalina.level = WARNING
I have not see your server.xml, but let's suppose that your Realm is
in the Engine.
The logging category for engine will be
org.apache.catalina.core.ContainerBase.[Catalina]
To enable debug logging for it you have to
1. add the following line to logging.properties file and
2. restart Tomcat:
org.apache.catalina.core.ContainerBase.[Catalina].level = FINE
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Hi,
FYI, I posted a msg with the server.xml snippet, which I had forgotten.
Also, I just tried adding the line you suggested to logging.properties, then
bounced Tomcat.
On startup, I do see some new messages:
May 17, 2012 1:40:48 PM org.apache.catalina.realm.RealmBase init
FINE: Register Realm Catalina:type=Realm,realmPath=/realm0
May 17, 2012 1:40:48 PM org.apache.catalina.realm.JNDIRealm
getDirectoryContextEnvironment
FINE: Connecting to URL ldap://oidoif:6501
but, just to test if the logging was outputing anything, I access Tomcat
/manager, with incorrect username/password, and I don't see anything from
JNDIRealm in the logs.
Looking at JNDIRealm.java code, I see this code:
944 // Authenticate the specified username if possible
945 principal = authenticate(context, username,
credentials);
946
947 } catch (NullPointerException e) {
948 /* BZ 42449 - Kludge Sun's LDAP provider
949 with broken SSL
950 */
951 // log the exception so we know it's there.
952
containerLog.warn(sm.getString(jndiRealm.exception), e);
Shouldn't the logs show some kind of exception message for the above lines?
Thanks,
Jim
Hi,
I think that the code snippet I sent earlier was the wrong one, but it seems
like I still should have gotten some output logging for the following code from
JNDIRealm.java?
1003 } catch (NamingException e) {
1004
1005 // Log the problem for posterity
1006 containerLog.error(sm.getString(jndiRealm.exception), e);
1007
1008 // Close the connection so that it gets reopened next time
1009 if (context != null)
1010 close(context);
1011
1012 // Return not authenticated for this request
1013 if (containerLog.isDebugEnabled())
1014 containerLog.debug(Returning null principal.);
1015 return (null);
i.e., I should have seen Returning null principal in the Tomcat logging?
Jim
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to get debug output from JNDIRealm.java?
Christopher Schultz ch...@christopherschultz.net wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim,
On 5/17/12 1:56 PM, oh...@cox.net wrote:
I think that the code snippet I sent earlier was the wrong one, but
it seems like I still should have gotten some output logging for
the following code from JNDIRealm.java?
1003 } catch (NamingException e) { 1004 1005
// Log the problem for posterity 1006
containerLog.error(sm.getString(jndiRealm.exception), e); 1007
1008 // Close the connection so that it gets
reopened next time 1009 if (context != null) 1010
close(context); 1011 1012 // Return not
authenticated for this request 1013 if
(containerLog.isDebugEnabled()) 1014
containerLog.debug(Returning null principal.); 1015
return (null);
i.e., I should have seen Returning null principal in the Tomcat
logging?
Why do you think that a NamingException is being caught?
- -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/
iEYEARECAAYFAk+1ZGwACgkQ9CaO5/Lv0PCnXACfQ053y47B7MLmIbpznhPufSQK
Y3MAoJ4TkTP3/HcwlelKvOm/wISz5fbI
=H5G4
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Hi,
I didn't say that I didn't think that the exception was not being caught, but
rather that I'm not seeing any associated output in any of the Tomcat logs (or
the console out), e.g., I don't see a log msg with Returning null principal.
What else do I need to configure in logging.properties or otherwise to get the
output logged?
Thanks,
Jim
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Custom realm.authenticate() that would work with any realm - possible?
Hi Chuck, Thanks for the pointer to the CombinedRealm, but, as I've been working with the test implementation that I mentioned for extending the JNDIRealm, I *think* that I'm coming to the realization that I was asking for is probably not possible, or at least not practical, unless I'm totally missing something. The reason I'm thinking this is that, for example, in the case where I'm extending the JNDIRealm, in my custom JNDIRealm, I've had to make calls to the super.set() methods to set parameters in the JNDIRealm class that I'm extending, in order for the calls that I then make to the super class (e.g., super.getUser()) to work. Again, I may be missing something, or doing things completely wrong, but if not, then that means that if I was going to try go design my realm extender to support all of the normal realm types, my code would get fairly complex, because it'd have to know all of the parameters for all of the different realm types, in order to set the parameters in the super class. It was messy enough doing that for just one realm type (JNDIRealm), and for just calling two methods in the super JNDIRealm class, but I imagine if I was trying to extend 5 or 6 realm types, all in one piece of code, it'd be a real mess. Anyway, if anyone has some insight into doing something like this, please post back. Otherwise, I think the best approach is to implement one realm extension for each of the normal Tomcat realms that we'll want to be able to support. Thanks again, Jim Caldarale wrote: From: oh...@cox.net [mailto:oh...@cox.net] Subject: Custom realm.authenticate() that would work with any realm - possible? I was wondering if there might, perhaps, be another way to do what I'm trying to do (basically have an realm.authenticate() method that doesn't require a password, but that would work with any realm? Look at the CombinedRealm; you might be able to use your no-password realm in conjunction with one of the others, since the doc says Authentication against any Realm will be sufficient to authenticate the user. I don't know if that will get you the necessary roles established. http://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html#CombinedRealm - 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. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Custom realm.authenticate() that would work with any realm - possible?
André Warnier a...@ice-sa.com wrote: Hi Jim. As I recall, your original issue was that there is no OAM plugin for Tomcat, and therefore, you are doing the OAM authentication within the front-end Apache, and then passing the user-id to Tomcat. And then, you find yourself in Tomcat with a user-id, but without any roles corresponding to this user-id. And in order to get such roles, you are now facing a rather complex programming issue at the Tomcat level. I wrote this before, but let me repeat it : are you not doing a lot of work un-necessarily there, and should you not look at this another way ? As far as I understand these Tomcat-level matters, a role in Tomcat is used to control access to resources. And you seem to use Tomcat's declarative type of acess-control, which means that you allow access or not to a given webapp, in function of whether the user-id (which is passed to Tomcat by the front-end) has or not a particular role. And, in the OAM system globally, the fact that a user has or not access to a particular resource, is already managed at the OAM level; but to which OAM level, unfortunately right now, you do not have access from Tomcat. But in this case, all your accesses to Tomcat webapps *always* happen through the front-end, because it is this front-end which obtains the user-id (from OAM) and later passes it to Tomcat. And this front-end thus *has* access to the OAM data. So what is stopping you from : - not using any authentication/access-control at the Tomcat level - but checking all this at the Apache httpd front-end level ? Example : suppose you have 3 webapps app1, app2, app3. You could have at the front-end level these sections : Location /app1 SetHandler jakarta-servlet (same as JkMount /app1) AuthType Oblix require valid-user require .. (whatever) /Location Location /app2 SetHandler jakarta-servlet (same as JkMount /app2) AuthType Oblix require valid-user require .. (whatever) /Location Location /app3 SetHandler jakarta-servlet (same as JkMount /app3) AuthType Oblix require valid-user require .. (whatever) /Location If the user does not pass muster for /app1 according to OAM, then the call will never even make it Tomcat. If the user passes muster, then you can let them access Tomcat's /app1 application, as they have been checked for it. Or am I missing something ? Hi, Yes, you are missing something, something akin to the last mile. Following your example, of /app1, suppose that that is a webapp that requires a known user (principal). The security JSP example in Tomcat is an example of this. You can use something like OAM to protect (permit or deny) access, but once you get to the /app1, you wouldn't be logged into the app itself, not only for declarative type constraints, but also, for example, if the app does things like give you access to only specified resources (e.g., database tables, etc.) based on who you are. So, for example with the security example, with just OAM, and without anything else, you end up on the form login page, instead of it saying Hi, x. Just some examples there... Jim - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Custom realm.authenticate() that would work with any realm - possible?
André Warnier a...@ice-sa.com wrote:
oh...@cox.net wrote:
André Warnier a...@ice-sa.com wrote:
Hi Jim.
As I recall, your original issue was that there is no OAM plugin for
Tomcat, and
therefore, you are doing the OAM authentication within the front-end
Apache, and then
passing the user-id to Tomcat.
And then, you find yourself in Tomcat with a user-id, but without any
roles
corresponding to this user-id.
And in order to get such roles, you are now facing a rather complex
programming issue at
the Tomcat level.
I wrote this before, but let me repeat it : are you not doing a lot of
work un-necessarily
there, and should you not look at this another way ?
As far as I understand these Tomcat-level matters, a role in Tomcat is
used to control
access to resources.
And you seem to use Tomcat's declarative type of acess-control, which
means that you
allow access or not to a given webapp, in function of whether the user-id
(which is passed
to Tomcat by the front-end) has or not a particular role.
And, in the OAM system globally, the fact that a user has or not access to
a particular
resource, is already managed at the OAM level; but to which OAM level,
unfortunately right
now, you do not have access from Tomcat.
But in this case, all your accesses to Tomcat webapps *always* happen
through the
front-end, because it is this front-end which obtains the user-id (from
OAM) and later
passes it to Tomcat. And this front-end thus *has* access to the OAM data.
So what is stopping you from :
- not using any authentication/access-control at the Tomcat level
- but checking all this at the Apache httpd front-end level
?
Example : suppose you have 3 webapps app1, app2, app3.
You could have at the front-end level these sections :
Location /app1
SetHandler jakarta-servlet (same as JkMount /app1)
AuthType Oblix
require valid-user
require .. (whatever)
/Location
Location /app2
SetHandler jakarta-servlet (same as JkMount /app2)
AuthType Oblix
require valid-user
require .. (whatever)
/Location
Location /app3
SetHandler jakarta-servlet (same as JkMount /app3)
AuthType Oblix
require valid-user
require .. (whatever)
/Location
If the user does not pass muster for /app1 according to OAM, then the
call will never
even make it Tomcat.
If the user passes muster, then you can let them access Tomcat's /app1
application, as
they have been checked for it.
Or am I missing something ?
Hi,
Yes, you are missing something, something akin to the last mile.
Following your example, of /app1, suppose that that is a webapp that
requires a known user (principal). The security JSP example in Tomcat is
an example of this.
You can use something like OAM to protect (permit or deny) access, but once
you get to the /app1, you wouldn't be logged into the app itself, not
only for declarative type constraints, but also, for example, if the app
does things like give you access to only specified resources (e.g.,
database tables, etc.) based on who you are. So, for example with the
security example, with just OAM, and without anything else, you end up on
the form login page, instead of it saying Hi, x.
Just some examples there...
Ok, I may be misunderstanding the scope of OAM within your organisation,
maybe because I
am going by the OAM documentation as I was browsingt it on the web.
If you are using it only as an SSO system and only to get a user-id, then
your example is
correct.
From the documentation, it just sounded like it is much more than that.
What I was trying to say is more or less this : if all accesses to your
Tomcat
applications necessarily go through the front-end, then for all intents and
purposes the
front-end and Tomcat are functionally one and the same system. Or, to put it
another way,
you could consider the front-end as just a part of Tomcat; or again to put it
yet another
way, your front-end /is/ your Tomcat authentication realm.
And whatever information you can obtain at the front-end level, you can pass
to Tomcat as
request attributes, which attributes you can retrieve in Tomat and pass to
your
applications, for them to use to make any access decision they want.
Hi Andre,
The thing is, as you yourself mentioned earlier, some (maybe a lot) of systems
(apps), utilize declarative security constraints (e.g., in web.xml), in order
to avoid having to put code in the app that does stuff like (this is just
pseudo-code):
if (user.isInRole(xyz) {
.
.
}
If the app/webapp utilizes declarative security (constraints, etc.), then just
protecting the app's URIs at the Apache isn't sufficient.
I'm not wanting to get in to a debate about the pros/cons of declarative vs.
programmatic. The area that I'm in (my job) is
Custom realm.authenticate() that would work with any realm - possible?
Hi, This is a followup to an earlier thread, Do any of the Tomcat LDAP-type realms support no password authentication?. As I mentioned in that earlier thread, I'm still new to Tomcat, and still trying to find my way around, and understand (somewhat) its security design, so apologies in advance if my terminology is incorrect. Ok. I've been experimenting with writing what I think is called a custom realm, that would have a no password authenticate() method. What I think that I've been able to do is to implement a new realm where all I do in my code is override the uthenticate(Context, string, string) method. For my initial attempt, I'm just extending the JNDIRealm, and just overriding that one method, and I think that this works. However, ideally, I really want to be able to do this (override the authenticate() method with any of the default realms that come with Tomcat, whereas with the approach that I'm currently working (extending the JNDIRealm), in order to do this for all the different realm types, I'd have to implement something similar, with a custom realm corresponding to each of the out-of-box Tomcat realm types. That might be ok, but I was wondering if there might, perhaps, be another way to do what I'm trying to do (basically have an realm.authenticate() method that doesn't require a password, but that would work with any realm? Thanks, Jim - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support no password authentication?
Rainer Jung rainer.j...@kippdata.de wrote: On 02.12.2011 17:49, André Warnier wrote: oh...@cox.net wrote: oh...@cox.net wrote: André Warnier a...@ice-sa.com wrote: oh...@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 9test 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
Re: Do any of the Tomcat LDAP-type realms support no password authentication?
André Warnier a...@ice-sa.com wrote:
oh...@cox.net wrote:
...
Rainer Jung rainer.j...@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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support no password authentication?
Rainer Jung rainer.j...@kippdata.de wrote:
On 05.12.2011 10:42, oh...@cox.net wrote:
André Warniera...@ice-sa.com wrote:
oh...@cox.net wrote:
...
Rainer Jungrainer.j...@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
RE: Do any of the Tomcat LDAP-type realms support no password authentication?
oh...@cox.net wrote: Caldarale wrote: From: oh...@cox.net [mailto:oh...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support no password authentication?
André Warnier a...@ice-sa.com wrote:
André Warnier wrote:
oh...@cox.net wrote:
oh...@cox.net wrote:
P.S. I forgot to mention:
As you know, I'd been using a sniffer, to see the data on the
Apache-to-Tomcat connection. I have a sniff from earlier, where I
was using ProxyPass ajp://, and, comparing that sniff vs. a sniff
that I have from when I tested with your suggested Location, in the
latter sniff, I can see the userID (testuser), whereas in the former,
that same area in the hex dump is basically just null-terminated
strings.
So, it appears like, when the OAM stuff and the ajp: stuff is in the
Apache .conf, as you were guessing, the userID isn't making it into
the Apache-to-Tomcat/AJP connection at all.
Jim
Hi,
Sorry for the top-post :(...
Here're the sniffs from the tests that I did:
a) Working (OAM disabled, Location per Andre):
12 34 02 AB 02 02 00 08 48 54 54 50 2F 31 2E 31 .4.«
HTTP/1.1 0010 00 00 1F 2F 73 61 6D 70 6C 65 73 61 6A 70 2F 73
.../samp lesajp/s 0020 73 6F 41 4D 54 6F 6D 63 61 74 54 65 73 74
2E 6A soAMTomc atTest.j 0030 73 70 00 00 0B 31 39 32 2E 31 36
38 2E 30 2E 37 sp...192 .168.0.7 0040 00 FF FF 00 14 61 70 61
63 68 65 31 2E 77 68 61 .ÿÿ..apa che1.wha 0050 74 65 76 65 72
2E 63 6F 6D 00 01 BB 01 00 09 A0 tever.co m..»... 0060 0B 00
14 61 70 61 63 68 65 31 2E 77 68 61 74 65 ...apach e1.whate
0070 76 65 72 2E 63 6F 6D 00 A0 0E 00 3F 4D 6F 7A 69 ver.com.
..?Mozi 0080 6C 6C 61 2F 35 2E 30 20 28 57 69 6E 64 6F 77 73
lla/5.0 (Windows 0090 20 4E 54 20 36 2E 31 3B 20 72 76 3A 38 2E
30 29NT 6.1; rv:8.0) 00A0 20 47 65 63 6B 6F 2F 32 30 31 30
30 31 30 31 20Gecko/2 0100101 00B0 46 69 72 65 66 6F 78 2F
38 2E 30 00 A0 01 00 3F Firefox/ 8.0. ..? 00C0 74 65 78 74 2F
68 74 6D 6C 2C 61 70 70 6C 69 63 text/htm l,applic 00D0 61 74
69 6F 6E 2F 78 68 74 6D 6C 2B 78 6D 6C 2C ation/xh tml+xml,
00E0 61 70 70 6C 69 63 61 74 69 6F 6E 2F 78 6D 6C 3B applicat
ion/xml; 00F0 71 3D 30 2E 39 2C 2A 2F 2A 3B 71 3D 30 2E 38 00
q=0.9,*/ *;q=0.8. 0100 00 0F 41 63 63 65 70 74 2D 4C 61 6E 67 75
61 67 ..Accept -Languag 0110 65 00 00 0E 65 6E 2D 75 73 2C 65
6E 3B 71 3D 30 e...en-u s,en;q=0 0120 2E 35 00 00 0F 41 63 63
65 70 74 2D 45 6E 63 6F .5...Acc ept-Enco 0130 64 69 6E 67 00
00 0D 67 7A 69 70 2C 20 64 65 66 ding...g zip, def 0140 6C 61
74 65 00 00 0E 41 63 63 65 70 74 2D 43 68 late...A ccept-Ch
0150 61 72 73 65 74 00 00 1E 49 53 4F 2D 38 38 35 39 arset...
ISO-8859 0160 2D 31 2C 75 74 66 2D 38 3B 71 3D 30 2E 37 2C 2A
-1,utf-8 ;q=0.7,* 0170 3B 71 3D 30 2E 37 00 A0 06 00 0A 6B 65 65
70 2D ;q=0.7. ...keep- 0180 61 6C 69 76 65 00 A0 05 00 1A 42
61 73 69 63 20 alive. . ..Basic 0190 64 47 56 7A 64 48 56 7A
5A 58 49 36 59 6D 56 7A dGVzdHVz ZXI6YmVz 01A0 64 44 46 69 00
A0 08 00 01 30 00 03 00 08 74 65 dDFi. .. .0te 01B0 73 74
75 73 65 72 00 04 00 05 42 61 73 69 63 00 stuser.. ..Basic.
01C0 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_user0x03
?auth_type0x04
(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
Re: Do any of the Tomcat LDAP-type realms support no password authentication?
oh...@cox.net wrote:
André Warnier a...@ice-sa.com wrote:
André Warnier wrote:
oh...@cox.net wrote:
oh...@cox.net wrote:
P.S. I forgot to mention:
As you know, I'd been using a sniffer, to see the data on the
Apache-to-Tomcat connection. I have a sniff from earlier, where I
was using ProxyPass ajp://, and, comparing that sniff vs. a sniff
that I have from when I tested with your suggested Location, in the
latter sniff, I can see the userID (testuser), whereas in the former,
that same area in the hex dump is basically just null-terminated
strings.
So, it appears like, when the OAM stuff and the ajp: stuff is in the
Apache .conf, as you were guessing, the userID isn't making it into
the Apache-to-Tomcat/AJP connection at all.
Jim
Hi,
Sorry for the top-post :(...
Here're the sniffs from the tests that I did:
a) Working (OAM disabled, Location per Andre):
12 34 02 AB 02 02 00 08 48 54 54 50 2F 31 2E 31 .4.«
HTTP/1.1 0010 00 00 1F 2F 73 61 6D 70 6C 65 73 61 6A 70 2F 73
.../samp lesajp/s 0020 73 6F 41 4D 54 6F 6D 63 61 74 54 65 73 74
2E 6A soAMTomc atTest.j 0030 73 70 00 00 0B 31 39 32 2E 31 36
38 2E 30 2E 37 sp...192 .168.0.7 0040 00 FF FF 00 14 61 70 61
63 68 65 31 2E 77 68 61 .ÿÿ..apa che1.wha 0050 74 65 76 65 72
2E 63 6F 6D 00 01 BB 01 00 09 A0 tever.co m..»... 0060 0B 00
14 61 70 61 63 68 65 31 2E 77 68 61 74 65 ...apach e1.whate
0070 76 65 72 2E 63 6F 6D 00 A0 0E 00 3F 4D 6F 7A 69 ver.com.
..?Mozi 0080 6C 6C 61 2F 35 2E 30 20 28 57 69 6E 64 6F 77 73
lla/5.0 (Windows 0090 20 4E 54 20 36 2E 31 3B 20 72 76 3A 38 2E
30 29NT 6.1; rv:8.0) 00A0 20 47 65 63 6B 6F 2F 32 30 31 30
30 31 30 31 20Gecko/2 0100101 00B0 46 69 72 65 66 6F 78 2F
38 2E 30 00 A0 01 00 3F Firefox/ 8.0. ..? 00C0 74 65 78 74 2F
68 74 6D 6C 2C 61 70 70 6C 69 63 text/htm l,applic 00D0 61 74
69 6F 6E 2F 78 68 74 6D 6C 2B 78 6D 6C 2C ation/xh tml+xml,
00E0 61 70 70 6C 69 63 61 74 69 6F 6E 2F 78 6D 6C 3B applicat
ion/xml; 00F0 71 3D 30 2E 39 2C 2A 2F 2A 3B 71 3D 30 2E 38 00
q=0.9,*/ *;q=0.8. 0100 00 0F 41 63 63 65 70 74 2D 4C 61 6E 67 75
61 67 ..Accept -Languag 0110 65 00 00 0E 65 6E 2D 75 73 2C 65
6E 3B 71 3D 30 e...en-u s,en;q=0 0120 2E 35 00 00 0F 41 63 63
65 70 74 2D 45 6E 63 6F .5...Acc ept-Enco 0130 64 69 6E 67 00
00 0D 67 7A 69 70 2C 20 64 65 66 ding...g zip, def 0140 6C 61
74 65 00 00 0E 41 63 63 65 70 74 2D 43 68 late...A ccept-Ch
0150 61 72 73 65 74 00 00 1E 49 53 4F 2D 38 38 35 39 arset...
ISO-8859 0160 2D 31 2C 75 74 66 2D 38 3B 71 3D 30 2E 37 2C 2A
-1,utf-8 ;q=0.7,* 0170 3B 71 3D 30 2E 37 00 A0 06 00 0A 6B 65 65
70 2D ;q=0.7. ...keep- 0180 61 6C 69 76 65 00 A0 05 00 1A 42
61 73 69 63 20 alive. . ..Basic 0190 64 47 56 7A 64 48 56 7A
5A 58 49 36 59 6D 56 7A dGVzdHVz ZXI6YmVz 01A0 64 44 46 69 00
A0 08 00 01 30 00 03 00 08 74 65 dDFi. .. .0te 01B0 73 74
75 73 65 72 00 04 00 05 42 61 73 69 63 00 stuser.. ..Basic.
01C0 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_user0x03
?auth_type0x04
(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
Re: Do any of the Tomcat LDAP-type realms support no password authentication?
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support no password authentication?
André Warnier a...@ice-sa.com wrote: oh...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support no password authentication?
André Warnier a...@ice-sa.com wrote: oh...@cox.net wrote: André Warnier a...@ice-sa.com wrote: oh...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support no password authentication?
André Warnier a...@ice-sa.com wrote: oh...@cox.net wrote: André Warnier a...@ice-sa.com wrote: oh...@cox.net wrote: André Warnier a...@ice-sa.com wrote: oh...@cox.net wrote: 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
Re: Do any of the Tomcat LDAP-type realms support no password authentication?
oh...@cox.net wrote:
André Warnier a...@ice-sa.com wrote:
oh...@cox.net wrote:
André Warnier a...@ice-sa.com wrote:
oh...@cox.net wrote:
André Warnier a...@ice-sa.com wrote:
oh...@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
Re: Do any of the Tomcat LDAP-type realms support no password authentication?
oh...@cox.net wrote: oh...@cox.net wrote: André Warnier a...@ice-sa.com wrote: oh...@cox.net wrote: André Warnier a...@ice-sa.com wrote: oh...@cox.net wrote: André Warnier a...@ice-sa.com wrote: oh...@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
Re: Do any of the Tomcat LDAP-type realms support no password authentication?
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 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
RE: Do any of the Tomcat LDAP-type realms support no password authentication?
Caldarale wrote: From: oh...@cox.net [mailto:oh...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support no password authentication?
André Warnier a...@ice-sa.com wrote: oh...@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 9test ProxyPass ajp://weblogic1.whatever.com:8009/samplesajp ProxyPassReverseajp://weblogic1.whatever.com:8009/samplesajp /Location Jim - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support no password authentication?
oh...@cox.net wrote: André Warnier a...@ice-sa.com wrote: oh...@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 9test 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support no password authentication?
André Warnier a...@ice-sa.com wrote: oh...@cox.net wrote: oh...@cox.net wrote: André Warnier a...@ice-sa.com wrote: oh...@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 9test 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]
Re: Do any of the Tomcat LDAP-type realms support no password authentication?
Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim, On 12/2/11 11:26 AM, oh...@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):
Re: Do any of the Tomcat LDAP-type realms support no password authentication?
oh...@cox.net wrote: Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim, On 12/2/11 11:26 AM, oh...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support no password authentication?
André Warnier a...@ice-sa.com wrote: oh...@cox.net wrote: .. re-synchronising.. I've made some progress. I have a VirtualHost, so I had to add a JkMountCopy 'on' inside the VirtualHost, and now, it's at least proxying through to the Tomcat using mod_jk!! BUT, it's still not logging me into the Tomcat :(... I don't want to post the entire jk.log, so can someone point me to what to look for in there, maybe? Ok, so let's now continue on the mod_jk track, since you've got that part running. What you are looking for, is an AJP request attribute named remote_user (lowercase), in the packets which mod_jk sends to Tomcat. I don't know if that would be in the log, nor if there is any way to coerce mod_jk into putting it in the log. But since your Tomcat is not authenticating, chances are that it isn't there. So let's try to cheat, and force it to be there. In your Apache configuration, add this line : JkEnvVar remote_user blablabla and let's see what happens. (and after that, we'll try mod_rewrite or a combination) Andre, I had already tried including a JkEnvVar as you suggested in my httpd.conf, in order to try to hard-code getting SOMETHING to show up, but no joy :(... I've also tried a bunch of other variants: JkEnvVar REMOTE_USER also: JkEnvVar remote_user foobar also: JkEnvVar AJP_REMOTE_USER foobar Nothing works :(... This is really getting discouraging :(. It almost seems to me like that 'tomcatAuthentication' functionality doesn't even exist at all. I've searched the jk.log for multiple things, attr, remo, etc., and find nothing relevant/significant at all in there... Thanks, Jim - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support no password authentication?
André Warnier a...@ice-sa.com wrote: oh...@cox.net wrote: André Warnier a...@ice-sa.com wrote: oh...@cox.net wrote: .. re-synchronising.. I've made some progress. I have a VirtualHost, so I had to add a JkMountCopy 'on' inside the VirtualHost, and now, it's at least proxying through to the Tomcat using mod_jk!! BUT, it's still not logging me into the Tomcat :(... I don't want to post the entire jk.log, so can someone point me to what to look for in there, maybe? Ok, so let's now continue on the mod_jk track, since you've got that part running. What you are looking for, is an AJP request attribute named remote_user (lowercase), in the packets which mod_jk sends to Tomcat. I don't know if that would be in the log, nor if there is any way to coerce mod_jk into putting it in the log. But since your Tomcat is not authenticating, chances are that it isn't there. So let's try to cheat, and force it to be there. In your Apache configuration, add this line : JkEnvVar remote_user blablabla and let's see what happens. (and after that, we'll try mod_rewrite or a combination) Andre, I had already tried including a JkEnvVar as you suggested in my httpd.conf, in order to try to hard-code getting SOMETHING to show up, but no joy :(... I've also tried a bunch of other variants: JkEnvVar REMOTE_USER also: JkEnvVar remote_user foobar also: JkEnvVar AJP_REMOTE_USER foobar Nothing works :(... This is really getting discouraging :(. It almost seems to me like that 'tomcatAuthentication' functionality doesn't even exist at all. I've searched the jk.log for multiple things, attr, remo, etc., and find nothing relevant/significant at all in there... Do not get discouraged. I can guarantee that the tomcatAuthentication=false works, when the Apache front-end really does authenticate the user. I use this all the time. (Just not with the same SSO mechanism as you). I also know that JkEnvVar does work in general for setting request attributes at the Apache level, and have them passed to Tomcat by mod_jk, because I also us that regularly. (And there exists a similar functionality in mod_proxy_ajp). What may not work in the trials above, is that specifically this remote_user request attribute may be overwritten by mod_jk or mod_proxy_ajp, even when you have set it explicitly in Apache. After all, this feature is designed to do one thing : examine the request record of Apache for an authenticated user-id, and if one is set, pass it along to Tomcat over the AJP channel. If mod_jk/mod_proxy_ajp do not find such a user-id in the request record, they may just /clear/ the remote_user attribute, thus voiding our attempts at cheating. To verify this is relatively simple. Create the following Location section in Apache : Location /sampleajp AuthType Basic AuthName toTomcat AuthUserFile /some-path/passwords Require user testuser SetHandler jakarta-servlet SetEnv JK_WORKER_NAME tomcatA (- or whatever name your worker has) Location Note: the SetHandler and SetEnv lines above, in that Location, are equivalent to saying : JkMount /sampleajp/* tomcatA Then follow the instructions here to create the password file and the user testuser in it : http://httpd.apache.org/docs/2.2/howto/auth.html section : Getting it working If you try to access such a URL /sampleajp/*, the browser will popup a bssic auth dialog and force you to login. This will result in the request being duly authenticated for Apache, which /will/ result in the Apache user-id being passed to Tomcat. Then, once you have verified (in Tomcat) that it is so, have another look at the mod_jk logfile, to see if then you spot the attribute being passed. (You will know that it is passed, but it may still not show up the logs). If all of that works, then we know that in order for your scheme to work, you must somehow force the user-id obtained by your SSO system, to be also set in the Apache request record. Which should be a solvable problem. And if not, then you still have your Valve.. Andre, I haven't tried your full suggestion yet, but I removed all of the OAM SSO stuff out of my Apache httpd.conf, just to see what happens, but even after that, still am not getting logged into Tomcat, so it may be as you suggest, that mod_jk tries to get the userid from somewhere deep inside of Apache. So, I will try adding what you suggested, to get authenticated with just the Apache, and then see what happens, and will post back. If that works, we can go from there. Thanks for following up with this! Jim - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support no password authentication?
oh...@cox.net wrote:
André Warnier a...@ice-sa.com wrote:
oh...@cox.net wrote:
André Warnier a...@ice-sa.com wrote:
oh...@cox.net wrote:
.. re-synchronising..
I've made some progress. I have a VirtualHost, so I had to add a
JkMountCopy 'on' inside the VirtualHost, and now, it's at least
proxying through to the Tomcat using mod_jk!!
BUT, it's still not logging me into the Tomcat :(...
I don't want to post the entire jk.log, so can someone point me to what
to look for in there, maybe?
Ok, so let's now continue on the mod_jk track, since you've got that
part running.
What you are looking for, is an AJP request attribute named
remote_user (lowercase),
in the packets which mod_jk sends to Tomcat.
I don't know if that would be in the log, nor if there is any way to
coerce mod_jk into
putting it in the log.
But since your Tomcat is not authenticating, chances are that it isn't
there.
So let's try to cheat, and force it to be there.
In your Apache configuration, add this line :
JkEnvVar remote_user blablabla
and let's see what happens.
(and after that, we'll try mod_rewrite or a combination)
Andre,
I had already tried including a JkEnvVar as you suggested in my
httpd.conf, in order to try to hard-code getting SOMETHING to show up,
but no joy :(...
I've also tried a bunch of other variants:
JkEnvVar REMOTE_USER
also:
JkEnvVar remote_user foobar
also:
JkEnvVar AJP_REMOTE_USER foobar
Nothing works :(...
This is really getting discouraging :(. It almost seems to me like that
'tomcatAuthentication' functionality doesn't even exist at all.
I've searched the jk.log for multiple things, attr, remo, etc., and
find nothing relevant/significant at all in there...
Do not get discouraged. I can guarantee that the
tomcatAuthentication=false works, when
the Apache front-end really does authenticate the user. I use this all the
time.
(Just not with the same SSO mechanism as you).
I also know that JkEnvVar does work in general for setting request
attributes at the
Apache level, and have them passed to Tomcat by mod_jk, because I also us
that regularly.
(And there exists a similar functionality in mod_proxy_ajp).
What may not work in the trials above, is that specifically this
remote_user request
attribute may be overwritten by mod_jk or mod_proxy_ajp, even when you have
set it
explicitly in Apache.
After all, this feature is designed to do one thing : examine the request
record of
Apache for an authenticated user-id, and if one is set, pass it along to
Tomcat over the
AJP channel. If mod_jk/mod_proxy_ajp do not find such a user-id in the
request record,
they may just /clear/ the remote_user attribute, thus voiding our attempts
at cheating.
To verify this is relatively simple.
Create the following Location section in Apache :
Location /sampleajp
AuthType Basic
AuthName toTomcat
AuthUserFile /some-path/passwords
Require user testuser
SetHandler jakarta-servlet
SetEnv JK_WORKER_NAME tomcatA (- or whatever name your worker has)
Location
Note: the SetHandler and SetEnv lines above, in that Location, are
equivalent to saying :
JkMount /sampleajp/* tomcatA
Then follow the instructions here to create the password file and the user
testuser in it :
http://httpd.apache.org/docs/2.2/howto/auth.html
section : Getting it working
If you try to access such a URL /sampleajp/*, the browser will popup a
bssic auth dialog
and force you to login.
This will result in the request being duly authenticated for Apache, which
/will/ result
in the Apache user-id being passed to Tomcat.
Then, once you have verified (in Tomcat) that it is so, have another look
at the mod_jk
logfile, to see if then you spot the attribute being passed.
(You will know that it is passed, but it may still not show up the logs).
If all of that works, then we know that in order for your scheme to work,
you must somehow
force the user-id obtained by your SSO system, to be also set in the Apache
request
record. Which should be a solvable problem.
And if not, then you still have your Valve..
Andre,
I haven't tried your full suggestion yet, but I removed all of the OAM SSO
stuff out of my Apache httpd.conf, just to see what happens, but even after
that, still am not getting logged into Tomcat, so it may be as you suggest,
that mod_jk tries to get the userid from somewhere deep inside of Apache.
So, I will try adding what you suggested, to get authenticated with just the
Apache, and then see what happens, and will post back. If that works, we can
go from there.
Thanks for following up with this!
Jim
Hi Andre,
Re: Do any of the Tomcat LDAP-type realms support no password authentication?
P.S. I forgot to mention: As you know, I'd been using a sniffer, to see the data on the Apache-to-Tomcat connection. I have a sniff from earlier, where I was using ProxyPass ajp://, and, comparing that sniff vs. a sniff that I have from when I tested with your suggested Location, in the latter sniff, I can see the userID (testuser), whereas in the former, that same area in the hex dump is basically just null-terminated strings. So, it appears like, when the OAM stuff and the ajp: stuff is in the Apache .conf, as you were guessing, the userID isn't making it into the Apache-to-Tomcat/AJP connection at all. Jim oh...@cox.net wrote: oh...@cox.net wrote: André Warnier a...@ice-sa.com wrote: oh...@cox.net wrote: André Warnier a...@ice-sa.com wrote: oh...@cox.net wrote: .. re-synchronising.. I've made some progress. I have a VirtualHost, so I had to add a JkMountCopy 'on' inside the VirtualHost, and now, it's at least proxying through to the Tomcat using mod_jk!! BUT, it's still not logging me into the Tomcat :(... I don't want to post the entire jk.log, so can someone point me to what to look for in there, maybe? Ok, so let's now continue on the mod_jk track, since you've got that part running. What you are looking for, is an AJP request attribute named remote_user (lowercase), in the packets which mod_jk sends to Tomcat. I don't know if that would be in the log, nor if there is any way to coerce mod_jk into putting it in the log. But since your Tomcat is not authenticating, chances are that it isn't there. So let's try to cheat, and force it to be there. In your Apache configuration, add this line : JkEnvVar remote_user blablabla and let's see what happens. (and after that, we'll try mod_rewrite or a combination) Andre, I had already tried including a JkEnvVar as you suggested in my httpd.conf, in order to try to hard-code getting SOMETHING to show up, but no joy :(... I've also tried a bunch of other variants: JkEnvVar REMOTE_USER also: JkEnvVar remote_user foobar also: JkEnvVar AJP_REMOTE_USER foobar Nothing works :(... This is really getting discouraging :(. It almost seems to me like that 'tomcatAuthentication' functionality doesn't even exist at all. I've searched the jk.log for multiple things, attr, remo, etc., and find nothing relevant/significant at all in there... Do not get discouraged. I can guarantee that the tomcatAuthentication=false works, when the Apache front-end really does authenticate the user. I use this all the time. (Just not with the same SSO mechanism as you). I also know that JkEnvVar does work in general for setting request attributes at the Apache level, and have them passed to Tomcat by mod_jk, because I also us that regularly. (And there exists a similar functionality in mod_proxy_ajp). What may not work in the trials above, is that specifically this remote_user request attribute may be overwritten by mod_jk or mod_proxy_ajp, even when you have set it explicitly in Apache. After all, this feature is designed to do one thing : examine the request record of Apache for an authenticated user-id, and if one is set, pass it along to Tomcat over the AJP channel. If mod_jk/mod_proxy_ajp do not find such a user-id in the request record, they may just /clear/ the remote_user attribute, thus voiding our attempts at cheating. To verify this is relatively simple. Create the following Location section in Apache : Location /sampleajp AuthType Basic AuthName toTomcat AuthUserFile /some-path/passwords Require user testuser SetHandler jakarta-servlet SetEnv JK_WORKER_NAME tomcatA (- or whatever name your worker has) Location Note: the SetHandler and SetEnv lines above, in that Location, are equivalent to saying : JkMount /sampleajp/* tomcatA Then follow the instructions here to create the password file and the user testuser in it : http://httpd.apache.org/docs/2.2/howto/auth.html section : Getting it working If you try to access such a URL /sampleajp/*, the browser will popup a bssic auth dialog and force you to login. This will result in the request being duly authenticated for Apache, which /will/ result in the Apache user-id being passed to Tomcat. Then, once you have verified (in Tomcat) that it is so, have another look at the mod_jk logfile, to see if then you spot the attribute being passed. (You will know that it is passed, but it may still not show up the logs). If all of that works, then we know that in order for
Re: Do any of the Tomcat LDAP-type realms support no password authentication?
oh...@cox.net wrote: P.S. I forgot to mention: As you know, I'd been using a sniffer, to see the data on the Apache-to-Tomcat connection. I have a sniff from earlier, where I was using ProxyPass ajp://, and, comparing that sniff vs. a sniff that I have from when I tested with your suggested Location, in the latter sniff, I can see the userID (testuser), whereas in the former, that same area in the hex dump is basically just null-terminated strings. So, it appears like, when the OAM stuff and the ajp: stuff is in the Apache .conf, as you were guessing, the userID isn't making it into the Apache-to-Tomcat/AJP connection at all. Jim Hi, Sorry for the top-post :(... Here're the sniffs from the tests that I did: a) Working (OAM disabled, Location per Andre): 12 34 02 AB 02 02 00 08 48 54 54 50 2F 31 2E 31 .4.« HTTP/1.1 0010 00 00 1F 2F 73 61 6D 70 6C 65 73 61 6A 70 2F 73 .../samp lesajp/s 0020 73 6F 41 4D 54 6F 6D 63 61 74 54 65 73 74 2E 6A soAMTomc atTest.j 0030 73 70 00 00 0B 31 39 32 2E 31 36 38 2E 30 2E 37 sp...192 .168.0.7 0040 00 FF FF 00 14 61 70 61 63 68 65 31 2E 77 68 61 .ÿÿ..apa che1.wha 0050 74 65 76 65 72 2E 63 6F 6D 00 01 BB 01 00 09 A0 tever.co m..»... 0060 0B 00 14 61 70 61 63 68 65 31 2E 77 68 61 74 65 ...apach e1.whate 0070 76 65 72 2E 63 6F 6D 00 A0 0E 00 3F 4D 6F 7A 69 ver.com. ..?Mozi 0080 6C 6C 61 2F 35 2E 30 20 28 57 69 6E 64 6F 77 73 lla/5.0 (Windows 0090 20 4E 54 20 36 2E 31 3B 20 72 76 3A 38 2E 30 29NT 6.1; rv:8.0) 00A0 20 47 65 63 6B 6F 2F 32 30 31 30 30 31 30 31 20Gecko/2 0100101 00B0 46 69 72 65 66 6F 78 2F 38 2E 30 00 A0 01 00 3F Firefox/ 8.0. ..? 00C0 74 65 78 74 2F 68 74 6D 6C 2C 61 70 70 6C 69 63 text/htm l,applic 00D0 61 74 69 6F 6E 2F 78 68 74 6D 6C 2B 78 6D 6C 2C ation/xh tml+xml, 00E0 61 70 70 6C 69 63 61 74 69 6F 6E 2F 78 6D 6C 3B applicat ion/xml; 00F0 71 3D 30 2E 39 2C 2A 2F 2A 3B 71 3D 30 2E 38 00 q=0.9,*/ *;q=0.8. 0100 00 0F 41 63 63 65 70 74 2D 4C 61 6E 67 75 61 67 ..Accept -Languag 0110 65 00 00 0E 65 6E 2D 75 73 2C 65 6E 3B 71 3D 30 e...en-u s,en;q=0 0120 2E 35 00 00 0F 41 63 63 65 70 74 2D 45 6E 63 6F .5...Acc ept-Enco 0130 64 69 6E 67 00 00 0D 67 7A 69 70 2C 20 64 65 66 ding...g zip, def 0140 6C 61 74 65 00 00 0E 41 63 63 65 70 74 2D 43 68 late...A ccept-Ch 0150 61 72 73 65 74 00 00 1E 49 53 4F 2D 38 38 35 39 arset... ISO-8859 0160 2D 31 2C 75 74 66 2D 38 3B 71 3D 30 2E 37 2C 2A -1,utf-8 ;q=0.7,* 0170 3B 71 3D 30 2E 37 00 A0 06 00 0A 6B 65 65 70 2D ;q=0.7. ...keep- 0180 61 6C 69 76 65 00 A0 05 00 1A 42 61 73 69 63 20 alive. . ..Basic 0190 64 47 56 7A 64 48 56 7A 5A 58 49 36 59 6D 56 7A dGVzdHVz ZXI6YmVz 01A0 64 44 46 69 00 A0 08 00 01 30 00 03 00 08 74 65 dDFi. .. .0te 01B0 73 74 75 73 65 72 00 04 00 05 42 61 73 69 63 00 stuser.. ..Basic. 01C0 08 00 12 44 48 45 2D 52 53 41 2D 41 45 53 32 35 ...DHE-R SA-AES25 01D0 36 2D 53 48 41 00 09 00 40 35 41 38 35 44 36 33 6-SHA... @5A85D63 01E0 44 46 33 32 42 35 42 38 36 34 44 42 32 37 31 34 DF32B5B8 64DB2714 01F0 38 39 37 31 31 31 41 42 34 44 35 30 33 32 30 45 897111AB 4D50320E 0200 39 41 33 38 41 42 46 36 46 38 37 44 30 46 42 43 9A38ABF6 F87D0FBC 0210 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): 12 34 09 28 02 02 00 08 48 54 54 50 2F 31 2E 31 .4.( HTTP/1.1 0010 00 00 1F 2F 73 61 6D 70 6C 65 73 61 6A 70 2F 73 .../samp lesajp/s 0020 73 6F 41 4D 54 6F 6D 63 61 74 54 65 73 74 2E 6A soAMTomc atTest.j 0030 73 70 00 00 0B 31 39 32 2E 31 36 38 2E 30 2E 37 sp...192 .168.0.7 0040 00 FF FF 00 14 61 70 61 63 68 65 31 2E 77 68 61 .ÿÿ..apa che1.wha 0050 74 65 76 65 72 2E 63 6F 6D 00 01 BB 01 00 0E A0 tever.co m..»... 0060 0B 00 14 61 70 61 63 68 65 31 2E 77 68 61 74 65 ...apach e1.whate 0070 76 65 72 2E 63 6F 6D 00 A0 0E 00 3F 4D 6F 7A 69 ver.com. ..?Mozi 0080 6C 6C 61 2F 35 2E 30 20 28 57 69 6E 64 6F 77 73 lla/5.0 (Windows 0090 20 4E 54 20 36 2E 31 3B 20 72 76 3A 38 2E 30 29NT 6.1; rv:8.0) 00A0 20 47 65 63 6B 6F 2F 32 30 31 30 30 31 30 31 20Gecko/2 0100101 00B0 46 69 72 65 66 6F 78 2F 38 2E 30 00 A0 01 00 3F Firefox/ 8.0. ..? 00C0 74 65 78 74 2F 68 74 6D 6C 2C 61 70 70 6C 69 63 text/htm l,applic 00D0 61 74 69 6F 6E 2F 78 68 74 6D 6C 2B 78 6D 6C 2C ation/xh tml+xml, 00E0 61 70 70 6C 69 63 61 74 69 6F 6E 2F 78 6D 6C 3B applicat ion/xml; 00F0 71 3D 30 2E 39 2C 2A 2F 2A 3B 71 3D 30 2E 38 00 q=0.9,*/ *;q=0.8. 0100 A0 04 00 0E 65 6E 2D 75 73 2C 65 6E 3B 71 3D 30 ...en-u s,en;q=0 0110 2E 35 00 A0 03 00 0D 67 7A 69 70 2C 20 64 65
Re: Do any of the Tomcat LDAP-type realms support no password authentication?
André Warnier a...@ice-sa.com wrote: oh...@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
Re: Do any of the Tomcat LDAP-type realms support no password authentication?
André Warnier a...@ice-sa.com wrote: oh...@cox.net wrote: André Warnier a...@ice-sa.com wrote: oh...@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
Re: Do any of the Tomcat LDAP-type realms support no password authentication?
Mark Thomas ma...@apache.org wrote: On 01/12/2011 18:17, oh...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Do any of the Tomcat LDAP-type realms support no password authentication?
oh...@cox.net wrote:
André Warnier a...@ice-sa.com wrote:
oh...@cox.net wrote:
André Warnier a...@ice-sa.com wrote:
oh...@cox.net wrote:
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
Re: Do any of the Tomcat LDAP-type realms support no password authentication?
oh...@cox.net wrote: oh...@cox.net wrote: André Warnier a...@ice-sa.com wrote: oh...@cox.net wrote: André Warnier a...@ice-sa.com wrote: oh...@cox.net wrote: 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
RE: Do any of the Tomcat LDAP-type realms support no password authentication?
Caldarale wrote: From: oh...@cox.net [mailto:oh...@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=2 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Getting 403 (Access Denied) when running Tomcat under Eclipse
Hi, I have a web application that works when run directly under Tomcat. This web app has the following in web.xml: security-constraint web-resource-collection web-resource-nametestweb/web-resource-name description accessible by authenticated users of the tomcat role/description url-pattern/*/url-pattern http-methodGET/http-method http-methodPOST/http-method http-methodPUT/http-method http-methodDELETE/http-method /web-resource-collection auth-constraint descriptionThese roles are allowed access/description role-nameluceneuser/role-name /auth-constraint /security-constraint login-config auth-methodBASIC/auth-method realm-nameSearch/realm-name /login-config security-role descriptionOnly 'tomcat' role is allowed to access this web application/description role-nametestuser/role-name /security-role However, when I run the webapp under Eclipse (i.e., do a Run on server), and attempt to login as the same user, with the same password, I get a 403 (Access denied) error. If I remove the constraint, it then works under Tomcat and Eclipse I've checked the Tomcat logs, and I don't see any info there. Can anyone tell me why this is happening?? Thanks, Jim P.S. Tomcat version is 5.5.2.8, under Windows. Eclipse is latest Galileo. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Getting 403 (Access Denied) when running Tomcat under Eclipse
Hi, AHH!! I was only looking through the Eclipse GUI settings, and hadn't noticed that under Servers--Tomcat v5.5 in the Eclipse Project Explorer, there were catalina.policy, etc. files, including tomcat-users.xml :(... So, I added my role and user definitions to that tomcat-users.xml, and it worked!! I'm still a little puzzled though. In Eclipse Servers, there was also a web.xml, but I *did NOT* have to modify that web.xml, and it's picking up the web.xml from my webapp's WEB-INF\web.xml. Is that because the web.xml under Eclipse Servers is server-scoped, and so the web.xml in my webapp is overriding the Eclipse Servers web.xml? Thanks! Jim Ziggy zigg...@gmail.com wrote: Doesnt eclipse use use a $CATALINA_BASE to run tomcat? I think the tomcat instance on eclipse is not the same as the one on $CATALINA_HOME. Look at the server project files under eclipse they will have their own configuration files. On Mon, Jan 18, 2010 at 10:43 PM, oh...@cox.net wrote: Hi, I have a web application that works when run directly under Tomcat. This web app has the following in web.xml: security-constraint web-resource-collection web-resource-nametestweb/web-resource-name description accessible by authenticated users of the tomcat role/description url-pattern/*/url-pattern http-methodGET/http-method http-methodPOST/http-method http-methodPUT/http-method http-methodDELETE/http-method /web-resource-collection auth-constraint descriptionThese roles are allowed access/description role-nameluceneuser/role-name /auth-constraint /security-constraint login-config auth-methodBASIC/auth-method realm-nameSearch/realm-name /login-config security-role descriptionOnly 'tomcat' role is allowed to access this web application/description role-nametestuser/role-name /security-role However, when I run the webapp under Eclipse (i.e., do a Run on server), and attempt to login as the same user, with the same password, I get a 403 (Access denied) error. If I remove the constraint, it then works under Tomcat and Eclipse I've checked the Tomcat logs, and I don't see any info there. Can anyone tell me why this is happening?? Thanks, Jim P.S. Tomcat version is 5.5.2.8, under Windows. Eclipse is latest Galileo. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
