In this case, our client had dynamic IPs. That is, their IP was always changing and the above solution wouldn't work. In other workplaces, this problem was typically solved using VPN, however the network admins didn't support this at the time.
I did not want to build a custom authentication mechanism at the application level just for testing purposes. That would mean changing the behaviour of my application just for testing! GAH!
Instead I applied a login-based security mechanism at the Tomcat level as follows.
In my web.xml file of the web application I added the following:
<!-- Define a Security Constraint on this Application --> <security-constraint> <web-resource-collection> <web-resource-name>Block access to entire application</web-resource-name> <url-pattern>/*</url-pattern> </web-resource-collection> <auth-constraint> <!-- NOTE: This role is not present in the default users file --> <role-name>zebrafish</role-name> </auth-constraint> </security-constraint> <!-- Define the Login Configuration for this Application --> <login-config> <auth-method>BASIC</auth-method> <realm-name>Zebrafish</realm-name> </login-config> <!-- Security roles referenced by this web application --> <security-role> <description> The role that is required to log in to the Zebrafish Application </description> <role-name>zebrafish</role-name> </security-role>
And in the /conf/tomcat-users.xml I added a new user and role as follows:
<user username="philip" password="philip" roles="zebrafish"/>
Upon application redeployment and server restart, any access to the web application requires authentication via a popup dialog and once we go to production, it is very easy to disable.