Tomcat - Basic access authentication

[Merlin Jones]

Hello,

I am trying to restrict access to Tomcat applications on a server to specific users, without being prompt for username and password.
However, all the attempts  using basic authentication led me to : 1 - either restrict the access not just to the applications, but to the manager page as well (when I made the amendment on server.xml); 2 - or restrict the applications (by amending the context.xml).
The first outcome is not ideal as I need only the applications to be restricted, the second outcome requires extra checks once a deployment happens as the context.xml is going to  be replaced as part of the process (and it is also not ideal to have credentials saved in the code).

Any suggestion on using a token authentication between the servers/users to access the applications running on a Tomcat server?

Thanks in advance.

[Tim Holloway]

Welcome to the Ranch, Merlin!

How do you propose to limit access to "authorized users" if you do not know who the user (userid) is?  

There are a number of authentication mechanisms available, but knowing who is who is pretty much essential to all of them, and especially if different users have different privileges.

[Merlin Jones]

Hello Tim,

Thanks a lot for the welcome greetings and for replying to my very first post!  

You are right, I should have explained better who the users are.
I want to limit access to specific servers, say only server A,B,C will have access granted to the web applications running on my Tomcat server.
The reason why I would like to avoid user/password prompt is because the request to access the content comes from a servers ('the users'), instead of a 'real user'.
So I have attempted to restrict the access by IP only, and got stuck on restrict access not just to the applications, but to the manager page as well.
I am searching now the possibility of passing the 'credentials/token' of the servers that I want to grant access to the applications via the https parameters, but still no success.  

Merlin

[Ron McLeod]

If you strictly need to control access based on IP address, then I would use iptables or firewalld so that only authorized endpoints ever reach the server.

If you need control based on additional factors such as request URI, I would also/instead use nginx or httpd as a reverse proxy.  Using a reverse proxy can provide additional benefits such as:
  - security gateway to offload TLS processing from backend servers
  - load balancer to distribute to multiple server instances
  - rate limiter to help reduce DOS
  - in the case of a microservice architecture act as a service router to forward the requests to the responsible microservices

In addition, I would use JWT or some other token mechanism and use the roles/groups claims to control access to individual services/methods.

[Tim Holloway]

First, let me second Ron's advocacy for fronting Tomcat with a reverse proxy. In addition to the reasons he gave, there's one more very important one: Tomcat cannot listen on ports 80 and 443 safely, but a reverse proxy can.

To filter requests based on whether they are internal or external, you have 2 options. One is to use a reverse proxy and forbid the internal URLs from external servers. You'd probably just want to forbid them entirely in the proxy and have the internal servers talk to Tomcat directly. Most firewalls cannot filter by URL, and as mentioned, a reverse proxy is a useful thing to have in general.

The other option does require assigning user IDs to the internal servers. I'm assuming based on what I've heard that all external users are going to be anonymous. To avoid a password challenge, however, you can configure Tomcat to authenticate via client certificate. This is a relatively rare but useful option where you create security certs for each client machine and pair them with credentials registered with Tomcat.Be warned, though, that if the client machine goes down and gets swapped out, the swapped-in machine is going to have to have a valid cert!

A further note when using user IDs. Don't log in the same user ID from multiple machines! Tomcat will not like it and you may have corruption in your session-scope variables if you have any, plus possible cookie conflicts. Give each client a unique ID.

[Merlin Jones]

Hello again.
Thanks for the replies to this post.
I believe the information I have provided was not clear enough.

The tomcat servers are only accessible via internal network. However, what I am trying to achieve is to restrict the access to the applications (e.g. {$CATALINA_HOME}/webapps) to 2 specific servers. So, any request to the applications should be served only if coming from server A and B.
Servers A and B work as load balance for my tomcat servers. Saying that, the work I need to do is at tomcat servers. I need to find a way where the tomcats will be open to access the manager page (requesting the login details) to any user (admins and devs have access to the login details), but only reply to webapp requests IF coming from server A and B.

In the tomcat9 docs, I found some options such as add 'Valve className="org.apache.catalina.valves.RemoteAddrValve' and specify what ips are allowed (this in the server.xml file), however this also restrict the access to the manager page. I have also information there saying that, even having the 'valve' added to server.xml file, any other configuration applied at context.xml (on application level) would supersede the top level config (in this way, more granular).
But this is not the case. I must be missing something... Any suggestion/idea is much appreciated.

Ta

[Tim Holloway]

I think you've got your ideas of clients and servers fuzzed there.

Tomcat is a webapp server. It accepts requests from web clients. Those clients may be running as applications on other server machines, but regardless, from Tomcat's point of view, only Tomcat is the server when web requests come in. Tomcat doesn't care if the request comes from a user's desktop, an Internet of Things device (I actually do a lot of that!) or another machine that itself hosts webapp servers. And, of course, using web services, it's not uncommon for a web request to come into one server, and the web application in that server make requests to backend servers running Tomcat and/or other webapp server programs. We can put load-balancers and reverse-proxy servers in front of Tomcat as well. They are clients for Tomcat, too.

OK. Hope that makes sense. Now if you want to restrict which clients can access stuff on your Tomcat server, you have 2 primary choices. One is via a user identity and the other is by blocking everything at the network level. Often we'll do a little of both.

Using a user login on a Tomcat webapp allows you to establish a security session and you can use this session to allow access only to certain URLs served by the Tomcat server. So, for example, my client may no be allowed to access URLs whose resource path is /admin unless I've granted an admin role to that userid.

Blocking at the network level is usually all-or-nothing for the source IP address. You CAN use a Tomcat Valve  to limit what IPs Tomcat will listen to, but it's usually easier to employ the firewall of the machine that Tomcat's running in. Changing a Tomcat Valve requires modifying the basic Tomcat configuration, which requires restarting Tomcat. And should only be done by people who understand Tomcat. Filtering via OS firewall, on the other hand, is a standard sysadmin task and does not require stopping and restarting Tomcat. Also incoming requests are blocked well upstream of Tomcat, which reduces the amount of mayhem that Bad Packets could exploit security weaknesses downstream.

There's also another option, rarely used, where you assign client security certficates and define corresponding keys in your Tomcat server. Doing this eliminates the need for an explicit login and password, but it's best used for permanent internal client machines. The problem with client certs is that 1) if the client machine gets stolen, so does the cert and the thief can happily chat to your Tomcat server, subject only to firewall restrictions. The other problem is that if the client machine breaks down and has to be swapped out, you have to ensure that the replacement has its own security cert installed.