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-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

Reply via email to