When a Legacy App Can’t Consume
Secured Esri Map Services

March 7, 2019 — Skye Perry

Esri’s ArcGIS Server was around long before we saw the full evolution into modern web GIS including ArcGIS Online and ArcGIS Enterprise. Correspondingly, many third-party vendors built their own productized or custom web applications that consumed the REST web services from ArcGIS Server to include Esri mapping within their own applications. Many of these third-party applications may still provide critical functionality to your business today.

Now fast forward a few years. Many, if not most, of our customers have now implemented either ArcGIS Online (SAAS-based) or ArcGIS Enterprise (on-premise), both of which provide true web GIS including portal-based content management for our geospatial service items (map and feature services), web maps, and web applications. SSP was an early leader in these implementations and provided a lot of guidance to the industry around best practices when it came to architecting these deployments.

When we first began implementing ArcGIS Online, we often deployed what is called a hybrid installation which utilized an on-premise ArcGIS Server installation behind your firewall while securely exposing the REST web services to the internet via ArcGIS Online. We accomplished this by fully utilizing SSL / HTTPS encryption across the entire solution and then securing ALL of the web services using ArcGIS Server security which includes username/password authentication. We have yet to find an IT department that wouldn’t get behind this secure architecture and it truly provided a secure, yet accessible, deployment of your web mapping strategy. You may remember this architecture from many years ago:

As we the evolved into ArcGIS Enterprise installations (on-premise deployments of Portal for ArcGIS and ArcGIS Server), there was still a need to expose the applications securely to the internet. We accomplished this in a similar way by securely exposing both the Portal website and the underlying REST map services to the internet via SSL security with username/password authentication across the solution. This is a completely viable solution when it comes to deploying the Esri utility network which runs solely on secured web map services. I didn’t include the Portal architecture diagram in this post because it gets more complex. Contact me if you’d like to check it out.

Hopefully these internet-enabled deployment approaches ring true with you. So, where’s the problem? Well, many of those critical third-party business applications that consume ArcGIS Server web services were never upgraded to consume secured web map services. Now on the one hand, I have been preaching to the third-party vendors for years that they NEED to fix this issue and that ALL applications should support utilizing secured web services and many aligned Esri vendors do exactly that (SSP, Schneider, GeoCortex, etc.). But it turns out that there are many other third-party apps out there that just never made the leap forward and they continue to ONLY support unsecured map services. There in lies the dilemma.

I only know this because I’ve fielded countless calls and emails from our long-term customers asking what to do in this scenario. Historically, my answer has always been that you have to either:

a) unsecure the web services but that is a HORRIBLE idea if your map services are exposed to the internet and most IT departments would never sanction the risk that comes with this approach.

OR

b) deploy a second ArcGIS Server that is dedicated to serving the unsecured web services to the requisite third-party applications that can’t consume secured services. This server would NOT be exposed to the internet at all and would exist solely behind the firewall. While this is viable, it is certainly less than ideal because you have to provision a second server, maintain a second ArcGIS Sever installation, and likely publish and manage duplicate internal-only web services. Not insurmountable but ugh. No one is overly excited about this approach either.

With all that said, I got two identical calls on this exact issue from two separate customers late last year and after providing the above options, I realized we really needed to find a better way to solve this problem.

These calls happened to occur just before SSP’s 5th annual CodeFest competition which is an internal coding competition, originally instituted by our own Corey Blakeborough, where we form teams and tackle cool and valuable business challenges within the timeframe of a single day. Each team presents their solution to the company, there are prizes, and a lot of fun along the way. Some of our best internal tech has come out of CodeFest including the job costing system that runs our entire business, our time tracking system, and a number of product and customer-focused solutions.

So, I spearheaded a CodeFest team and enlisted two of our fantastic programmers, Konstantin Korchakov and John Sieben, to go after this issue. We knew there had to be a better solution! By the end of the competition, we (mostly Konstantin and John to be fair) had created a fully functioning solution which is deployed as a proxy website that consumes either ArcGIS Server or Portal for ArcGIS secured web services.

We configure authentication credentials into the proxy website which allows access to the secured web services and then expose / pass through the REST web services in an identical fashion to the native Esri map services. The consuming third-party application is then pointed at the proxy website instead of the ArcGIS Server instance and it can consume the services without having to provide any authentication credentials! The key is that the proxy website is NOT exposed to the internet and is only available behind the firewall thus ensuring the security of the overall solution. And, the proxy website can be deployed to ANY existing IIS web server. No new or dedicated infrastructure required. The following diagram shows the complete solution (this shows ArcGIS Online, the ArcGIS Enterprise deployment is very similar):

This simple, yet elegant, solution solves all of the issues and results in us being able to deploy a fully secured ArcGIS Server or ArcGIS Enterprise to the internet while still serving the legacy third-party apps that don’t support authenticated services. All with a single deployment. It’s the best of both worlds! My promise to the team at the beginning of CodeFest was that I could sell the solution twice within a week and with a little luck, I delivered on that promise. The proxy website can be installed and configured in under an hour!

In summary, if you’re facing a similar issue, don’t waste your time or effort on either of the undesirable solutions. Give us a call and we can deliver best of both worlds in literally no time at all!

We Wrote the Book

The Indispensible Guide to ArcGIS Online

Download It for Free
Chairman of the Board

What do you think?

Leave a comment, and share your thoughts

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>


This site uses Akismet to reduce spam. Learn how your comment data is processed.