You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Martynas Jusevičius <ma...@atomgraph.com> on 2020/02/27 09:58:01 UTC
Client cert auth on demand
Hi list,
I'm using a Docker image based on tomcat:8.0-jre8. It serves as an
end-user facing webapp but also as a REST API which authenticates
using client certificates. The same URLs serve both purposes, however
only administrators are using the API.
The Connector is configured using clientAuth="want".
This works fine with API calls which are run from shell scripts.
In the browser however it prompts a certificate selection (if there
are any client certs). This would not be a problem if the webapp would
not be user-facing, but since it is the certificate prompt can be
confusing to many users and increase our bounce rate.
I'm looking for some workaround that would not require changing the
whole design. For example asking for the client cert only when a
certain flag is set, such as a query param or request header.
Or somehow not asking for it but still accepting it :) But I guess
that's not how TLS works...
Any ideas? Thanks.
Martynas
atomgraph.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Client cert auth on demand
Posted by Martynas Jusevičius <ma...@atomgraph.com>.
My bad - I was looking in the catalina log, not the localhost log...
Now I see the config being parsed:
01-Mar-2020 21:12:49.147 FINE [localhost-startStop-1]
org.apache.catalina.valves.rewrite.RewriteValve.startInternal Read
configuration from: /WEB-INF/rewrite.config
01-Mar-2020 21:12:49.155 FINE [localhost-startStop-1]
org.apache.catalina.valves.rewrite.RewriteValve.parse Add rule with
pattern ^(.*)(localhost\%3A5443)(.*)$ and substitution $1localhost$3
01-Mar-2020 21:12:49.155 FINE [localhost-startStop-1]
org.apache.catalina.valves.rewrite.RewriteValve.parse Add condition
localhost%3A5443 test %{QUERY_STRING} to rule with pattern
^(.*)(localhost\%3A5443)(.*)$ and substitution $1localhost$3
On Mon, Mar 2, 2020 at 11:51 AM Martynas Jusevičius
<ma...@atomgraph.com> wrote:
>
> No matter where I place the rewrite.config, cannot get the
> RewriteValve to find it.
>
> I tried:
> * /usr/local/tomcat/conf/Catalina/localhost/ROOT.xml and
> /usr/local/tomcat/webapps/ROOT/WEB-INF/rewrite.config
> * /usr/local/tomcat/conf/context.xml and
> /usr/local/tomcat/conf/localhost/rewrite.config
>
> The only log output I get is:
>
> 01-Mar-2020 18:45:50.647 FINE [localhost-startStop-1]
> org.apache.catalina.util.LifecycleBase.setStateInternal Setting state
> for [org.apache.catalina.valves.rewrite.RewriteValve[]] to
> [INITIALIZING]
> 01-Mar-2020 18:45:50.650 FINE [localhost-startStop-1]
> org.apache.catalina.util.LifecycleBase.setStateInternal Setting state
> for [org.apache.catalina.valves.rewrite.RewriteValve[]] to
> [INITIALIZED]
> 01-Mar-2020 18:45:50.651 FINE [localhost-startStop-1]
> org.apache.catalina.util.LifecycleBase.setStateInternal Setting state
> for [org.apache.catalina.valves.rewrite.RewriteValve[]] to
> [STARTING_PREP]
> 01-Mar-2020 18:45:50.652 FINE [localhost-startStop-1]
> org.apache.catalina.util.LifecycleBase.setStateInternal Setting state
> for [org.apache.catalina.valves.rewrite.RewriteValve[]] to [STARTING]
> 01-Mar-2020 18:45:50.654 FINE [localhost-startStop-1]
> org.apache.catalina.util.LifecycleBase.setStateInternal Setting state
> for [org.apache.catalina.valves.rewrite.RewriteValve[]] to [STARTED]
>
>
>
> On Sun, Mar 1, 2020 at 2:15 PM Martynas Jusevičius
> <ma...@atomgraph.com> wrote:
> >
> > I hit a snag with the query string. In some cases it contains the
> > webapp base URI in a query parameter, such as:
> >
> > /admin/acl/authorizations/?forClass=https%3A//localhost%3A5443/admin/ns%23Authorization
> >
> > So I'm trying to rewrite those as well, from
> > https%3A//localhost%3A5443/ to https%3A//localhost/ (remove the port
> > number).
> >
> > RewriteValve seems to do what I need:
> > https://tomcat.apache.org/tomcat-8.0-doc/rewrite.html
> >
> > I have mounted the following under
> > /usr/local/tomcat/conf/Catalina/localhost/ROOT.xml
> >
> > <?xml version="1.0"?>
> > <Context>
> > <Valve className="org.apache.catalina.valves.rewrite.RewriteValve"/>
> > </Context>
> >
> > and this under /usr/local/tomcat/webapps/ROOT/WEB-INF/rewrite.config
> >
> > RewriteCond %{QUERY_STRING} localhost%3A5443
> > RewriteRule ^(.*)(localhost%3A5443)(.*)$ $1localhost$2
> >
> > However I'm not seeing any output re. RewriteValve in the Tomcat log.
> > The rewrite is not happening and it doesn't look like the config is
> > even read.
> >
> > On Sat, Feb 29, 2020 at 4:21 PM Martynas Jusevičius
> > <ma...@atomgraph.com> wrote:
> > >
> > > Thanks! I actually needed proxyPort="443" to make the URL
> > > https://localhost, but your suggestion did the trick.
> > >
> > > On Sat, Feb 29, 2020 at 11:12 AM Mark Thomas <ma...@apache.org> wrote:
> > > >
> > > >
> > > >
> > > > On 28/02/2020 22:26, Martynas Jusevičius wrote:
> > > > > Yes the clients connect only directly to nginx.
> > > > >
> > > > > So the proxy config within 2 pairs of containers is like this:
> > > > >
> > > > > # website service; clientAuth=false
> > > > > nginx:80 -> tomcat:8080
> > > > > nginx:443 -> tomcat:8443
> > > > >
> > > > > # API service; clientAuth=true
> > > > > nginx-api:90 -> tomcat-api:8080
> > > > > nginx-api:5443 -> tomcat-api:8443
> > > >
> > > > Try using proxyPort="5443" on the HTTPS connector in Tomcat for this
> > > > instance. That should do the trick.
> > > >
> > > > Mark
> > > >
> > > >
> > > > >
> > > > > nginx and nginx-api ports are exposed to the Docker host and that is
> > > > > where the clients access them, therefore the host name the webapp sees
> > > > > is localhost (as in my rewrite example).
> > > > >
> > > > > What I'm trying to do is to fool the webapp on tomcat-api into
> > > > > thinking it's being accessed on localhost:80/443 instead of
> > > > > localhost:90/5443.
> > > > >
> > > > > Absolute URIs matter in this case because they are used for direct
> > > > > lookups in an RDF triplestore and RDF uses absolute URIs.
> > > > >
> > > > >
> > > > > On Fri, Feb 28, 2020 at 10:59 PM Mark Thomas <ma...@apache.org> wrote:
> > > > >>
> > > > >> On 28/02/2020 21:00, Martynas Jusevičius wrote:
> > > > >>> Setting up a second container with a different port was easy enough.
> > > > >>>
> > > > >>> However I got stuck on the URL mapping/rewriting. Using nginx as a
> > > > >>> proxy, I don't think it's possible to rewrite headers with the
> > > > >>> upstream module:
> > > > >>> https://nginx.org/en/docs/http/ngx_http_upstream_module.html
> > > > >>>
> > > > >>> As I understand it just forwards raw traffic, so the URL rewriting
> > > > >>> would have to be done on the Tomcat's side. Basically I want to
> > > > >>> rewrite:
> > > > >>>
> > > > >>> https://localhost:5443/ => https://localhost/
> > > > >>>
> > > > >>> which requires rewriting the Host request header, I think.
> > > > >>>
> > > > >>> I was looking at the RewriteValve, but it says:
> > > > >>> "Unlike newer mod_rewrite versions, the Tomcat rewrite valve does not
> > > > >>> automatically support absolute URLs (the specific redirect flag must
> > > > >>> be used to be able to specify an absolute URLs, see below) or direct
> > > > >>> file serving."
> > > > >>>
> > > > >>> Is there a way to rewrite the hostname/port in configuration?
> > > > >>> Something placed in context.xml would be ideal.
> > > > >>
> > > > >>
> > > > >> What port is nginx listening on?
> > > > >>
> > > > >> What port is Tomcat listening on?
> > > > >>
> > > > >> I assume the client connects directly to nginx.
> > > > >>
> > > > >> Mark
> > > > >>
> > > > >>
> > > > >> ---------------------------------------------------------------------
> > > > >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > > > >> For additional commands, e-mail: users-help@tomcat.apache.org
> > > > >>
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > > > > For additional commands, e-mail: users-help@tomcat.apache.org
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > > > For additional commands, e-mail: users-help@tomcat.apache.org
> > > >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Client cert auth on demand
Posted by Martynas Jusevičius <ma...@atomgraph.com>.
No matter where I place the rewrite.config, cannot get the
RewriteValve to find it.
I tried:
* /usr/local/tomcat/conf/Catalina/localhost/ROOT.xml and
/usr/local/tomcat/webapps/ROOT/WEB-INF/rewrite.config
* /usr/local/tomcat/conf/context.xml and
/usr/local/tomcat/conf/localhost/rewrite.config
The only log output I get is:
01-Mar-2020 18:45:50.647 FINE [localhost-startStop-1]
org.apache.catalina.util.LifecycleBase.setStateInternal Setting state
for [org.apache.catalina.valves.rewrite.RewriteValve[]] to
[INITIALIZING]
01-Mar-2020 18:45:50.650 FINE [localhost-startStop-1]
org.apache.catalina.util.LifecycleBase.setStateInternal Setting state
for [org.apache.catalina.valves.rewrite.RewriteValve[]] to
[INITIALIZED]
01-Mar-2020 18:45:50.651 FINE [localhost-startStop-1]
org.apache.catalina.util.LifecycleBase.setStateInternal Setting state
for [org.apache.catalina.valves.rewrite.RewriteValve[]] to
[STARTING_PREP]
01-Mar-2020 18:45:50.652 FINE [localhost-startStop-1]
org.apache.catalina.util.LifecycleBase.setStateInternal Setting state
for [org.apache.catalina.valves.rewrite.RewriteValve[]] to [STARTING]
01-Mar-2020 18:45:50.654 FINE [localhost-startStop-1]
org.apache.catalina.util.LifecycleBase.setStateInternal Setting state
for [org.apache.catalina.valves.rewrite.RewriteValve[]] to [STARTED]
On Sun, Mar 1, 2020 at 2:15 PM Martynas Jusevičius
<ma...@atomgraph.com> wrote:
>
> I hit a snag with the query string. In some cases it contains the
> webapp base URI in a query parameter, such as:
>
> /admin/acl/authorizations/?forClass=https%3A//localhost%3A5443/admin/ns%23Authorization
>
> So I'm trying to rewrite those as well, from
> https%3A//localhost%3A5443/ to https%3A//localhost/ (remove the port
> number).
>
> RewriteValve seems to do what I need:
> https://tomcat.apache.org/tomcat-8.0-doc/rewrite.html
>
> I have mounted the following under
> /usr/local/tomcat/conf/Catalina/localhost/ROOT.xml
>
> <?xml version="1.0"?>
> <Context>
> <Valve className="org.apache.catalina.valves.rewrite.RewriteValve"/>
> </Context>
>
> and this under /usr/local/tomcat/webapps/ROOT/WEB-INF/rewrite.config
>
> RewriteCond %{QUERY_STRING} localhost%3A5443
> RewriteRule ^(.*)(localhost%3A5443)(.*)$ $1localhost$2
>
> However I'm not seeing any output re. RewriteValve in the Tomcat log.
> The rewrite is not happening and it doesn't look like the config is
> even read.
>
> On Sat, Feb 29, 2020 at 4:21 PM Martynas Jusevičius
> <ma...@atomgraph.com> wrote:
> >
> > Thanks! I actually needed proxyPort="443" to make the URL
> > https://localhost, but your suggestion did the trick.
> >
> > On Sat, Feb 29, 2020 at 11:12 AM Mark Thomas <ma...@apache.org> wrote:
> > >
> > >
> > >
> > > On 28/02/2020 22:26, Martynas Jusevičius wrote:
> > > > Yes the clients connect only directly to nginx.
> > > >
> > > > So the proxy config within 2 pairs of containers is like this:
> > > >
> > > > # website service; clientAuth=false
> > > > nginx:80 -> tomcat:8080
> > > > nginx:443 -> tomcat:8443
> > > >
> > > > # API service; clientAuth=true
> > > > nginx-api:90 -> tomcat-api:8080
> > > > nginx-api:5443 -> tomcat-api:8443
> > >
> > > Try using proxyPort="5443" on the HTTPS connector in Tomcat for this
> > > instance. That should do the trick.
> > >
> > > Mark
> > >
> > >
> > > >
> > > > nginx and nginx-api ports are exposed to the Docker host and that is
> > > > where the clients access them, therefore the host name the webapp sees
> > > > is localhost (as in my rewrite example).
> > > >
> > > > What I'm trying to do is to fool the webapp on tomcat-api into
> > > > thinking it's being accessed on localhost:80/443 instead of
> > > > localhost:90/5443.
> > > >
> > > > Absolute URIs matter in this case because they are used for direct
> > > > lookups in an RDF triplestore and RDF uses absolute URIs.
> > > >
> > > >
> > > > On Fri, Feb 28, 2020 at 10:59 PM Mark Thomas <ma...@apache.org> wrote:
> > > >>
> > > >> On 28/02/2020 21:00, Martynas Jusevičius wrote:
> > > >>> Setting up a second container with a different port was easy enough.
> > > >>>
> > > >>> However I got stuck on the URL mapping/rewriting. Using nginx as a
> > > >>> proxy, I don't think it's possible to rewrite headers with the
> > > >>> upstream module:
> > > >>> https://nginx.org/en/docs/http/ngx_http_upstream_module.html
> > > >>>
> > > >>> As I understand it just forwards raw traffic, so the URL rewriting
> > > >>> would have to be done on the Tomcat's side. Basically I want to
> > > >>> rewrite:
> > > >>>
> > > >>> https://localhost:5443/ => https://localhost/
> > > >>>
> > > >>> which requires rewriting the Host request header, I think.
> > > >>>
> > > >>> I was looking at the RewriteValve, but it says:
> > > >>> "Unlike newer mod_rewrite versions, the Tomcat rewrite valve does not
> > > >>> automatically support absolute URLs (the specific redirect flag must
> > > >>> be used to be able to specify an absolute URLs, see below) or direct
> > > >>> file serving."
> > > >>>
> > > >>> Is there a way to rewrite the hostname/port in configuration?
> > > >>> Something placed in context.xml would be ideal.
> > > >>
> > > >>
> > > >> What port is nginx listening on?
> > > >>
> > > >> What port is Tomcat listening on?
> > > >>
> > > >> I assume the client connects directly to nginx.
> > > >>
> > > >> Mark
> > > >>
> > > >>
> > > >> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > > >> For additional commands, e-mail: users-help@tomcat.apache.org
> > > >>
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > > > For additional commands, e-mail: users-help@tomcat.apache.org
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > > For additional commands, e-mail: users-help@tomcat.apache.org
> > >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Client cert auth on demand
Posted by Martynas Jusevičius <ma...@atomgraph.com>.
I hit a snag with the query string. In some cases it contains the
webapp base URI in a query parameter, such as:
/admin/acl/authorizations/?forClass=https%3A//localhost%3A5443/admin/ns%23Authorization
So I'm trying to rewrite those as well, from
https%3A//localhost%3A5443/ to https%3A//localhost/ (remove the port
number).
RewriteValve seems to do what I need:
https://tomcat.apache.org/tomcat-8.0-doc/rewrite.html
I have mounted the following under
/usr/local/tomcat/conf/Catalina/localhost/ROOT.xml
<?xml version="1.0"?>
<Context>
<Valve className="org.apache.catalina.valves.rewrite.RewriteValve"/>
</Context>
and this under /usr/local/tomcat/webapps/ROOT/WEB-INF/rewrite.config
RewriteCond %{QUERY_STRING} localhost%3A5443
RewriteRule ^(.*)(localhost%3A5443)(.*)$ $1localhost$2
However I'm not seeing any output re. RewriteValve in the Tomcat log.
The rewrite is not happening and it doesn't look like the config is
even read.
On Sat, Feb 29, 2020 at 4:21 PM Martynas Jusevičius
<ma...@atomgraph.com> wrote:
>
> Thanks! I actually needed proxyPort="443" to make the URL
> https://localhost, but your suggestion did the trick.
>
> On Sat, Feb 29, 2020 at 11:12 AM Mark Thomas <ma...@apache.org> wrote:
> >
> >
> >
> > On 28/02/2020 22:26, Martynas Jusevičius wrote:
> > > Yes the clients connect only directly to nginx.
> > >
> > > So the proxy config within 2 pairs of containers is like this:
> > >
> > > # website service; clientAuth=false
> > > nginx:80 -> tomcat:8080
> > > nginx:443 -> tomcat:8443
> > >
> > > # API service; clientAuth=true
> > > nginx-api:90 -> tomcat-api:8080
> > > nginx-api:5443 -> tomcat-api:8443
> >
> > Try using proxyPort="5443" on the HTTPS connector in Tomcat for this
> > instance. That should do the trick.
> >
> > Mark
> >
> >
> > >
> > > nginx and nginx-api ports are exposed to the Docker host and that is
> > > where the clients access them, therefore the host name the webapp sees
> > > is localhost (as in my rewrite example).
> > >
> > > What I'm trying to do is to fool the webapp on tomcat-api into
> > > thinking it's being accessed on localhost:80/443 instead of
> > > localhost:90/5443.
> > >
> > > Absolute URIs matter in this case because they are used for direct
> > > lookups in an RDF triplestore and RDF uses absolute URIs.
> > >
> > >
> > > On Fri, Feb 28, 2020 at 10:59 PM Mark Thomas <ma...@apache.org> wrote:
> > >>
> > >> On 28/02/2020 21:00, Martynas Jusevičius wrote:
> > >>> Setting up a second container with a different port was easy enough.
> > >>>
> > >>> However I got stuck on the URL mapping/rewriting. Using nginx as a
> > >>> proxy, I don't think it's possible to rewrite headers with the
> > >>> upstream module:
> > >>> https://nginx.org/en/docs/http/ngx_http_upstream_module.html
> > >>>
> > >>> As I understand it just forwards raw traffic, so the URL rewriting
> > >>> would have to be done on the Tomcat's side. Basically I want to
> > >>> rewrite:
> > >>>
> > >>> https://localhost:5443/ => https://localhost/
> > >>>
> > >>> which requires rewriting the Host request header, I think.
> > >>>
> > >>> I was looking at the RewriteValve, but it says:
> > >>> "Unlike newer mod_rewrite versions, the Tomcat rewrite valve does not
> > >>> automatically support absolute URLs (the specific redirect flag must
> > >>> be used to be able to specify an absolute URLs, see below) or direct
> > >>> file serving."
> > >>>
> > >>> Is there a way to rewrite the hostname/port in configuration?
> > >>> Something placed in context.xml would be ideal.
> > >>
> > >>
> > >> What port is nginx listening on?
> > >>
> > >> What port is Tomcat listening on?
> > >>
> > >> I assume the client connects directly to nginx.
> > >>
> > >> Mark
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > >> For additional commands, e-mail: users-help@tomcat.apache.org
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > > For additional commands, e-mail: users-help@tomcat.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Client cert auth on demand
Posted by Martynas Jusevičius <ma...@atomgraph.com>.
Thanks! I actually needed proxyPort="443" to make the URL
https://localhost, but your suggestion did the trick.
On Sat, Feb 29, 2020 at 11:12 AM Mark Thomas <ma...@apache.org> wrote:
>
>
>
> On 28/02/2020 22:26, Martynas Jusevičius wrote:
> > Yes the clients connect only directly to nginx.
> >
> > So the proxy config within 2 pairs of containers is like this:
> >
> > # website service; clientAuth=false
> > nginx:80 -> tomcat:8080
> > nginx:443 -> tomcat:8443
> >
> > # API service; clientAuth=true
> > nginx-api:90 -> tomcat-api:8080
> > nginx-api:5443 -> tomcat-api:8443
>
> Try using proxyPort="5443" on the HTTPS connector in Tomcat for this
> instance. That should do the trick.
>
> Mark
>
>
> >
> > nginx and nginx-api ports are exposed to the Docker host and that is
> > where the clients access them, therefore the host name the webapp sees
> > is localhost (as in my rewrite example).
> >
> > What I'm trying to do is to fool the webapp on tomcat-api into
> > thinking it's being accessed on localhost:80/443 instead of
> > localhost:90/5443.
> >
> > Absolute URIs matter in this case because they are used for direct
> > lookups in an RDF triplestore and RDF uses absolute URIs.
> >
> >
> > On Fri, Feb 28, 2020 at 10:59 PM Mark Thomas <ma...@apache.org> wrote:
> >>
> >> On 28/02/2020 21:00, Martynas Jusevičius wrote:
> >>> Setting up a second container with a different port was easy enough.
> >>>
> >>> However I got stuck on the URL mapping/rewriting. Using nginx as a
> >>> proxy, I don't think it's possible to rewrite headers with the
> >>> upstream module:
> >>> https://nginx.org/en/docs/http/ngx_http_upstream_module.html
> >>>
> >>> As I understand it just forwards raw traffic, so the URL rewriting
> >>> would have to be done on the Tomcat's side. Basically I want to
> >>> rewrite:
> >>>
> >>> https://localhost:5443/ => https://localhost/
> >>>
> >>> which requires rewriting the Host request header, I think.
> >>>
> >>> I was looking at the RewriteValve, but it says:
> >>> "Unlike newer mod_rewrite versions, the Tomcat rewrite valve does not
> >>> automatically support absolute URLs (the specific redirect flag must
> >>> be used to be able to specify an absolute URLs, see below) or direct
> >>> file serving."
> >>>
> >>> Is there a way to rewrite the hostname/port in configuration?
> >>> Something placed in context.xml would be ideal.
> >>
> >>
> >> What port is nginx listening on?
> >>
> >> What port is Tomcat listening on?
> >>
> >> I assume the client connects directly to nginx.
> >>
> >> Mark
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Client cert auth on demand
Posted by Mark Thomas <ma...@apache.org>.
On 28/02/2020 22:26, Martynas Jusevičius wrote:
> Yes the clients connect only directly to nginx.
>
> So the proxy config within 2 pairs of containers is like this:
>
> # website service; clientAuth=false
> nginx:80 -> tomcat:8080
> nginx:443 -> tomcat:8443
>
> # API service; clientAuth=true
> nginx-api:90 -> tomcat-api:8080
> nginx-api:5443 -> tomcat-api:8443
Try using proxyPort="5443" on the HTTPS connector in Tomcat for this
instance. That should do the trick.
Mark
>
> nginx and nginx-api ports are exposed to the Docker host and that is
> where the clients access them, therefore the host name the webapp sees
> is localhost (as in my rewrite example).
>
> What I'm trying to do is to fool the webapp on tomcat-api into
> thinking it's being accessed on localhost:80/443 instead of
> localhost:90/5443.
>
> Absolute URIs matter in this case because they are used for direct
> lookups in an RDF triplestore and RDF uses absolute URIs.
>
>
> On Fri, Feb 28, 2020 at 10:59 PM Mark Thomas <ma...@apache.org> wrote:
>>
>> On 28/02/2020 21:00, Martynas Jusevičius wrote:
>>> Setting up a second container with a different port was easy enough.
>>>
>>> However I got stuck on the URL mapping/rewriting. Using nginx as a
>>> proxy, I don't think it's possible to rewrite headers with the
>>> upstream module:
>>> https://nginx.org/en/docs/http/ngx_http_upstream_module.html
>>>
>>> As I understand it just forwards raw traffic, so the URL rewriting
>>> would have to be done on the Tomcat's side. Basically I want to
>>> rewrite:
>>>
>>> https://localhost:5443/ => https://localhost/
>>>
>>> which requires rewriting the Host request header, I think.
>>>
>>> I was looking at the RewriteValve, but it says:
>>> "Unlike newer mod_rewrite versions, the Tomcat rewrite valve does not
>>> automatically support absolute URLs (the specific redirect flag must
>>> be used to be able to specify an absolute URLs, see below) or direct
>>> file serving."
>>>
>>> Is there a way to rewrite the hostname/port in configuration?
>>> Something placed in context.xml would be ideal.
>>
>>
>> What port is nginx listening on?
>>
>> What port is Tomcat listening on?
>>
>> I assume the client connects directly to nginx.
>>
>> Mark
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Client cert auth on demand
Posted by Martynas Jusevičius <ma...@atomgraph.com>.
Yes the clients connect only directly to nginx.
So the proxy config within 2 pairs of containers is like this:
# website service; clientAuth=false
nginx:80 -> tomcat:8080
nginx:443 -> tomcat:8443
# API service; clientAuth=true
nginx-api:90 -> tomcat-api:8080
nginx-api:5443 -> tomcat-api:8443
nginx and nginx-api ports are exposed to the Docker host and that is
where the clients access them, therefore the host name the webapp sees
is localhost (as in my rewrite example).
What I'm trying to do is to fool the webapp on tomcat-api into
thinking it's being accessed on localhost:80/443 instead of
localhost:90/5443.
Absolute URIs matter in this case because they are used for direct
lookups in an RDF triplestore and RDF uses absolute URIs.
On Fri, Feb 28, 2020 at 10:59 PM Mark Thomas <ma...@apache.org> wrote:
>
> On 28/02/2020 21:00, Martynas Jusevičius wrote:
> > Setting up a second container with a different port was easy enough.
> >
> > However I got stuck on the URL mapping/rewriting. Using nginx as a
> > proxy, I don't think it's possible to rewrite headers with the
> > upstream module:
> > https://nginx.org/en/docs/http/ngx_http_upstream_module.html
> >
> > As I understand it just forwards raw traffic, so the URL rewriting
> > would have to be done on the Tomcat's side. Basically I want to
> > rewrite:
> >
> > https://localhost:5443/ => https://localhost/
> >
> > which requires rewriting the Host request header, I think.
> >
> > I was looking at the RewriteValve, but it says:
> > "Unlike newer mod_rewrite versions, the Tomcat rewrite valve does not
> > automatically support absolute URLs (the specific redirect flag must
> > be used to be able to specify an absolute URLs, see below) or direct
> > file serving."
> >
> > Is there a way to rewrite the hostname/port in configuration?
> > Something placed in context.xml would be ideal.
>
>
> What port is nginx listening on?
>
> What port is Tomcat listening on?
>
> I assume the client connects directly to nginx.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Client cert auth on demand
Posted by Mark Thomas <ma...@apache.org>.
On 28/02/2020 21:00, Martynas Jusevičius wrote:
> Setting up a second container with a different port was easy enough.
>
> However I got stuck on the URL mapping/rewriting. Using nginx as a
> proxy, I don't think it's possible to rewrite headers with the
> upstream module:
> https://nginx.org/en/docs/http/ngx_http_upstream_module.html
>
> As I understand it just forwards raw traffic, so the URL rewriting
> would have to be done on the Tomcat's side. Basically I want to
> rewrite:
>
> https://localhost:5443/ => https://localhost/
>
> which requires rewriting the Host request header, I think.
>
> I was looking at the RewriteValve, but it says:
> "Unlike newer mod_rewrite versions, the Tomcat rewrite valve does not
> automatically support absolute URLs (the specific redirect flag must
> be used to be able to specify an absolute URLs, see below) or direct
> file serving."
>
> Is there a way to rewrite the hostname/port in configuration?
> Something placed in context.xml would be ideal.
What port is nginx listening on?
What port is Tomcat listening on?
I assume the client connects directly to nginx.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Client cert auth on demand
Posted by Martynas Jusevičius <ma...@atomgraph.com>.
Setting up a second container with a different port was easy enough.
However I got stuck on the URL mapping/rewriting. Using nginx as a
proxy, I don't think it's possible to rewrite headers with the
upstream module:
https://nginx.org/en/docs/http/ngx_http_upstream_module.html
As I understand it just forwards raw traffic, so the URL rewriting
would have to be done on the Tomcat's side. Basically I want to
rewrite:
https://localhost:5443/ => https://localhost/
which requires rewriting the Host request header, I think.
I was looking at the RewriteValve, but it says:
"Unlike newer mod_rewrite versions, the Tomcat rewrite valve does not
automatically support absolute URLs (the specific redirect flag must
be used to be able to specify an absolute URLs, see below) or direct
file serving."
Is there a way to rewrite the hostname/port in configuration?
Something placed in context.xml would be ideal.
On Thu, Feb 27, 2020 at 11:52 AM Martynas Jusevičius
<ma...@atomgraph.com> wrote:
>
> Tomcat is deep within the Docker image configured with a single
> connector and a single ROOT webapp, so it's easier to deploy a second
> container than to add a second connector or context :)
>
> Thanks for your help.
>
>
> On Thu, Feb 27, 2020 at 11:36 AM Mark Thomas <ma...@apache.org> wrote:
> >
> > On 27/02/2020 10:28, Martynas Jusevičius wrote:
> > > Yes, that could be an option. Or, since we're on Docker, a second
> > > instance of the webapp on a different port would be easier.
> > >
> > > But we would need to add some URL rewriting proxy before that
> > > connector to strip that port number to make the webapp see the
> > > canonical URLs. That should be doable with nginx which we are using
> > > anyway.
> > >
> > > So essentially 2 webapps on different ports, one configured without
> > > the clientAuth for the end-users, and one with clientAuth for the API
> > > access, correct?
> >
> > It depends on what you can / want to change.
> >
> > The approach you describe should work.
> >
> > If you can change the clients, a second Connector for the same
> > Service/Engine/Host/Context is all that should be required.
> >
> > Depending on the URLs used, you might be able to deploy two versions of
> > the web application to different Contexts, remap the internal servlets
> > and still have clients see the same URLs. In that case you could move
> > the client auth requirement to the web application.
> >
> > There are quite a few options. It really comes down to want you can
> > control, and what is easiest for you to change.
> >
> > Mark
> >
> >
> > >
> > > On Thu, Feb 27, 2020 at 11:18 AM Mark Thomas <ma...@apache.org> wrote:
> > >>
> > >> On 27/02/2020 09:58, Martynas Jusevičius wrote:
> > >>> Hi list,
> > >>>
> > >>> I'm using a Docker image based on tomcat:8.0-jre8. It serves as an
> > >>> end-user facing webapp but also as a REST API which authenticates
> > >>> using client certificates. The same URLs serve both purposes, however
> > >>> only administrators are using the API.
> > >>>
> > >>> The Connector is configured using clientAuth="want".
> > >>> This works fine with API calls which are run from shell scripts.
> > >>> In the browser however it prompts a certificate selection (if there
> > >>> are any client certs). This would not be a problem if the webapp would
> > >>> not be user-facing, but since it is the certificate prompt can be
> > >>> confusing to many users and increase our bounce rate.
> > >>>
> > >>> I'm looking for some workaround that would not require changing the
> > >>> whole design. For example asking for the client cert only when a
> > >>> certain flag is set, such as a query param or request header.
> > >>> Or somehow not asking for it but still accepting it :) But I guess
> > >>> that's not how TLS works...
> > >>>
> > >>> Any ideas? Thanks.
> > >>
> > >> Can you configure a separate connector on a different port for the shell
> > >> scripts to use?
> > >>
> > >> Mark
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > >> For additional commands, e-mail: users-help@tomcat.apache.org
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > > For additional commands, e-mail: users-help@tomcat.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Client cert auth on demand
Posted by Martynas Jusevičius <ma...@atomgraph.com>.
Tomcat is deep within the Docker image configured with a single
connector and a single ROOT webapp, so it's easier to deploy a second
container than to add a second connector or context :)
Thanks for your help.
On Thu, Feb 27, 2020 at 11:36 AM Mark Thomas <ma...@apache.org> wrote:
>
> On 27/02/2020 10:28, Martynas Jusevičius wrote:
> > Yes, that could be an option. Or, since we're on Docker, a second
> > instance of the webapp on a different port would be easier.
> >
> > But we would need to add some URL rewriting proxy before that
> > connector to strip that port number to make the webapp see the
> > canonical URLs. That should be doable with nginx which we are using
> > anyway.
> >
> > So essentially 2 webapps on different ports, one configured without
> > the clientAuth for the end-users, and one with clientAuth for the API
> > access, correct?
>
> It depends on what you can / want to change.
>
> The approach you describe should work.
>
> If you can change the clients, a second Connector for the same
> Service/Engine/Host/Context is all that should be required.
>
> Depending on the URLs used, you might be able to deploy two versions of
> the web application to different Contexts, remap the internal servlets
> and still have clients see the same URLs. In that case you could move
> the client auth requirement to the web application.
>
> There are quite a few options. It really comes down to want you can
> control, and what is easiest for you to change.
>
> Mark
>
>
> >
> > On Thu, Feb 27, 2020 at 11:18 AM Mark Thomas <ma...@apache.org> wrote:
> >>
> >> On 27/02/2020 09:58, Martynas Jusevičius wrote:
> >>> Hi list,
> >>>
> >>> I'm using a Docker image based on tomcat:8.0-jre8. It serves as an
> >>> end-user facing webapp but also as a REST API which authenticates
> >>> using client certificates. The same URLs serve both purposes, however
> >>> only administrators are using the API.
> >>>
> >>> The Connector is configured using clientAuth="want".
> >>> This works fine with API calls which are run from shell scripts.
> >>> In the browser however it prompts a certificate selection (if there
> >>> are any client certs). This would not be a problem if the webapp would
> >>> not be user-facing, but since it is the certificate prompt can be
> >>> confusing to many users and increase our bounce rate.
> >>>
> >>> I'm looking for some workaround that would not require changing the
> >>> whole design. For example asking for the client cert only when a
> >>> certain flag is set, such as a query param or request header.
> >>> Or somehow not asking for it but still accepting it :) But I guess
> >>> that's not how TLS works...
> >>>
> >>> Any ideas? Thanks.
> >>
> >> Can you configure a separate connector on a different port for the shell
> >> scripts to use?
> >>
> >> Mark
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Client cert auth on demand
Posted by Mark Thomas <ma...@apache.org>.
On 27/02/2020 10:28, Martynas Jusevičius wrote:
> Yes, that could be an option. Or, since we're on Docker, a second
> instance of the webapp on a different port would be easier.
>
> But we would need to add some URL rewriting proxy before that
> connector to strip that port number to make the webapp see the
> canonical URLs. That should be doable with nginx which we are using
> anyway.
>
> So essentially 2 webapps on different ports, one configured without
> the clientAuth for the end-users, and one with clientAuth for the API
> access, correct?
It depends on what you can / want to change.
The approach you describe should work.
If you can change the clients, a second Connector for the same
Service/Engine/Host/Context is all that should be required.
Depending on the URLs used, you might be able to deploy two versions of
the web application to different Contexts, remap the internal servlets
and still have clients see the same URLs. In that case you could move
the client auth requirement to the web application.
There are quite a few options. It really comes down to want you can
control, and what is easiest for you to change.
Mark
>
> On Thu, Feb 27, 2020 at 11:18 AM Mark Thomas <ma...@apache.org> wrote:
>>
>> On 27/02/2020 09:58, Martynas Jusevičius wrote:
>>> Hi list,
>>>
>>> I'm using a Docker image based on tomcat:8.0-jre8. It serves as an
>>> end-user facing webapp but also as a REST API which authenticates
>>> using client certificates. The same URLs serve both purposes, however
>>> only administrators are using the API.
>>>
>>> The Connector is configured using clientAuth="want".
>>> This works fine with API calls which are run from shell scripts.
>>> In the browser however it prompts a certificate selection (if there
>>> are any client certs). This would not be a problem if the webapp would
>>> not be user-facing, but since it is the certificate prompt can be
>>> confusing to many users and increase our bounce rate.
>>>
>>> I'm looking for some workaround that would not require changing the
>>> whole design. For example asking for the client cert only when a
>>> certain flag is set, such as a query param or request header.
>>> Or somehow not asking for it but still accepting it :) But I guess
>>> that's not how TLS works...
>>>
>>> Any ideas? Thanks.
>>
>> Can you configure a separate connector on a different port for the shell
>> scripts to use?
>>
>> Mark
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Client cert auth on demand
Posted by Martynas Jusevičius <ma...@atomgraph.com>.
Yes, that could be an option. Or, since we're on Docker, a second
instance of the webapp on a different port would be easier.
But we would need to add some URL rewriting proxy before that
connector to strip that port number to make the webapp see the
canonical URLs. That should be doable with nginx which we are using
anyway.
So essentially 2 webapps on different ports, one configured without
the clientAuth for the end-users, and one with clientAuth for the API
access, correct?
On Thu, Feb 27, 2020 at 11:18 AM Mark Thomas <ma...@apache.org> wrote:
>
> On 27/02/2020 09:58, Martynas Jusevičius wrote:
> > Hi list,
> >
> > I'm using a Docker image based on tomcat:8.0-jre8. It serves as an
> > end-user facing webapp but also as a REST API which authenticates
> > using client certificates. The same URLs serve both purposes, however
> > only administrators are using the API.
> >
> > The Connector is configured using clientAuth="want".
> > This works fine with API calls which are run from shell scripts.
> > In the browser however it prompts a certificate selection (if there
> > are any client certs). This would not be a problem if the webapp would
> > not be user-facing, but since it is the certificate prompt can be
> > confusing to many users and increase our bounce rate.
> >
> > I'm looking for some workaround that would not require changing the
> > whole design. For example asking for the client cert only when a
> > certain flag is set, such as a query param or request header.
> > Or somehow not asking for it but still accepting it :) But I guess
> > that's not how TLS works...
> >
> > Any ideas? Thanks.
>
> Can you configure a separate connector on a different port for the shell
> scripts to use?
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Client cert auth on demand
Posted by Mark Thomas <ma...@apache.org>.
On 27/02/2020 09:58, Martynas Jusevičius wrote:
> Hi list,
>
> I'm using a Docker image based on tomcat:8.0-jre8. It serves as an
> end-user facing webapp but also as a REST API which authenticates
> using client certificates. The same URLs serve both purposes, however
> only administrators are using the API.
>
> The Connector is configured using clientAuth="want".
> This works fine with API calls which are run from shell scripts.
> In the browser however it prompts a certificate selection (if there
> are any client certs). This would not be a problem if the webapp would
> not be user-facing, but since it is the certificate prompt can be
> confusing to many users and increase our bounce rate.
>
> I'm looking for some workaround that would not require changing the
> whole design. For example asking for the client cert only when a
> certain flag is set, such as a query param or request header.
> Or somehow not asking for it but still accepting it :) But I guess
> that's not how TLS works...
>
> Any ideas? Thanks.
Can you configure a separate connector on a different port for the shell
scripts to use?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Client cert auth on demand
Posted by Michael Osipov <mi...@apache.org>.
Am 2020-02-29 um 15:12 schrieb Mark Thomas:
> On 29/02/2020 13:05, Thomas Meyer wrote:
>> Am 29. Februar 2020 13:10:13 MEZ schrieb Mark Thomas <ma...@apache.org>:
>>> On 29/02/2020 11:23, Michael Osipov wrote:
>>>> Am 2020-02-29 um 12:13 schrieb Mark Thomas:
>>>>> On 29/02/2020 11:07, Michael Osipov wrote:
>>>>>> Am 2020-02-29 um 12:05 schrieb Mark Thomas:
>>>>>>> On 29/02/2020 10:40, Michael Osipov wrote:
>>>>>
>>>>> <snip/>
>>>>>
>>>>>>>> Tomcat does not support renegotiation of TLS contexts based
>>>>>>>> on URLs like HTTPd.
>>>>>>>
>>>>>>> Yes it does.
>>>>>>>
>>>>>>> If you specify CLIENT-CERT auth for a sub-set of URLs Tomcat will
>>>>>>> trigger a renegotiation when one of those URLs is requested.
>>>>>>>
>>>>>>> You don't have the same fine-grained control you have in httpd but
>>> you
>>>>>>> can replicate the typical use cases.
>>>>>>
>>>>>> Really? If I say require client cert auth on the connector, it will
>>> be
>>>>>> enforced even on those contexts which do not require
>>> authentication?!
>>>>>
>>>>> If you required auth on the connector it always applies.
>>>>>
>>>>> However, if you don't require it at the connector level you can
>>> require
>>>>> it for a subset of URLs with security constraints and Tomcat will
>>>>> trigger any required renegotiations.
>>>>
>>>> Mark,
>>>>
>>>> this makes me wonder whether Tomcat properly implements RFC 7540,
>>>> section 9.2.1 and RFC 8740, section 3. From my understanding the
>>>> configuration you have described MUST fail here.
>>>
>>> Those aspects of those specs are implemented correctly. Authentication
>>> will fail for both HTTP/2 and TLS 1.3 if a web application level
>>> security constraint tries to trigger renegotiation.
>>>
>>> For HTTP/2 and/or TLS 1/3 you can only configure client certificate
>>> authentication on the Connector.
>>
>> Hi,
>>
>> Oh, I didn't know that. Why exactly is that? Becaus of the multiplexing on http2 or something in tls1.3, or asked the oth way around, will it fail only for http2 && tls1.3 or for http2 || tls1.3
>
> For HTTP/2, yes because of the multiplexing. HTTP/2 explicitly prohibits
> renegotiation.
>
> For TLS 1.3 there is post handshake authentication but the JSSE
> implementation doesn't support that.
>
> However...
>
> If NIO/NIO2 is used with OpenSSL or if the APR/Native Connector is used
> then post-handshake authentication is supported for TLS 1.3 and
> CLIENT-CERT auth triggered by security constraints works as expected.
But I hope this only applies to HTTP/1.1, does it?
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Client cert auth on demand
Posted by Mark Thomas <ma...@apache.org>.
On 29/02/2020 13:05, Thomas Meyer wrote:
> Am 29. Februar 2020 13:10:13 MEZ schrieb Mark Thomas <ma...@apache.org>:
>> On 29/02/2020 11:23, Michael Osipov wrote:
>>> Am 2020-02-29 um 12:13 schrieb Mark Thomas:
>>>> On 29/02/2020 11:07, Michael Osipov wrote:
>>>>> Am 2020-02-29 um 12:05 schrieb Mark Thomas:
>>>>>> On 29/02/2020 10:40, Michael Osipov wrote:
>>>>
>>>> <snip/>
>>>>
>>>>>>> Tomcat does not support renegotiation of TLS contexts based
>>>>>>> on URLs like HTTPd.
>>>>>>
>>>>>> Yes it does.
>>>>>>
>>>>>> If you specify CLIENT-CERT auth for a sub-set of URLs Tomcat will
>>>>>> trigger a renegotiation when one of those URLs is requested.
>>>>>>
>>>>>> You don't have the same fine-grained control you have in httpd but
>> you
>>>>>> can replicate the typical use cases.
>>>>>
>>>>> Really? If I say require client cert auth on the connector, it will
>> be
>>>>> enforced even on those contexts which do not require
>> authentication?!
>>>>
>>>> If you required auth on the connector it always applies.
>>>>
>>>> However, if you don't require it at the connector level you can
>> require
>>>> it for a subset of URLs with security constraints and Tomcat will
>>>> trigger any required renegotiations.
>>>
>>> Mark,
>>>
>>> this makes me wonder whether Tomcat properly implements RFC 7540,
>>> section 9.2.1 and RFC 8740, section 3. From my understanding the
>>> configuration you have described MUST fail here.
>>
>> Those aspects of those specs are implemented correctly. Authentication
>> will fail for both HTTP/2 and TLS 1.3 if a web application level
>> security constraint tries to trigger renegotiation.
>>
>> For HTTP/2 and/or TLS 1/3 you can only configure client certificate
>> authentication on the Connector.
>
> Hi,
>
> Oh, I didn't know that. Why exactly is that? Becaus of the multiplexing on http2 or something in tls1.3, or asked the oth way around, will it fail only for http2 && tls1.3 or for http2 || tls1.3
For HTTP/2, yes because of the multiplexing. HTTP/2 explicitly prohibits
renegotiation.
For TLS 1.3 there is post handshake authentication but the JSSE
implementation doesn't support that.
However...
If NIO/NIO2 is used with OpenSSL or if the APR/Native Connector is used
then post-handshake authentication is supported for TLS 1.3 and
CLIENT-CERT auth triggered by security constraints works as expected.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Client cert auth on demand
Posted by Michael Osipov <mi...@apache.org>.
Am 2020-02-29 um 14:05 schrieb Thomas Meyer:
> Am 29. Februar 2020 13:10:13 MEZ schrieb Mark Thomas <ma...@apache.org>:
>> On 29/02/2020 11:23, Michael Osipov wrote:
>>> Am 2020-02-29 um 12:13 schrieb Mark Thomas:
>>>> On 29/02/2020 11:07, Michael Osipov wrote:
>>>>> Am 2020-02-29 um 12:05 schrieb Mark Thomas:
>>>>>> On 29/02/2020 10:40, Michael Osipov wrote:
>>>>
>>>> <snip/>
>>>>
>>>>>>> Tomcat does not support renegotiation of TLS contexts based
>>>>>>> on URLs like HTTPd.
>>>>>>
>>>>>> Yes it does.
>>>>>>
>>>>>> If you specify CLIENT-CERT auth for a sub-set of URLs Tomcat will
>>>>>> trigger a renegotiation when one of those URLs is requested.
>>>>>>
>>>>>> You don't have the same fine-grained control you have in httpd but
>> you
>>>>>> can replicate the typical use cases.
>>>>>
>>>>> Really? If I say require client cert auth on the connector, it will
>> be
>>>>> enforced even on those contexts which do not require
>> authentication?!
>>>>
>>>> If you required auth on the connector it always applies.
>>>>
>>>> However, if you don't require it at the connector level you can
>> require
>>>> it for a subset of URLs with security constraints and Tomcat will
>>>> trigger any required renegotiations.
>>>
>>> Mark,
>>>
>>> this makes me wonder whether Tomcat properly implements RFC 7540,
>>> section 9.2.1 and RFC 8740, section 3. From my understanding the
>>> configuration you have described MUST fail here.
>>
>> Those aspects of those specs are implemented correctly. Authentication
>> will fail for both HTTP/2 and TLS 1.3 if a web application level
>> security constraint tries to trigger renegotiation.
>>
>> For HTTP/2 and/or TLS 1/3 you can only configure client certificate
>> authentication on the Connector.
>
> Hi,
>
> Oh, I didn't know that. Why exactly is that? Becaus of the multiplexing on http2 or something in tls1.3, or asked the oth way around, will it fail only for http2 && tls1.3 or for http2 || tls1.3
I recently made some research on the toptic for work. As far as I
understand there is no renogotiation in TLS 1.3 anymore. It has been
replaced with PHA (post-handshake authentication). Because of, as you
properly noticed, parallel streams you'd suffer from race conditions if
one stream for a URL would request PHA and another won't.
Here is a very helpful read:
https://lists.w3.org/Archives/Public/ietf-http-wg/2019AprJun/0001.html
So doing
<Location /sfs>
VerifyClient require
</Location>
is unusable.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Client cert auth on demand
Posted by Thomas Meyer <th...@m3y3r.de>.
Am 29. Februar 2020 13:10:13 MEZ schrieb Mark Thomas <ma...@apache.org>:
>On 29/02/2020 11:23, Michael Osipov wrote:
>> Am 2020-02-29 um 12:13 schrieb Mark Thomas:
>>> On 29/02/2020 11:07, Michael Osipov wrote:
>>>> Am 2020-02-29 um 12:05 schrieb Mark Thomas:
>>>>> On 29/02/2020 10:40, Michael Osipov wrote:
>>>
>>> <snip/>
>>>
>>>>>> Tomcat does not support renegotiation of TLS contexts based
>>>>>> on URLs like HTTPd.
>>>>>
>>>>> Yes it does.
>>>>>
>>>>> If you specify CLIENT-CERT auth for a sub-set of URLs Tomcat will
>>>>> trigger a renegotiation when one of those URLs is requested.
>>>>>
>>>>> You don't have the same fine-grained control you have in httpd but
>you
>>>>> can replicate the typical use cases.
>>>>
>>>> Really? If I say require client cert auth on the connector, it will
>be
>>>> enforced even on those contexts which do not require
>authentication?!
>>>
>>> If you required auth on the connector it always applies.
>>>
>>> However, if you don't require it at the connector level you can
>require
>>> it for a subset of URLs with security constraints and Tomcat will
>>> trigger any required renegotiations.
>>
>> Mark,
>>
>> this makes me wonder whether Tomcat properly implements RFC 7540,
>> section 9.2.1 and RFC 8740, section 3. From my understanding the
>> configuration you have described MUST fail here.
>
>Those aspects of those specs are implemented correctly. Authentication
>will fail for both HTTP/2 and TLS 1.3 if a web application level
>security constraint tries to trigger renegotiation.
>
>For HTTP/2 and/or TLS 1/3 you can only configure client certificate
>authentication on the Connector.
Hi,
Oh, I didn't know that. Why exactly is that? Becaus of the multiplexing on http2 or something in tls1.3, or asked the oth way around, will it fail only for http2 && tls1.3 or for http2 || tls1.3
>
>Mark
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>For additional commands, e-mail: users-help@tomcat.apache.org
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Client cert auth on demand
Posted by Mark Thomas <ma...@apache.org>.
On 29/02/2020 11:23, Michael Osipov wrote:
> Am 2020-02-29 um 12:13 schrieb Mark Thomas:
>> On 29/02/2020 11:07, Michael Osipov wrote:
>>> Am 2020-02-29 um 12:05 schrieb Mark Thomas:
>>>> On 29/02/2020 10:40, Michael Osipov wrote:
>>
>> <snip/>
>>
>>>>> Tomcat does not support renegotiation of TLS contexts based
>>>>> on URLs like HTTPd.
>>>>
>>>> Yes it does.
>>>>
>>>> If you specify CLIENT-CERT auth for a sub-set of URLs Tomcat will
>>>> trigger a renegotiation when one of those URLs is requested.
>>>>
>>>> You don't have the same fine-grained control you have in httpd but you
>>>> can replicate the typical use cases.
>>>
>>> Really? If I say require client cert auth on the connector, it will be
>>> enforced even on those contexts which do not require authentication?!
>>
>> If you required auth on the connector it always applies.
>>
>> However, if you don't require it at the connector level you can require
>> it for a subset of URLs with security constraints and Tomcat will
>> trigger any required renegotiations.
>
> Mark,
>
> this makes me wonder whether Tomcat properly implements RFC 7540,
> section 9.2.1 and RFC 8740, section 3. From my understanding the
> configuration you have described MUST fail here.
Those aspects of those specs are implemented correctly. Authentication
will fail for both HTTP/2 and TLS 1.3 if a web application level
security constraint tries to trigger renegotiation.
For HTTP/2 and/or TLS 1/3 you can only configure client certificate
authentication on the Connector.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Client cert auth on demand
Posted by Michael Osipov <mi...@apache.org>.
Am 2020-02-29 um 12:13 schrieb Mark Thomas:
> On 29/02/2020 11:07, Michael Osipov wrote:
>> Am 2020-02-29 um 12:05 schrieb Mark Thomas:
>>> On 29/02/2020 10:40, Michael Osipov wrote:
>
> <snip/>
>
>>>> Tomcat does not support renegotiation of TLS contexts based
>>>> on URLs like HTTPd.
>>>
>>> Yes it does.
>>>
>>> If you specify CLIENT-CERT auth for a sub-set of URLs Tomcat will
>>> trigger a renegotiation when one of those URLs is requested.
>>>
>>> You don't have the same fine-grained control you have in httpd but you
>>> can replicate the typical use cases.
>>
>> Really? If I say require client cert auth on the connector, it will be
>> enforced even on those contexts which do not require authentication?!
>
> If you required auth on the connector it always applies.
>
> However, if you don't require it at the connector level you can require
> it for a subset of URLs with security constraints and Tomcat will
> trigger any required renegotiations.
Mark,
this makes me wonder whether Tomcat properly implements RFC 7540,
section 9.2.1 and RFC 8740, section 3. From my understanding the
configuration you have described MUST fail here.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Client cert auth on demand
Posted by Michael Osipov <mi...@apache.org>.
Am 2020-02-29 um 12:13 schrieb Mark Thomas:
> On 29/02/2020 11:07, Michael Osipov wrote:
>> Am 2020-02-29 um 12:05 schrieb Mark Thomas:
>>> On 29/02/2020 10:40, Michael Osipov wrote:
>
> <snip/>
>
>>>> Tomcat does not support renegotiation of TLS contexts based
>>>> on URLs like HTTPd.
>>>
>>> Yes it does.
>>>
>>> If you specify CLIENT-CERT auth for a sub-set of URLs Tomcat will
>>> trigger a renegotiation when one of those URLs is requested.
>>>
>>> You don't have the same fine-grained control you have in httpd but you
>>> can replicate the typical use cases.
>>
>> Really? If I say require client cert auth on the connector, it will be
>> enforced even on those contexts which do not require authentication?!
>
> If you required auth on the connector it always applies.
>
> However, if you don't require it at the connector level you can require
> it for a subset of URLs with security constraints and Tomcat will
> trigger any required renegotiations.
I wasn't aware of that. Thank you for the enlightment!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Client cert auth on demand
Posted by Mark Thomas <ma...@apache.org>.
On 29/02/2020 11:07, Michael Osipov wrote:
> Am 2020-02-29 um 12:05 schrieb Mark Thomas:
>> On 29/02/2020 10:40, Michael Osipov wrote:
<snip/>
>>> Tomcat does not support renegotiation of TLS contexts based
>>> on URLs like HTTPd.
>>
>> Yes it does.
>>
>> If you specify CLIENT-CERT auth for a sub-set of URLs Tomcat will
>> trigger a renegotiation when one of those URLs is requested.
>>
>> You don't have the same fine-grained control you have in httpd but you
>> can replicate the typical use cases.
>
> Really? If I say require client cert auth on the connector, it will be
> enforced even on those contexts which do not require authentication?!
If you required auth on the connector it always applies.
However, if you don't require it at the connector level you can require
it for a subset of URLs with security constraints and Tomcat will
trigger any required renegotiations.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Client cert auth on demand
Posted by Michael Osipov <mi...@apache.org>.
Am 2020-02-29 um 12:05 schrieb Mark Thomas:
> On 29/02/2020 10:40, Michael Osipov wrote:
>> Am 2020-02-29 um 10:09 schrieb Thomas Meyer:
>
> <snip/>
>
>>> Hi,
>>>
>>> Instead of configuring the container for client cert Auth change the
>>> webapp:
>>> 1) define a realm in local context.xml
>>> 2) add resp security constraint only for rest api calls
>>
>> This will not help.
>
> In this case that appears to be correct although it isn't generally correct.
>
>> You cannot configure cert-based auth from the
>> context.xml.
>
> True. You do that in web.xml.
>
>> Tomcat does not support renegotiation of TLS contexts based
>> on URLs like HTTPd.
>
> Yes it does.
>
> If you specify CLIENT-CERT auth for a sub-set of URLs Tomcat will
> trigger a renegotiation when one of those URLs is requested.
>
> You don't have the same fine-grained control you have in httpd but you
> can replicate the typical use cases.
Really? If I say require client cert auth on the connector, it will be
enforced even on those contexts which do not require authentication?!
M
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Client cert auth on demand
Posted by Mark Thomas <ma...@apache.org>.
On 29/02/2020 10:40, Michael Osipov wrote:
> Am 2020-02-29 um 10:09 schrieb Thomas Meyer:
<snip/>
>> Hi,
>>
>> Instead of configuring the container for client cert Auth change the
>> webapp:
>> 1) define a realm in local context.xml
>> 2) add resp security constraint only for rest api calls
>
> This will not help.
In this case that appears to be correct although it isn't generally correct.
> You cannot configure cert-based auth from the
> context.xml.
True. You do that in web.xml.
> Tomcat does not support renegotiation of TLS contexts based
> on URLs like HTTPd.
Yes it does.
If you specify CLIENT-CERT auth for a sub-set of URLs Tomcat will
trigger a renegotiation when one of those URLs is requested.
You don't have the same fine-grained control you have in httpd but you
can replicate the typical use cases.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Client cert auth on demand
Posted by Michael Osipov <mi...@apache.org>.
Am 2020-02-29 um 10:09 schrieb Thomas Meyer:
> Am 27. Februar 2020 10:58:01 MEZ schrieb "Martynas Jusevičius" <ma...@atomgraph.com>:
>> Hi list,
>>
>> I'm using a Docker image based on tomcat:8.0-jre8. It serves as an
>> end-user facing webapp but also as a REST API which authenticates
>> using client certificates. The same URLs serve both purposes, however
>> only administrators are using the API.
>>
>> The Connector is configured using clientAuth="want".
>> This works fine with API calls which are run from shell scripts.
>> In the browser however it prompts a certificate selection (if there
>> are any client certs). This would not be a problem if the webapp would
>> not be user-facing, but since it is the certificate prompt can be
>> confusing to many users and increase our bounce rate.
>>
>> I'm looking for some workaround that would not require changing the
>> whole design. For example asking for the client cert only when a
>> certain flag is set, such as a query param or request header.
>> Or somehow not asking for it but still accepting it :) But I guess
>> that's not how TLS works...
>>
>> Any ideas? Thanks.
>>
>>
>> Martynas
>> atomgraph.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>
> Hi,
>
> Instead of configuring the container for client cert Auth change the webapp:
> 1) define a realm in local context.xml
> 2) add resp security constraint only for rest api calls
This will not help. You cannot configure cert-based auth from the
context.xml. Tomcat does not support renegotiation of TLS contexts based
on URLs like HTTPd.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Client cert auth on demand
Posted by Thomas Meyer <th...@m3y3r.de>.
Am 27. Februar 2020 10:58:01 MEZ schrieb "Martynas Jusevičius" <ma...@atomgraph.com>:
>Hi list,
>
>I'm using a Docker image based on tomcat:8.0-jre8. It serves as an
>end-user facing webapp but also as a REST API which authenticates
>using client certificates. The same URLs serve both purposes, however
>only administrators are using the API.
>
>The Connector is configured using clientAuth="want".
>This works fine with API calls which are run from shell scripts.
>In the browser however it prompts a certificate selection (if there
>are any client certs). This would not be a problem if the webapp would
>not be user-facing, but since it is the certificate prompt can be
>confusing to many users and increase our bounce rate.
>
>I'm looking for some workaround that would not require changing the
>whole design. For example asking for the client cert only when a
>certain flag is set, such as a query param or request header.
>Or somehow not asking for it but still accepting it :) But I guess
>that's not how TLS works...
>
>Any ideas? Thanks.
>
>
>Martynas
>atomgraph.com
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>For additional commands, e-mail: users-help@tomcat.apache.org
Hi,
Instead of configuring the container for client cert Auth change the webapp:
1) define a realm in local context.xml
2) add resp security constraint only for rest api calls
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org