Re: user and certificate info is not passed to tomcat
There is no Tomcat, mod_jk nor httpd bug here. The root cause of this thread is a configuration error. >From the httpd docs for Location: The URL may use wildcards. In a wild-card string, ? matches any single character, and * matches any sequences of characters. Neither wildcard character matches a / in the URL-path. Note - in particular - the final sentence. >From the JkMount docs: Inside Location, one omits the first argument (path), which gets inherited verbatim from the Location argument. Whereas matches any URI beginning with "/myapp", any JkMount nested in such a Location block will only match for requests with exact URI /myapp. Therefore nesting JkMount in Location is typically not the right thing to do. Again, note - in particular - the final sentence. The original configuration was: JkMount worker1 SSLVerifyClient require SSLOptions +StdEnvVars SSLOptions +ExportCertData ... As per the documentation, configuration in the Location block and the JkMount DO NOT apply to the same set of URLs as the matching rules are different. Hence the behaviour that is observed. For example "/servlet/foo" will match the JkMount directive but NOT the location block. It isn't clear what the intended configuration is but I suspect it is something along these lines: SSLVerifyClient require SSLOptions +StdEnvVars SSLOptions +ExportCertData ... JkMount /servlet worker1 JkMount /servlet/* worker1 Mark On 08/10/2019 02:09, André Warnier (tomcat) wrote: > On 08.10.2019 00:50, Magosányi Árpád wrote: >> On 10/7/19 11:29 PM, André Warnier (tomcat) wrote: >>> >>> DirectoryIndex off >>> RewriteEngine Off >>> AuthType openid-connect >>> AllowOverride None >>> AuthzDBDQuery "a correct database query" >>> Require dbd-group allrepo >>> LogLevel debug >>> >> >> Nice. It have solved the problem, thank you very much. By adding the ssl >> related directives here I could pass the ssl info as well. So basically >> we have put the JkMount in a Location, and the other directives in >> another similar directive, as a kind of workaround? > > Think of it as follows : > When httpd gets a request, > - step 1 : it first looks only at the request URL, and it applies any > directives that it finds in or sections which > match that URL. > - step 2 : then it tries to match the URL, with the filesystem on disk, > and IF it finds a file that corresponds to that URL > - step 3 : then it applies any or that > apply to that file > - step 4 : httpd serves the file back to the browser > > If you have JkMount directives that match the URL, then step 2, 3 and 4 > above never happen, because the request will be passed to tomcat anyway, > so it will never map to a file on the httpd filesystem. And if you have > JkUnmount directives, that also match the URL, then they partially > negate the matching JkMount, and they /force/ step 2, 3 and 4. > > The combination of JkMount/JkUnmount directives, with the httpd > and sections, is sometimes a bit > unclear, specially when they overlap. > > There is another syntax applicable to the proxying via mod_jk, which I > prefer because I find that it makes the httpd URL mapping clearer, in a > httpd configuration logic sense. > You can find it here : > http://tomcat.apache.org/connectors-doc/reference/apache.html > section : Using SetHandler and Environment Variables > > Using that form, you do NOT use any "JkMount/JkUnmount" directives, you > use only blocks, like : > > > SetHandler jakarta-servlet > SetEnv JK_WORKER_NAME worker1 > DirectoryIndex off > RewriteEngine Off > AuthType openid-connect > AllowOverride None > AuthzDBDQuery "a correct database query" > Require dbd-group allrepo > LogLevel debug > > > The combination of the , SetHandler and > SetEnv, does the same as a separate "JkMount /servlet* worker1" and (in > my view) it makes it clearer in the Apache httpd configuration file, to > know which URLs get proxied to tomcat and which do not get proxied. > Look at the example "" to see how you can have some > static documents served by the httpd front-end directly (= not proxied > to tomcat), and the real calls to tomcat servlets being proxied to tomcat. > > > >> >> >> >> - >> 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 > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: user and certificate info is not passed to tomcat
On 08.10.2019 00:50, Magosányi Árpád wrote: On 10/7/19 11:29 PM, André Warnier (tomcat) wrote: DirectoryIndex off RewriteEngine Off AuthType openid-connect AllowOverride None AuthzDBDQuery "a correct database query" Require dbd-group allrepo LogLevel debug Nice. It have solved the problem, thank you very much. By adding the ssl related directives here I could pass the ssl info as well. So basically we have put the JkMount in a Location, and the other directives in another similar directive, as a kind of workaround? Think of it as follows : When httpd gets a request, - step 1 : it first looks only at the request URL, and it applies any directives that it finds in or sections which match that URL. - step 2 : then it tries to match the URL, with the filesystem on disk, and IF it finds a file that corresponds to that URL - step 3 : then it applies any or that apply to that file - step 4 : httpd serves the file back to the browser If you have JkMount directives that match the URL, then step 2, 3 and 4 above never happen, because the request will be passed to tomcat anyway, so it will never map to a file on the httpd filesystem. And if you have JkUnmount directives, that also match the URL, then they partially negate the matching JkMount, and they /force/ step 2, 3 and 4. The combination of JkMount/JkUnmount directives, with the httpd and sections, is sometimes a bit unclear, specially when they overlap. There is another syntax applicable to the proxying via mod_jk, which I prefer because I find that it makes the httpd URL mapping clearer, in a httpd configuration logic sense. You can find it here : http://tomcat.apache.org/connectors-doc/reference/apache.html section : Using SetHandler and Environment Variables Using that form, you do NOT use any "JkMount/JkUnmount" directives, you use only blocks, like : SetHandler jakarta-servlet SetEnv JK_WORKER_NAME worker1 DirectoryIndex off RewriteEngine Off AuthType openid-connect AllowOverride None AuthzDBDQuery "a correct database query" Require dbd-group allrepo LogLevel debug The combination of the , SetHandler and SetEnv, does the same as a separate "JkMount /servlet* worker1" and (in my view) it makes it clearer in the Apache httpd configuration file, to know which URLs get proxied to tomcat and which do not get proxied. Look at the example "" to see how you can have some static documents served by the httpd front-end directly (= not proxied to tomcat), and the real calls to tomcat servlets being proxied to tomcat. - 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: user and certificate info is not passed to tomcat
On 10/7/19 11:29 PM, André Warnier (tomcat) wrote: > > DirectoryIndex off > RewriteEngine Off > AuthType openid-connect > AllowOverride None > AuthzDBDQuery "a correct database query" > Require dbd-group allrepo > LogLevel debug > Nice. It have solved the problem, thank you very much. By adding the ssl related directives here I could pass the ssl info as well. So basically we have put the JkMount in a Location, and the other directives in another similar directive, as a kind of workaround? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: user and certificate info is not passed to tomcat
Adding to my own previous post : A posteriori, I saw a question here : https://stackoverflow.com/questions/58240796/pass-username-and-client-certificate-from-apache-to-tomcat-using-mod-jk that may be related to your question on this list. Examining the above, you problem may be in the httpd configuration : As I interpret it, the section that you mention, will not be taken into account for the URLs that you are proxying to tomcat. That is because sections only apply if the URL ultimately maps to a local file for httpd. In this case, it does not, because you are proxying this request to tomcat. For such URLs, you should use a or in httpd, not a . For example, *add* this to your httpd configuration : DirectoryIndex off RewriteEngine Off AuthType openid-connect AllowOverride None AuthzDBDQuery "a correct database query" Require dbd-group allrepo LogLevel debug Note: the above is very rough, and you may need to tune the regex a bit better. On 08.10.2019 00:11, André Warnier (tomcat) wrote: On 07.10.2019 23:24, Magosányi Árpád wrote: On 10/7/19 8:20 PM, André Warnier (tomcat) wrote: Forgot the atribute 'tomcatAuthentication="false"' in the Connector ? Yes, I did, however adding it back did not improve the situation. Ok. I just mentioned that, because it is one piece of the puzzle, and you might have forgotten it. What this piece really does is : - IF the front-end Apache httpd authenticates the HTTP request which it later passes on to tomcat - IF the protocol used between Apache httpd and tomcat is AJP - IF the AJP Connector in tomcat has the attribute set as above - THEN tomcat will retrieve the user-id of the httpd-authenticated user, and save it internally as the tomcat-authenticated user-id for this request So now you have the two last IF's answered positively. What about the first IF ? Info : in the default format of the Apache httpd access log, it will show the authenticated user (if any) for each request, for example like this : 127.0.0.1 - THEUSER [07/Oct/2019:21:18:20 +0200] "GET /starwebtt-internal/esearch... (where "THEUSER" is the httpd-authenticated user) while if the request is not authenticated by httpd, it will show a "-" instead of the user-id, like this : 127.0.0.1 - - [07/Oct/2019:21:18:20 +0200] "GET /starwebtt-internal/esearch... (and, of course, if httpd has not authenticated the request which it later passes on to tomcat via AJP, then it cannot pass a user-id to tomcat, and thus tomcat cannot retrieve this user-id, and thus the request, at the tomcat level, is not authenticated). Next comes the question of how the tomcat application retrieves this user-id, from tomcat itself. I suppose that this would be a question for the developers of the "com.kodekonveyor.realm.KKAuthorizationFilter" filter mentioned in your configuration below. (if the KKAuthorizationFilter does not use request.getRemoteuser(), but uses some other method, then you are out of luck for this front-end/back-end combination)(or you may need to do something additional at the front-end httpd level). My server.xml now: and my web.xml until mime mappings: http://xmlns.jcp.org/xml/ns/javaee; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd; version="4.0"> default org.apache.catalina.servlets.DefaultServlet debug 0 listings false 1 jsp org.apache.jasper.servlet.JspServlet fork false xpoweredBy false 3 default / jsp *.jsp *.jspx KKAuthorizationFilter com.kodekonveyor.realm.KKAuthorizationFilter KKAuthorizationFilter /* REQUEST 30 - 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: user and certificate info is not passed to tomcat
On 07.10.2019 23:24, Magosányi Árpád wrote: On 10/7/19 8:20 PM, André Warnier (tomcat) wrote: Forgot the atribute 'tomcatAuthentication="false"' in the Connector ? Yes, I did, however adding it back did not improve the situation. Ok. I just mentioned that, because it is one piece of the puzzle, and you might have forgotten it. What this piece really does is : - IF the front-end Apache httpd authenticates the HTTP request which it later passes on to tomcat - IF the protocol used between Apache httpd and tomcat is AJP - IF the AJP Connector in tomcat has the attribute set as above - THEN tomcat will retrieve the user-id of the httpd-authenticated user, and save it internally as the tomcat-authenticated user-id for this request So now you have the two last IF's answered positively. What about the first IF ? Info : in the default format of the Apache httpd access log, it will show the authenticated user (if any) for each request, for example like this : 127.0.0.1 - THEUSER [07/Oct/2019:21:18:20 +0200] "GET /starwebtt-internal/esearch... (where "THEUSER" is the httpd-authenticated user) while if the request is not authenticated by httpd, it will show a "-" instead of the user-id, like this : 127.0.0.1 - - [07/Oct/2019:21:18:20 +0200] "GET /starwebtt-internal/esearch... (and, of course, if httpd has not authenticated the request which it later passes on to tomcat via AJP, then it cannot pass a user-id to tomcat, and thus tomcat cannot retrieve this user-id, and thus the request, at the tomcat level, is not authenticated). Next comes the question of how the tomcat application retrieves this user-id, from tomcat itself. I suppose that this would be a question for the developers of the "com.kodekonveyor.realm.KKAuthorizationFilter" filter mentioned in your configuration below. (if the KKAuthorizationFilter does not use request.getRemoteuser(), but uses some other method, then you are out of luck for this front-end/back-end combination)(or you may need to do something additional at the front-end httpd level). My server.xml now: and my web.xml until mime mappings: http://xmlns.jcp.org/xml/ns/javaee; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd; version="4.0"> default org.apache.catalina.servlets.DefaultServlet debug 0 listings false 1 jsp org.apache.jasper.servlet.JspServlet fork false xpoweredBy false 3 default / jsp *.jsp *.jspx KKAuthorizationFilter com.kodekonveyor.realm.KKAuthorizationFilter KKAuthorizationFilter /* REQUEST 30 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: user and certificate info is not passed to tomcat
On 10/7/19 8:20 PM, André Warnier (tomcat) wrote: > > Forgot the atribute 'tomcatAuthentication="false"' in the Connector ? > Yes, I did, however adding it back did not improve the situation. My server.xml now: and my web.xml until mime mappings: http://xmlns.jcp.org/xml/ns/javaee; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd; version="4.0"> default org.apache.catalina.servlets.DefaultServlet debug 0 listings false 1 jsp org.apache.jasper.servlet.JspServlet fork false xpoweredBy false 3 default / jsp *.jsp *.jspx KKAuthorizationFilter com.kodekonveyor.realm.KKAuthorizationFilter KKAuthorizationFilter /* REQUEST 30 > > > - > 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: user and certificate info is not passed to tomcat
On 07.10.2019 17:36, Magosányi Árpád wrote:
Magosányi,
How are you getting the attributes from the request?
This is the filter code:
String user = httpRequest.getRemoteUser(); Object cert =
httpRequest.getAttribute("javax.servlet.request.X509Certificate");
this.context.log("user:"+user);
This won't show any username unless the user has logged-in using HTTP
Basic/Digest authentication. Are you using those?
I am using openid right now in the apache side, but also tested with
basic auth to make sure that it is not an interaction with mod_openidc.
The user information does not get passed along either in the remoteUser
attribute or anywhere, in either of those cases, in spite that the
documentation states that the authenticated user name should be
retrievable using httpRequest.getRemoteUser(), and the CGI clearly shows
that we indeed have a REMOTE_USER in the apache side.
To get the certificate chain, I think you also need this in your httpd
configuration:
JkOptions +ForwardSSLCertChain
I have added this now, though as I understand this is only needed if I
want to get the full chain.
Unfortunately this did not improve the situation in any way.
Forgot the atribute 'tomcatAuthentication="false"' in the Connector ?
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: user and certificate info is not passed to tomcat
> Magosányi,
>
> >> How are you getting the attributes from the request?
>
> > This is the filter code:
>
>
> > String user = httpRequest.getRemoteUser(); Object cert =
> > httpRequest.getAttribute("javax.servlet.request.X509Certificate");
> > this.context.log("user:"+user);
>
> This won't show any username unless the user has logged-in using HTTP
> Basic/Digest authentication. Are you using those?
I am using openid right now in the apache side, but also tested with
basic auth to make sure that it is not an interaction with mod_openidc.
The user information does not get passed along either in the remoteUser
attribute or anywhere, in either of those cases, in spite that the
documentation states that the authenticated user name should be
retrievable using httpRequest.getRemoteUser(), and the CGI clearly shows
that we indeed have a REMOTE_USER in the apache side.
>
> To get the certificate chain, I think you also need this in your httpd
> configuration:
>
> JkOptions +ForwardSSLCertChain
>
I have added this now, though as I understand this is only needed if I
want to get the full chain.
Unfortunately this did not improve the situation in any way.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: user and certificate info is not passed to tomcat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Magosányi,
On 10/7/19 11:16, Magosányi Árpád wrote:
>> Magosányi,
>>
>> On 10/7/19 10:37, Magosányi Árpád wrote:
>>> I intend to use the user and certificate info in a Filter.
>>
>>> I think I have configured everything to do that, but the
>>> information does not get passed along. Based on various
>>> documentations and howtos, SSLVerifyClient require, SSLOptions
>>> +StdEnvVars and SSLOptions +ExportCertData and JkExtractSSL On
>>> should be enough to pass certificate data, and Require
>>> valid-user should be enough to pass the authenticated
>>> username.
>>
>>> I see the following debug output (also contains the various
>>> info logged by the filter), which clearly lacks the information
>>> needed.
>> How are you getting the attributes from the request?
>
> This is the filter code:
>
>
> String user = httpRequest.getRemoteUser(); Object cert =
> httpRequest.getAttribute("javax.servlet.request.X509Certificate");
> this.context.log("user:"+user);
This won't show any username unless the user has logged-in using HTTP
Basic/Digest authentication. Are you using those?
To get the certificate chain, I think you also need this in your httpd
configuration:
JkOptions +ForwardSSLCertChain
>> Is the CGI being executed by Tomcat or is it being executed by
>> httpd?
>
> Executed by Apache httpd.
Okay.
- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2bWSkACgkQHPApP6U8
pFgkdQ/+O3c3y8QZaBSyQk0do9nCyVl1os/GBGnBTmPYio7C3L/DHQ78LaERjJwl
DHvElopUxA5T7Jcbrg8mAN41lv3oLkoZqBv1htXxL/6JliRGG5DkH8ZCXbIBIH36
a2kVIJ2B4fbPryZ0kjZ+dmiHfJUYRr41NNZ0Ejrs93VEsV4+A8JZna74z4Wh0nRN
AwctTF/PTZuPrgEAVx7s9zxGFAasHWv5h3UIHXUmHKCmFQxY8bP8GUWXyAZ0pdtg
PiDJf3xAZeG2joB7n2M44VohGyFhG0i+x4fKYn212n8zq7bs++TbWiknrUAUQqMS
LFc6qXw85CxeKoJva4Q1F228HmtXJXLYw/6esjQHWdKqChU2IPUutrTFwxeb2hlf
ZBWHby77FyDQtErakxyVlv9Qi4bwmPeH4bR86ovarxhFYQ7bEcEyEAxdsY6HPnpj
we/pvHXWhb1Rs6MAthZyXzyhmGHu4nZyHbedQnsgX9hBAXerSqs0u8AQaAkmQLtd
dYDNQZ2jL5scN8jB951BMTlgskpxuWGyxG6xbBPM6/YdGTN9Qfgem7TRPzhDImO8
C53AheJwAK/RQGAoNaXIHK66p1bTR33IH3ycvmzsDhBxdtQcCRSpABL6Xm8LGxzS
PU2zKywcD5dqKu9Btd1+PECVy1MIPUkvl++Qv9TwTdqxwGoas3s=
=PCeu
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: user and certificate info is not passed to tomcat
> Magosányi,
>
> On 10/7/19 10:37, Magosányi Árpád wrote:
> > I intend to use the user and certificate info in a Filter.
>
> > I think I have configured everything to do that, but the
> > information does not get passed along. Based on various
> > documentations and howtos, SSLVerifyClient require, SSLOptions
> > +StdEnvVars and SSLOptions +ExportCertData and JkExtractSSL On
> > should be enough to pass certificate data, and Require valid-user
> > should be enough to pass the authenticated username.
>
> > I see the following debug output (also contains the various info
> > logged by the filter), which clearly lacks the information needed.
> How are you getting the attributes from the request?
This is the filter code:
package com.kodekonveyor.realm;
import java.io.IOException;
import java.util.Collections;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletContext;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpSession;
public class KKAuthorizationFilter implements Filter {
private ServletContext context;
@Override
public void init(FilterConfig fConfig) throws ServletException {
this.context = fConfig.getServletContext();
this.context.log("KKAuthorizationFilter initialized");
}
@Override
public void doFilter(ServletRequest request, ServletResponse
response, FilterChain chain)
throws IOException, ServletException {
HttpServletRequest httpRequest = (HttpServletRequest) request;
String user = httpRequest.getRemoteUser();
String authType = httpRequest.getAuthType();
for ( String attributeName:
Collections.list(httpRequest.getAttributeNames())) {
this.context.log("attr
"+attributeName+"="+httpRequest.getAttribute(attributeName));
}
for ( String name:
Collections.list(httpRequest.getParameterNames())) {
this.context.log("param
"+name+"="+httpRequest.getParameterValues(name));
}
for ( String headerName:
Collections.list(httpRequest.getHeaderNames())) {
for (String value:
Collections.list(httpRequest.getHeaders(headerName)))
this.context.log("header "+headerName+":"+value);
}
HttpSession session = httpRequest.getSession();
this.context.log("session:"+session);
if(null != session)
for (String sessionAttName:
Collections.list(session.getAttributeNames())) {
this.context.log("session attribute
"+sessionAttName+":"+session.getAttribute(sessionAttName));
}
for ( String attributeName:
Collections.list(context.getAttributeNames())) {
this.context.log("context attr
"+attributeName+"="+context.getAttribute(attributeName));
}
Object cert =
httpRequest.getAttribute("javax.servlet.request.X509Certificate");
this.context.log("user:"+user);
this.context.log("cert:"+cert);
this.context.log("authType:"+authType);
this.context.log("getContextPath:"+httpRequest.getContextPath());
this.context.log("getProtocol:"+httpRequest.getProtocol());
this.context.log("getRemoteHost:"+httpRequest.getRemoteHost());
this.context.log("getServerInfo:"+context.getServerInfo());
this.context.log("getServletContextName:"+context.getServletContextName());
this.context.log("getRemoteHost:"+httpRequest.getRequestURI());
chain.doFilter(request, response);
}
}
>
> > I have a cgi in the cgi-bin directory, which prints out the
> > environment, and I see both REMOTE_USER and all relevant
> > certificate related information there.
> Is the CGI being executed by Tomcat or is it being executed by httpd?
Executed by Apache httpd. As you can see in the logs, mod_jk does not
pass any of that information through to tomcat, which is exactly my problem.
For reference, here is the code of the CGI (not my code, copied from the
internet):
#!/usr/bin/perl
print "Content-type: text/html\n\n";
print "\n";
foreach $key (sort keys(%ENV)) {
print "$key = $ENV{$key}";
}
print "\n";
and relevant parts of the output:
REMOTE_USER = github|756...@kode-konveyor.eu.auth0.com/
SSL_CLIENT_S_DN = emailAddress=m...@kodekonveyor.com,CN=mag
>
> -chris
> > -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For
additional commands, e-mail: users-h...@tomcat.apache.org >
Re: user and certificate info is not passed to tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Magosányi, On 10/7/19 10:37, Magosányi Árpád wrote: > I intend to use the user and certificate info in a Filter. > > I think I have configured everything to do that, but the > information does not get passed along. Based on various > documentations and howtos, SSLVerifyClient require, SSLOptions > +StdEnvVars and SSLOptions +ExportCertData and JkExtractSSL On > should be enough to pass certificate data, and Require valid-user > should be enough to pass the authenticated username. > > I see the following debug output (also contains the various info > logged by the filter), which clearly lacks the information needed. How are you getting the attributes from the request? > I have a cgi in the cgi-bin directory, which prints out the > environment, and I see both REMOTE_USER and all relevant > certificate related information there. Is the CGI being executed by Tomcat or is it being executed by httpd? - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2bVNYACgkQHPApP6U8 pFj/EBAAxOTOVnx/BoxXCtzkCTk4VH5WUrGi1iwwJODJ6h8d4jEz6Jm241gdNA4Q m6+x1vFHxjnvgdmVxo7RxrIjx0StLECRGk/dNbiRTKbx6uA4PpR+4DWB1X9HJ+pE NIkURRM33h/ywcwLEw0I3ar2qGJQuXPBktaYxyjdRQUgZHzKRdcZP9wLRCIkRskN qMkLGia7v4lIpmBN4EVTISJmFzFRwmgkxruFh8XG/1vecFbxuKr8N8U3fuW8ATnf 9zHWXbrjrqzWDBZGkNgFRNql0s6TS08CWivO6yeSk4BaiIqVvAuozrQzgKXPvDrS MeYa8X6G1L7XPxTKM563dFza6ohoaWDNZ7ylFYuGGlB3CYCZDPns22sXedfYWjrg FHbRuz+qdh5/+aWOtRKOniBT5HctOU14LTNBehX6TBwHimicLQ+nLd0wR1YMbO4Q W8C7XglralnGRzissW9/u+qAanXGW2jEILlLiubgTxNYWvSg4AJ5Dy4xeiUuYva/ WHGBWxTLoGc3gPYOKXbpk9m3d4kRejEiNrHtaYux3zOnjpjvSBjEalavhyN57J28 Wvs7JfCgOlzbEQXj6xaBUpoOxdZiiK3+jSByETXWd8n445xab59uC7RRcjD2g3L7 bVFlrQnxo4dUbM2Wf2+2Wrgm80+5wxgB/+YsfTXoHIZmLTX/tBY= =ejIn -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
user and certificate info is not passed to tomcat
I intend to use the user and certificate info in a Filter. I think I have configured everything to do that, but the information does not get passed along. Based on various documentations and howtos, SSLVerifyClient require, SSLOptions +StdEnvVars and SSLOptions +ExportCertData and JkExtractSSL On should be enough to pass certificate data, and Require valid-user should be enough to pass the authenticated username. I see the following debug output (also contains the various info logged by the filter), which clearly lacks the information needed. I have a cgi in the cgi-bin directory, which prints out the environment, and I see both REMOTE_USER and all relevant certificate related information there. debug log: Oct 5 19:46:13 s_src@repo apache-jk[7881]: [Sat Oct 05 19:46:13.554 2019] [7885:139750518257408] [debug] map_uri_to_worker_ext::jk_uri_worker_map.c (1185): Attempting to map URI '/servlet/servlet' from 1 maps Oct 5 19:46:13 s_src@repo apache-jk[7881]: [Sat Oct 05 19:46:13.555 2019] [7885:139750518257408] [debug] find_match::jk_uri_worker_map.c (980): Attempting to map context URI '/servlet*=worker1' source 'JkMount' Oct 5 19:46:13 s_src@repo apache-jk[7881]: [Sat Oct 05 19:46:13.555 2019] [7885:139750518257408] [debug] find_match::jk_uri_worker_map.c (993): Found a wildchar match '/servlet*=worker1' Oct 5 19:46:13 s_src@repo apache-jk[7881]: [Sat Oct 05 19:46:13.556 2019] [7885:139750518257408] [debug] jk_handler::mod_jk.c (2823): Into handler jakarta-servlet worker=worker1 r->proxyreq=0 Oct 5 19:46:13 s_src@repo apache-jk[7881]: [Sat Oct 05 19:46:13.556 2019] [7885:139750518257408] [debug] wc_get_worker_for_name::jk_worker.c (120): found a worker worker1 Oct 5 19:46:13 s_src@repo apache-jk[7881]: [Sat Oct 05 19:46:13.557 2019] [7885:139750518257408] [debug] wc_get_name_for_type::jk_worker.c (304): Found worker type 'ajp13' Oct 5 19:46:13 s_src@repo apache-jk[7881]: [Sat Oct 05 19:46:13.557 2019] [7885:139750518257408] [debug] init_ws_service::mod_jk.c (1196): Service protocol=HTTP/1.1 method=GET ssl=true host=(null) addr=94.62.142.229 name=repository.kodekonveyor.com port=443 auth=(null) user=(null) laddr=217.61.105.99 raddr=94.62.142.229 uaddr=94.62.142.229 uri=/servlet/servlet Oct 5 19:46:13 s_src@repo apache-jk[7881]: [Sat Oct 05 19:46:13.558 2019] [7885:139750518257408] [debug] ajp_get_endpoint::jk_ajp_common.c (3356): (worker1) acquired connection pool slot=0 after 0 retries Oct 5 19:46:13 s_src@repo apache-jk[7881]: [Sat Oct 05 19:46:13.559 2019] [7885:139750518257408] [debug] ajp_marshal_into_msgb::jk_ajp_common.c (684): (worker1) ajp marshaling done Oct 5 19:46:13 s_src@repo apache-jk[7881]: [Sat Oct 05 19:46:13.559 2019] [7885:139750518257408] [debug] ajp_service::jk_ajp_common.c (2591): processing worker1 with 2 retries Oct 5 19:46:13 s_src@repo apache-jk[7881]: [Sat Oct 05 19:46:13.560 2019] [7885:139750518257408] [debug] ajp_send_request::jk_ajp_common.c (1722): (worker1) no usable connection found, will create a new one. Oct 5 19:46:13 s_src@repo apache-jk[7881]: [Sat Oct 05 19:46:13.561 2019] [7885:139750518257408] [debug] jk_open_socket::jk_connect.c (675): socket TCP_NODELAY set to On Oct 5 19:46:13 s_src@repo apache-jk[7881]: [Sat Oct 05 19:46:13.561 2019] [7885:139750518257408] [debug] jk_open_socket::jk_connect.c (799): trying to connect socket 24 to ::1:8009 Oct 5 19:46:13 s_src@repo apache-jk[7881]: [Sat Oct 05 19:46:13.565 2019] [7885:139750518257408] [debug] jk_open_socket::jk_connect.c (825): socket 24 [:::51520 -> ::a00:c940:0:0:8009] connected Oct 5 19:46:13 s_src@repo apache-jk[7881]: [Sat Oct 05 19:46:13.566 2019] [7885:139750518257408] [debug] ajp_connection_tcp_send_message::jk_ajp_common.c (1267): sending to ajp13 pos=4 len=620 max=8192 Oct 5 19:46:13 s_src@repo apache-jk[7881]: [Sat Oct 05 19:46:13.566 2019] [7885:139750518257408] [debug] ajp_connection_tcp_send_message::jk_ajp_common.c (1267): 12 34 02 68 02 02 00 08 48 54 54 50 2F 31 2E 31 - .4.hHTTP/1.1 Oct 5 19:46:13 s_src@repo apache-jk[7881]: [Sat Oct 05 19:46:13.567 2019] [7885:139750518257408] [debug] ajp_connection_tcp_send_message::jk_ajp_common.c (1267): 001000 00 10 2F 73 65 72 76 6C 65 74 2F 73 65 72 76 - .../servlet/serv Oct 5 19:46:13 s_src@repo apache-jk[7881]: [Sat Oct 05 19:46:13.567 2019] [7885:139750518257408] [debug] ajp_connection_tcp_send_message::jk_ajp_common.c (1267): 00206C 65 74 00 00 0D 39 34 2E 36 32 2E 31 34 32 2E - let...94.62.142. Oct 5 19:46:13 s_src@repo apache-jk[7881]: [Sat Oct 05 19:46:13.567 2019] [7885:139750518257408] [debug] ajp_connection_tcp_send_message::jk_ajp_common.c (1267): 003032 32 39 00 FF FF 00 1B 72 65 70 6F 73 69 74 6F - 229.reposito Oct 5 19:46:13 s_src@repo apache-jk[7881]: [Sat Oct 05 19:46:13.567 2019] [7885:139750518257408] [debug] ajp_connection_tcp_send_message::jk_ajp_common.c (1267): 004072 79 2E 6B 6F 64 65 6B 6F 6E 76 65 79 6F 72 2E -
