tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: making security constraints configureable
Date Mon, 07 Nov 2011 15:19:21 GMT
@Leon : I think I misunderstood your requirement, so disregard my previous response.

@Dan :  an SSH tunnel for HTTP is a (mild) pain, because of the hostname.  To make it 
work, you need to add an entry to your local hosts file (I assume a laptop), so that it 
resolves "" as, to connect to the local side of the tunnel.

@Leon (trying to do better this time) : I presume that you have a separate Tomcat server 
(or instance) for staging. If so, the easiest solution would be to leave the production 
one as it is, and your app as it is, and put an apache httpd front-end before only the 
staging Tomcat, and only for external accesses. The filtering/authentication would happen

on the front-end, and it would only pass the external requests to the back-end staging 
Tomcat if the access conditions are met.
Internal accesses can still go to the staging Tomcat directly, and access the app without

That should be easy to set up, easy being a function of how easily you can set up this 
Apache front-end with a separate hostname on the Internet, and allow it to proxy-pass 
requests to your internal Tomcat staging server.
As you probably do not have a plethora of external staging user-ids, the type of 
authentication setup could be very simple (basic auth, file-based). If basic auth is too 
insecure, you can run the browser/front-end part over HTTPS, still without changing 
anything on Tomcat.

Daniel Mikusa wrote:
> Leon,
> One possible way to work around this would be to use an SSH tunnel or a
> VPN (like OpenVPN) to access your network from the remote locations.
> Dan
> On Sat, 2011-11-05 at 08:53 -0700, Leon Rosenberg wrote:
>> Hello Daniel,
>> I can't use IP-Adresses, because it is possible that we show the
>> preproduction system in a starbucks to some customers for user testing
>> purposes.
>> I have no means to know which adresses are allowed and which not.
>> regards
>> Leon
>> On Thu, Nov 3, 2011 at 7:09 PM, Daniel Mikusa <> wrote:
>>> Leon,
>>> Is it a requirement for you to use BASIC auth?  or could you use
>>> something like the Remote Address Filter to restrict by IP address?
>>> If you configure this valve in the restricted environment you can then
>>> control who can access to just that environment.
>>> Dan
>>> On Thu, 2011-11-03 at 10:10 -0700, Leon Rosenberg wrote:
>>>> Hello,
>>>> I have a situation where an application is accessable from outside in
>>>> staging and production environment, but shouldn't be open for public
>>>> in staging environment.
>>>> What we did so far was, that we excluded everyone via web.xml:
>>>>         <!-- security configuration -->
>>>>         <login-config>
>>>>                 <auth-method>BASIC</auth-method>
>>>>         </login-config>
>>>>         <security-role>
>>>>                 <role-name>my-access</role-name>
>>>>         </security-role>
>>>>         <security-constraint>
>>>>                 <display-name>blub</display-name>
>>>>                 <web-resource-collection>
>>>>                         <web-resource-name>myres</web-resource-name>
>>>>                         <url-pattern>*.html</url-pattern>
>>>>                 </web-resource-collection>
>>>>                 <auth-constraint>
>>>>                         <role-name>my-access</role-name>
>>>>                 </auth-constraint>
>>>>         </security-constraint>
>>>>         <!-- /security configuration -->
>>>> Is there any possibility to make this conditional, depending on an
>>>> environment property? Is there any other opportunity to achieve the
>>>> same?
>>>> Currently we have to kill the above lines from web.xml after each
>>>> deployment and this sucks ;-(
>>>> regards
>>>> Leon
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message