Re: making security constraints configureable
Hello Terence, the System property would be indeed the easiest way, unfortunately I wouldn't know that the descriptive security in web.xml supports scripting with environment variables. If it does, it would solve all the problems ;-) regards Leon 2011/11/8 Terence M. Bandoian tere...@tmbsw.com: On 1:59 PM, André Warnier wrote: Terence M. Bandoian wrote: On 1:59 PM, Konstantin Kolinko wrote: 2011/11/3 Leon Rosenbergrosenberg.l...@gmail.com: 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. Put it behind Apache HTTPD (or any other proxy) and let HTTPD handle authentication authorization instead of Tomcat. I'd advise against using BASIC auth in public internet, unless the channel is protected with HTTPS. What we did so far was, that we excluded everyone via web.xml: You can automate the above. If you pack your war file using Ant, you can usereplaceregexp task. Best regards, Konstantin Kolinko I'm not sure what open for public means above. What about using a system property (e.g. myorg.myapp.isStagingEnv=true) in a filter or valve to accept or reject requests? If I (belatedly) understand the requirements properly, Leon does not not want to reject /all/ requests (that, he could do by undeploying the application). It is more something like this : - requests originating from a range of IP addresses (e.g. the internal LAN) should be accepted, without authentication - requests originating from anywhere else should be submitted to authentication. Practical case : the application is in a testing state, and should not be available to the public at large, only to inside testers. The inside testers should not have to login for that. However, occasionally, someone may be sitting in an Internet Cafe and want to do a demo for a customer from there. He should be able to access the application, but only after logging in. Leon, if the above is not the right description, please correct it. In such matters, the devil is in the details. The system property that indicates whether or not the application is in a staging or test environment would be used in conjunction with a test against, for example, request.getRemoteUser() or request.isUserInRole() or request.getRemoteAddr(). -Terence Bandoian - 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
Re: making security constraints configureable
Hello Andre, sorry for the late response. Putting a httpd or lightttpd or nginx in front of our staging tomcat came to our mind too. The problem with this approach is however, that it reduces the idea of having a staging environment to absurdity, at least in technical sense, because its not similar to the production environment anymore. In this setup we couldn't make any reliable loadtesting against preproduction/staging, because its simple not the same as production ;-) But thanx nevertheless ;-) regards Leon On Mon, Nov 7, 2011 at 4:19 PM, André Warnier a...@ice-sa.com wrote: @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 authentication. 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 dmik...@vmware.com 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? https://tomcat.apache.org/tomcat-6.0-doc/config/valve.html#Remote_Address_Filter 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-methodBASIC/auth-method /login-config security-role role-namemy-access/role-name /security-role security-constraint display-nameblub/display-name web-resource-collection web-resource-namemyres/web-resource-name url-pattern*.html/url-pattern /web-resource-collection auth-constraint role-namemy-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: 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: making security constraints configureable
Leon Rosenberg wrote: Hello Andre, sorry for the late response. Putting a httpd or lightttpd or nginx in front of our staging tomcat came to our mind too. The problem with this approach is however, that it reduces the idea of having a staging environment to absurdity, at least in technical sense, because its not similar to the production environment anymore. In this setup we couldn't make any reliable loadtesting against preproduction/staging, because its simple not the same as production ;-) Response 1 : Well then, put the front-end server also in front of the production system. That'll make them comparable again. :-) Not only a jest : the impact, performance-wise, is likely to be minimal expect in the most extreme cases. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: making security constraints configureable
Leon Rosenberg wrote: Hello Andre, sorry for the late response. Putting a httpd or lightttpd or nginx in front of our staging tomcat came to our mind too. The problem with this approach is however, that it reduces the idea of having a staging environment to absurdity, at least in technical sense, because its not similar to the production environment anymore. In this setup we couldn't make any reliable loadtesting against preproduction/staging, because its simple not the same as production ;-) Response 2 : Taking into account your various requirements, and if you do not want a front-end, then I think that the only practical solution would be to switch from container-driven AAA (in web.xml), to servlet-filter based AAA, and create your own servlet filter for ditto. This servlet filter would then be present inside both your production and staging app, thus be part of your normal deployment. Only, some run-time parameter would either enable or disable its AAA function according to where it's used. One problem is that you'd have to write your own servlet filter for that, because I can't think off-hand of an existing one which does all that you need. The closest may be the SecurityFilter (http://securityfilter.sourceforge.net/), code of which you could modify to add client IP discrimination e.g. (and an on-off switch). Or maybe combine that one with the UrlRewriteFilter (www.tuckey.org). Both together may come close to what you need. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: making security constraints configureable
This thread is quite long, but to sum up what I have understood 1) you have an application running on staging and production 2) you want to enable access to staging for public demos from anywhere on the internet - for this you want to add access controls 3) everyone else will access the application on an intranet with no access controls, e.g. no security constraints Also you weren't happy with the suggestion of placing apache httpd infront as this would make staging different from production. Assuming the above is a fair summation of 15 emails, then - Why don't you expose tomcat via say port 80 and have no security enabled. This is what people use to access the production environment, and probably how you have things configured currently - For the staging server, configure exactly the same way for intranet access - For internet access have your firewall route through to a different port, which apache http listens on. Then add security to apache, and if they make it past the security forward the requests to the tomcat instance via say ajp. This won't give a 100% affinity in the cyber cafe for exactly what people will experience in production due to the extra steps. However it will be pretty close and this satisfies your security requirements. Also satisfies your load testing requirements - you load test on staging against the internal port - FWIW to me staging is where you test the roll out scripts - you shouldn't let anybody on it, and certainly not be doing any performance testing on it. I think I would call the environment you describe UAT - As already mentioned, if this doesn't work for you then the only other viable alternative that springs to mind is to add a filter that allows you to configure the security constraint on and off per installation. Anyway hope that helps Chris
Re: making security constraints configureable
On 1:59 PM, André Warnier wrote: Terence M. Bandoian wrote: On 1:59 PM, Konstantin Kolinko wrote: 2011/11/3 Leon Rosenbergrosenberg.l...@gmail.com: 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. Put it behind Apache HTTPD (or any other proxy) and let HTTPD handle authentication authorization instead of Tomcat. I'd advise against using BASIC auth in public internet, unless the channel is protected with HTTPS. What we did so far was, that we excluded everyone via web.xml: You can automate the above. If you pack your war file using Ant, you can usereplaceregexp task. Best regards, Konstantin Kolinko I'm not sure what open for public means above. What about using a system property (e.g. myorg.myapp.isStagingEnv=true) in a filter or valve to accept or reject requests? If I (belatedly) understand the requirements properly, Leon does not not want to reject /all/ requests (that, he could do by undeploying the application). It is more something like this : - requests originating from a range of IP addresses (e.g. the internal LAN) should be accepted, without authentication - requests originating from anywhere else should be submitted to authentication. Practical case : the application is in a testing state, and should not be available to the public at large, only to inside testers. The inside testers should not have to login for that. However, occasionally, someone may be sitting in an Internet Cafe and want to do a demo for a customer from there. He should be able to access the application, but only after logging in. Leon, if the above is not the right description, please correct it. In such matters, the devil is in the details. The system property that indicates whether or not the application is in a staging or test environment would be used in conjunction with a test against, for example, request.getRemoteUser() or request.isUserInRole() or request.getRemoteAddr(). -Terence Bandoian - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: making security constraints configureable
Hello Konstantin, On Mon, Nov 7, 2011 at 4:30 AM, Konstantin Kolinko knst.koli...@gmail.com wrote: 2011/11/3 Leon Rosenberg rosenberg.l...@gmail.com: 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. Put it behind Apache HTTPD (or any other proxy) and let HTTPD handle authentication authorization instead of Tomcat. That would be the last and least acceptable choice... I'd advise against using BASIC auth in public internet, unless the channel is protected with HTTPS. What we did so far was, that we excluded everyone via web.xml: You can automate the above. If you pack your war file using Ant, you can use replaceregexp task. This doesn't work, cause we use exactly the same war in prod and preprod. But thanx for suggestions anyway! thanx Leon Best regards, Konstantin Kolinko - 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
Re: making security constraints configureable
Leon Rosenberg wrote: Hello Konstantin, On Mon, Nov 7, 2011 at 4:30 AM, Konstantin Kolinko knst.koli...@gmail.com wrote: 2011/11/3 Leon Rosenberg rosenberg.l...@gmail.com: 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. Put it behind Apache HTTPD (or any other proxy) and let HTTPD handle authentication authorization instead of Tomcat. That would be the last and least acceptable choice... I'd advise against using BASIC auth in public internet, unless the channel is protected with HTTPS. What we did so far was, that we excluded everyone via web.xml: You can automate the above. If you pack your war file using Ant, you can use replaceregexp task. This doesn't work, cause we use exactly the same war in prod and preprod. But thanx for suggestions anyway! What kind of user authentication is being used in the background ? And how many authenticated users can there be ? If there are not that many, the idea : in your auth constraints, specify that the application is accessible by the role myapp. Then depending on who should be able to access at any particular time, update your users database to only give this role to whoever can access at that time, and not to the others. If some users can access this all the time, then add another role to the auth-constraints (e.g. testers), and add this role only to the permanent users. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: making security constraints configureable
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 dmik...@vmware.com 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? https://tomcat.apache.org/tomcat-6.0-doc/config/valve.html#Remote_Address_Filter 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-methodBASIC/auth-method /login-config security-role role-namemy-access/role-name /security-role security-constraint display-nameblub/display-name web-resource-collection web-resource-namemyres/web-resource-name url-pattern*.html/url-pattern /web-resource-collection auth-constraint role-namemy-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: 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
Re: making security constraints configureable
@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 myhost.mycompany.com as 127.0.0.1, 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 authentication. 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 dmik...@vmware.com 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? https://tomcat.apache.org/tomcat-6.0-doc/config/valve.html#Remote_Address_Filter 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-methodBASIC/auth-method /login-config security-role role-namemy-access/role-name /security-role security-constraint display-nameblub/display-name web-resource-collection web-resource-namemyres/web-resource-name url-pattern*.html/url-pattern /web-resource-collection auth-constraint role-namemy-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: 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
Re: making security constraints configureable
On 1:59 PM, Konstantin Kolinko wrote: 2011/11/3 Leon Rosenbergrosenberg.l...@gmail.com: 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. Put it behind Apache HTTPD (or any other proxy) and let HTTPD handle authentication authorization instead of Tomcat. I'd advise against using BASIC auth in public internet, unless the channel is protected with HTTPS. What we did so far was, that we excluded everyone via web.xml: You can automate the above. If you pack your war file using Ant, you can usereplaceregexp task. Best regards, Konstantin Kolinko I'm not sure what open for public means above. What about using a system property (e.g. myorg.myapp.isStagingEnv=true) in a filter or valve to accept or reject requests? -Terence Bandoian - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: making security constraints configureable
Terence M. Bandoian wrote: On 1:59 PM, Konstantin Kolinko wrote: 2011/11/3 Leon Rosenbergrosenberg.l...@gmail.com: 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. Put it behind Apache HTTPD (or any other proxy) and let HTTPD handle authentication authorization instead of Tomcat. I'd advise against using BASIC auth in public internet, unless the channel is protected with HTTPS. What we did so far was, that we excluded everyone via web.xml: You can automate the above. If you pack your war file using Ant, you can usereplaceregexp task. Best regards, Konstantin Kolinko I'm not sure what open for public means above. What about using a system property (e.g. myorg.myapp.isStagingEnv=true) in a filter or valve to accept or reject requests? If I (belatedly) understand the requirements properly, Leon does not not want to reject /all/ requests (that, he could do by undeploying the application). It is more something like this : - requests originating from a range of IP addresses (e.g. the internal LAN) should be accepted, without authentication - requests originating from anywhere else should be submitted to authentication. Practical case : the application is in a testing state, and should not be available to the public at large, only to inside testers. The inside testers should not have to login for that. However, occasionally, someone may be sitting in an Internet Cafe and want to do a demo for a customer from there. He should be able to access the application, but only after logging in. Leon, if the above is not the right description, please correct it. In such matters, the devil is in the details. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: making security constraints configureable
2011/11/3 Leon Rosenberg rosenberg.l...@gmail.com: 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. Put it behind Apache HTTPD (or any other proxy) and let HTTPD handle authentication authorization instead of Tomcat. I'd advise against using BASIC auth in public internet, unless the channel is protected with HTTPS. What we did so far was, that we excluded everyone via web.xml: You can automate the above. If you pack your war file using Ant, you can use replaceregexp task. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: making security constraints configureable
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 dmik...@vmware.com 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? https://tomcat.apache.org/tomcat-6.0-doc/config/valve.html#Remote_Address_Filter 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-methodBASIC/auth-method /login-config security-role role-namemy-access/role-name /security-role security-constraint display-nameblub/display-name web-resource-collection web-resource-namemyres/web-resource-name url-pattern*.html/url-pattern /web-resource-collection auth-constraint role-namemy-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: 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
Re: making security constraints configureable
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? https://tomcat.apache.org/tomcat-6.0-doc/config/valve.html#Remote_Address_Filter 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-methodBASIC/auth-method /login-config security-role role-namemy-access/role-name /security-role security-constraint display-nameblub/display-name web-resource-collection web-resource-namemyres/web-resource-name url-pattern*.html/url-pattern /web-resource-collection auth-constraint role-namemy-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: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
