tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Restrict incoming connections per Application Tomcat 6.0.37
Date Sat, 14 Dec 2013 22:08:09 GMT
I'm going to try to explain myself better.

What I'm trying to do is create a permission system in Tomcat. This
permission system must allow or avoid the next connections:
- Receive from IP. The application with this permission only can accept
connections (or receive information) from an IP. It can't send anything or
connect to anywhere.
- Receive All. The application with this permission can accept connections
(or receive information) from any IP. It can't send anything or connect to
- Send and Receive IP. The application with this permission can accept
connection and connect to an IP.
- Send to IP.  The application with this permission only can connect or
send information to an IP. It can't receive information or accept
connections from anywhere.
- Send to All. The application with this permission can connect or send
information to any IP. It can't receive information or accept connections
from anywhere.

 With the SocketPermission, I can avoid that one application connects to an
specific IP or any IP (not granting SocketPermission "connect"). But if I
try to avoid that one IP connects to the application (not granting
SocketPermission "accept"), it doesn't restrict all connections. For
example, I can connect to the application from a browser in another host.
(I'm using the Security Manager in a correct way because it works with
others permissions).

If I add  <Valve className="org.apache.catalina.valves.RemoteHostValve"
allow="localhost"/> to the context.xml, I can restrict the previous
example, but with this I restrict all connections, so it doesn't allow me
to do what I want.

If I combine the SocketPermission with the RemoteHostValve I can grant the
first three permissions (or connections) in my list above. But I need to
restrict the incoming connections (accept connections) to grant the last

Any idea?

Thank you very much!


2013/12/14 Christopher Schultz <>

> Hash: SHA256
> Analía,
> On 12/14/13, 1:27 PM, ANALIA DE PEDRO SANTAMARIA wrote:
> > I'm developing a permission system in Tomcat and I would like to
> > restrict incoming connections per application. I mean, I want to
> > restrict incoming connections in some applications and permit them
> > in others.
> So you want one application to disallow all connections, but others
> can receive incoming requests? Why not just un-deploy the application
> you don't want to be accessible?
> > I have tried to do it with the Security Manager (SocketPermission),
> > but it doesn't restrict all incoming connections.
> Really? You must have done it incorrectly, because disabling
> SocketPermission should have prevented Tomcat from binding to the port
> in the first place. No connection would be possible at all. Note that
> you need to enable a SecurityManager in order to use SockerPermission,
> and that Tomcat's default security configuration is to allow the
> appropriate SocketPermissions, so you'd have to seriously damage your
> Tomcat installation in order to do that. I don't recommend it.
> > And also I have tried with RemoteAddrValve and RemoteHostValve
> > (<Context>) but it restricts all connections, not only the
> > incoming ones.
> What other kinds of connections are there, other than incoming ones?
> > I have been searching other way to do that but I couldn't find
> > anything.
> You haven't really described what you want to accomplish. "Restrict
> incoming connections per application" could mean a range of things. Do
> you want to prohibit certain connections (e.g. non-localhost),
> throttle connection rates, or require authentication for certain
> applications?
> - -chris
> Version: GnuPG v1.4.15 (Darwin)
> Comment: GPGTools -
> Comment: Using GnuPG with Thunderbird -
> +ldnboUFOvvbwQ2zgd8N0Cv2WAcdNtHmvPoM/0gPC3zdvK0YClN1ojsKyGi6N7P4
> eua18+A8z926xIDfx9OseQkiLlnHuK7JTcJHDeDCPQFYuV+qyTksHUWOrzXBNeXv
> munO0myFGafTwXHInx2Jx/nKpjQncn6Tt6yFftbDdIpA65dwd4TfmmVh2IHzIEfL
> IPRVy9E1AB++HeH7MUhfptqONlmZ8iRC5+sauQCd9W/BjK+D9K+6AWi/TLl2N1Ek
> GlphJesttrtbkaoGzUw69ow5mxYZCAdHjRBgHK+doh3IoWfoDdPlpIP0nLWcv+dA
> PRbXzcpazzV7F9FsekpGJM1sC1fKnPG/C6t3WC1Lb3LHYo5TBPRRA2xUUig7LRk5
> g4lCL8h9dVBHwJtKLrmD5+z1wWLgs6J5Bty2lTZU05+zPQ54XNzk4O/He39UJmTn
> ACWi3xqr51Tx9E8oD9t3BlcjUxzbskFk3FhozVLG+zOSjxJVzspB3+8n7kZzciW5
> 0VTCFkX9/AGEW7TdYDp4MusSYYfZNkZuxN2/XQo5TnwPJjrvaW0dz56cMURWFaKO
> PTGgcXg1yLU4Qb4P6EdOxLcLv6dC3mF37X7fO5VGMOvg8rcPvbR8blF+zgmFimcT
> kiAUjXjwF8VrUPc8EFft
> =/585
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message