Protecting against Direct Access

Because security.manager provides security for services using the Web Security Service, it is important to ensure that the possibility of directly accessing the service, for example via internet, is blocked. One way of doing this is to restrict access via the IP address.

Microsoft Internet Information Services (IIS)

With Microsoft Internet Information Services (IIS), this is performed as follows:

  • Open the IIS Manager (via the system management).

  • Select the web folder through which the service to be protected is accessible (for example 'ArcGIS' for ArcGIS Server services). Right click the folder to open the properties.

  • In the Properties window, select the Folder Security tab and click Edit located below Restrictions for IP Addresses and Domain Names.

  • Select the default option Deny Access and enter the IP address of the server running the WSS under Exception. If both services are installed on the same machine, it is also possible to use the local IP address 127.0.0.1.

  • Click OK three times to confirm.

The secured service can now be accessed from the explicitly defined IP address only. Access is blocked to all other users.

Tomcat Application Server

In Apache Tomcat access to certain web contexts can be restricted to particular IP addresses or hostnames, using so-called valves. To do this, open the file containing the context element of the web application to be protected. A valve element is then added to the context element of the web application, resulting in two different implementations: one permitting the specification of restrictions to particular hosts on the basis of hostnames, and one for using IP addresses.

Example of a Context with restricted access:

<Context path="/gateway" ...>
...
<Valve className="org.apache.catalina.valves.RemoteHostValve" allow="*.mycompany.com,www.yourcompany.com"/>
<Valve className="org.apache.catalina.valves.RemoteAddrValve" deny="192.168.1.*"/>
...
</Context>

Both of these possibilities (hostname or IP address) permit allowed hosts (allow attribute) and denied hosts (deny attribute) to be given. If the allow attribute is used, only those hosts are allowed that are listed in the attribute. If the attribute does not exist, all requests are permitted unless the deny attribute exists containing the respective host. If the deny attribute exists, the respective host must not be listed to make access possible. If this attribute does not exist, access is controlled by the allow attribute.
(Source: https://tomcat.apache.org/tomcat-9.0-doc/config/filter.html#Remote_Host_Filter)