Deployment Patterns for Exposing ArcGIS Enterprise Secured Services to External Users

[NoahMayer]

• Introduction
• DMZ Reverse Proxy
• Special Security Constraints
• No Unauthenticated Access to the Internal Network
• No HTTPS Access / Only Database Access is Allowed from the DMZ to the Internal Network
• No Inbound Access from the DMZ to the Internal Network
• Security Architecture Patterns
• DMZ ArcGIS Enterprise Portal and Registered Services
• Internal Replicated Geodatabase
• Service Publication and Collaboration
• Restrict External Applications Access to ArcGIS Enterprise
• ArcGIS Online Proxy
• Server Proxy

Introduction

Security plays a big part in the enterprise architecture design process. Security policies vary between organizations, and different deployment patterns are required to meet those requirements and constraints. In this post I will try to address some of the more common security constraints, and suggest deployment patterns to satisfy them.

This is by no means an exhaustive list of all available security requirements and security architecture patterns.

This post will focus on architecture patterns to expose ArcGIS Enterprise secured resources to external clients, i.e. systems with the requirement to be accessed outside of the organization internal network, via a DMZ, e.g. to support field workers access without a VPN.

There are additional considerations that play part in the decision on which pattern to use, which this post is not going to cover, such as how many resources, e.g. hardware, licensing, and staff, will be required for each pattern.

In order to simplify and focus on the security aspect of the architecture pattern, all architectures in this post are not highly available, but each can be adjusted to a highly available architecture without changing the pattern.

DMZ Reverse Proxy

Let’s begin with the most common external facing ArcGIS Enterprise system deployment pattern, using a reverse proxy in the DMZ.

Figure 1 - DMZ Reverse Proxy

In this pattern, all ArcGIS Enterprise components are hosted in the internal network, behind the firewall, and a reverse proxy (this can be a commercial reverse proxy, such as F5 or NetScaler, open-source reverse proxy such as Nginx or HAProxy, or a second set of ArcGIS Web Adaptors), is deployed in the DMZ, and passes external requests to ArcGIS Enterprise.

ArcGIS Enterprise portal supports only one DNS for public portal URL (the web context URL), and to support external access, an externally resolvable DNS name for the portal’s web context URL, e.g. https://gis.company.com/portal, must be used.

In most cases, the pattern above will include implementation of a Split Domain Name System (Split DNS), i.e. internal requests to ArcGIS Enterprise DNS (e.g. gis.company.com) will be resolved to the internal web adaptors machine IP, so internal users will stay behind the firewall, and external requests to ArcGIS Enterprise DNS will be resolved to the DMZ reverse proxy IP.

Using a Web Application Firewall (WAF) in front of the DMZ reverse proxy is a security best practice, as it adds additional security controls. Esri maintains a document (organizational login is required) in https://trust.arcgis.com with list of endpoints which may be safely filtered from external access to deny external access to potentially sensitive resources in your ArcGIS Enterprise site.

Special Security Constraints

No Unauthenticated Access to the Internal Network

In a federated ArcGIS Enterprise system, portal is responsible for user authentication and authorization. In the pattern above, when user makes a request to ArcGIS Enterprise, ArcGIS Enterprise will first check if the request to the secured resource (e.g. service) contains a valid authentication information, and if not, ArcGIS Enterprise will return a redirect response to the client to authenticate with the configured identity provider, e.g. SAML or OpenID Connect.

In the architecture above, an unauthenticated request from an external client is passed from the DMZ reverse proxy to an internal web adaptor, and from the web adaptor to ArcGIS Enterprise portal or server, before ArcGIS Enterprise returns a redirect response to the client.

Some security policies forbid unauthenticated access to the intranet zone, and so the above architecture does not meet this constraint.

No HTTPS Access / Only Database Access is Allowed from the DMZ to the Internal Network

Most security policies allow inbound access from the DMZ to the internal network, but may limit the type of allowed access by protocols or ports. Examples would be to not allow HTTPS (Hypertext Transfer Protocol Secure) access from DMZ to the intranet or allowing only database access via custom ports.

In the architecture above the DMZ reverse proxy pass the requests to ArcGIS Enterprise using HTTPS via port 443, which does not meet the constraint.

No Inbound Access from the DMZ to the Internal Network

In some cases, security policies forbid any type of inbound access from the DMZ to the internal network, and only allow non-persistent connections from the intranet to the DMZ.

Security Architecture Patterns

Let’s consider the below security architecture patterns and review how each pattern addresses some or all of the security constraints which we have reviewed above.  

DMZ ArcGIS Enterprise Portal and Registered Services

Figure 2 - ArcGIS Enterprise Portal Proxy

In figure 2 above, there is an ArcGIS Enterprise portal in the DMZ, and an ArcGIS Enterprise server in the internal network. The internal standalone server is not federated with portal – services are published directly to the standalone server, configured as secured in server using an application account (ArcGIS Enterprise server built-in application account or Active Directory / LDAP service account), and then added to portal as items from the web with stored credentials. When ArcGIS Enterprise server secured service is registered in portal with stored credentials, portal creates a proxy URL for that service, and all requests to that service will go through portal before they are forwarded to the internal standalone Server. ArcGIS Enterprise portal also allows you to define rate limit and specific referrers that can access the service.

Using the above pattern meets the constraint of no unauthenticated access to the internal network, as all external requests must pass through the portal in the DMZ, which will first authenticate and authorize the user, and only then make a request to the service in the internal network. Be aware that since all requests from portal to server are done using the stored credentials, you lose the editor tracking capability.

The architecture in this pattern can be elaborated to include an internal-facing federated system of ArcGIS Enterprise with portal, hosting server, and federated server(s), as depicted in figure 3.

Figure 3 - ArcGIS Enterprise Portal Proxy Elaborated

Internal Replicated Geodatabase

Some organizations’ security policies do not allow HTTPS access from the DMZ to the intranet, and only allow database access, usually via non-default ports, and in many cases also do not allow external access to a primary production database, and require the usage of a separate database.

In figure 4 below, ArcGIS Enterprise is deployed to the DMZ, and an internal replicated enterprise geodatabase is used as registered data source for the mapping server. Either Esri geodatabase replication or RDBMS replication can be used.

Figure 4 - Database Replication

Figure 5 below presents an elaborated architecture which includes internal-facing ArcGIS Enterprise system in the internal network and an external-facing ArcGIS Enterprise system in the DMZ.

Figure 5 - Database Replication Elaborated

Service Publication and Collaboration

Finally, for those who do not allow any inbound access from the DMZ to the intranet, figure 6 below depicts an external-facing ArcGIS Enterprise in the DMZ, and an internal-facing ArcGIS Enterprise in the intranet, with:

1. Services published to the DMZ ArcGIS Enterprise system as hosted layers, and automated tasks running on a schedule (e.g. nightly or weekly) to overwrite the hosted data with updated data from the internal ArcGIS Enterprise system
2. Feature layers are shared by copy from the internal ArcGIS Enterprise system to the DMZ ArcGIS Enterprise system via distributed collaboration with two-way shared editing (introduced at version 10.9)

Figure 6 - Service Publication and Collaboration

Restrict External Applications Access to ArcGIS Enterprise

In some cases, organizations use ArcGIS Enterprise to support external integrating applications and want to restrict external applications access by filtering external requests, allowing requests only from either specific list or range of IPs, or from specific domains.

ArcGIS Online Proxy

Similar to the DMZ ArcGIS Enterprise Portal and Registered Services pattern (figure 2 above), ArcGIS Online also acts as a proxy when you register secured services from either standalone ArcGIS Enterprise server or from federated ArcGIS Enterprise system. In Figure 7 below, services from an internal ArcGIS Enterprise system are registered in ArcGIS Online with stored credentials, ArcGIS Online can access the services via the DMZ reverse proxy, and the reverse proxy is configured to allow requests only from ArcGIS Online domain, blocking requests from any other sources. The integrating system web or mobile app can be registered with ArcGIS Online using OAuth 2.0 and ArcGIS Identity, so only authenticated and authorized users can access the registered services. Since ArcGIS Online will access the services using the stored credentials, editor tracking will not work. Similar to portal, you can define rate limit and specific referrers that can access the services.

Figure 7 - ArcGIS Online and Registered Services

Server Proxy

Another approach would be to use a standalone ArcGIS Enterprise server site and a server proxy to access secured services from an integrating web app.

In figure 8 below, integrating system web app clients are configured to send GIS requests to a proxy, hosted on the integrating system application server. The integrating application server is responsible to secure access to the proxy, i.e. allow only app-authenticated users to access the proxy, and to protect (encrypt) the ArcGIS Enterprise server credentials. The proxy handles the ArcGIS Enterprise server token security on behalf of the client, using a server built-in application account or an Active Directory / LDAP service account, and sends the request to the internal standalone ArcGIS Enterprise server site via the DMZ reverse proxy. The reverse proxy is configured to allow requests only from the integrating app server(s) IPs (list or range), blocking requests from any other sources.

Figure 8 - Integrating Web App Server Proxy