Over the last several years, we here at SSP have worked to stay up to date on the changes in technology that have been released from Esri so that we can advise and guide our customers and the general community on best practices surrounding the Esri platform.

We’ve written extensively about ArcGIS Online including our recommended architecture for using ArcGIS Online while keeping your data secure behind the firewall.

The recommended architecture includes installing a DMZ ArcGIS WebAdaptor server that allows your internal ArcGIS Server REST services to be consumed by ArcGIS Online. There are two key reasons that we utilize this architecture:

1. This is by far the simplest, secure approach to making your data available to ArcGIS Online applications in the field such as Collector for ArcGIS or Explorer for ArcGIS or to web browsers on machines that do not have access to your back office. Most of our customers desire to use the ArcGIS mobile apps on their iOS or Android devices and most corporate networks do NOT support a VPN from these mobile devices to the back office network. Therefore, having the DMZ component in place allows those field devices to have password protected access to the map web services from anywhere at anytime the device has connectivity.
   
2. The second reason was actually a technical limitation from Esri for allowing ArcGIS Online to edit ArcGIS Server Feature Services. Historically, ArcGIS.com has acted as an edit proxy in which your local device needed to relay through ArcGIS.com to perform edits against the back office REST feature service. For this reason, ArcGIS.com had to be able to access the feature service via a public internet address (ex. https://arcgis.somecustomer.com/arcgis/rest/services/…). The DMZ Web Adaptor fullfills this requirement and allows this to work quite nicely. If you, however, tried to access an editable feature service off an internal ArcGIS Service (ex. http://MyServer:6080/arcgis/rest/services/…), ArcGIS Online would return an error similar to the following:
   

   In the context of ArcGIS.com being used as a proxy, this error makes complete sense. ArcGIS.com cannot access the “MyServer” server on the internal network and therefore editing was disabled.

We’ve completed ArcGIS Online installations at utilities across the country and recently found that ArcGIS Online has been “unofficially enhanced” to bypass this error. We credit our good friend Jon Taylor of Jackson Energy Authority (Jackson, TN) for first bringing this to our attention.

Jon had found that he was now allowed to add editable feature services to ArcGIS Online from an internal ArcGIS Server without encountering this error. We jumped in and were able to verify that the error no longer existed by testing this on our own network as well.

We had not seen any formal release on this change from Esri so we reached out to the ArcGIS Online product team to verify what we were seeing. We absolutely wanted to validate this information before broadcasting it to the community! Esri confirmed this was an unofficial enhancement and they wanted to clarify some specifics about how editable features can be used in ArcGIS Online:

• You CAN now edit a feature service from a local server
• The feature service can be either secured with SSL (https) OR only use standard http
• You CANNOT store credentials for the service item within ArcGIS Online

These are important notes that you should fully understand before trying this out in your environment so I’ll break it down into some practical intel.

You can now add a local, editable feature service directly to an ArcGIS Online WebMap or as a service item within ArcGIS Online but you will not be able to save credentials. To demonstrate this, when I add a feature service that is available via the internet to ArcGIS Online, I can save the credentials into the service so that my users are not prompted to authenticate against the service every time they load the map:

The benefit here is that once the user has authenticated to ArcGIS Online via their Esri named user account, they do NOT have to authenticate again at the feature service level. To be clear, if you are using an internal server, you will not have the option to save the credentials (note the missing option):

The reasoning behind this is that ArcGIS.com needs to be able to see the REST endpoint to be able to create an authentication token when using the service via the saved credentials. When the token can be established, Esri can refresh the token automatically from ArcGIS.com to maintain the connection.

The main limitation you will run into in this scenario is double authentication within your WebMaps. The user will first log into ArcGIS Online via the standard login from ArcGIS.com or the web browser. This image shows the first login to ArcGIS Online within Collector using my Esri named user account:

The user then has to log in again using the ArcGIS Server credentials when they load the WebMap. If the app crashes or is closed, the user will have to authenticate again when they reopen the WebMap. This applies to both users in a web browser AND in the mobile applications. This image shows the second, web service level login in Collector, note the request per the specific web service:

This may or may not be a big deal to your organization but in our implemenations we have definitely found that the double login requires additional training issues and has resulted in complaints from the field community. They typically do not want to have to deal with multiple logins.

It’s not insurmountable but it is worth taking into account with your change management plan. One more idea to think about is that if the REST services are only available on your internal network, perhaps you do not need to secure them. This may be an option for you BUT most utilities will still want the authentication in place resulting in the double login requirement.

The other main (and perhaps more important) point I’d like to make is that using this pattern may seem great because you don’t need a DMZ server. BUT it is only going to work well if you are able to connect your field devices to your back office via a VPN. Here at SSP we are lucky enough to have a VPN that supports mobile device authentication.

You can see this on my iPhone Collector screenshot at the top (highlighted in yellow):

Many of your laptops already have VPN access but if your organization does not support a mobile device VPN then you won’t be able to access the internal network feature services from your iOS or Android devices.

So with these clarifications, we do want the community to know about this new option when implementing ArcGIS Online but in my opinion it doesn’t change our recommendation for most customers. We still want to put that DMZ server in place which will allow your end users a seamless experience with ArcGIS Online from any device, any where.

It should be noted that the ‘any device’ concept includes your personal phones, tablets, etc. which also adds significant value in our BYOD world. Let us know if you have further questions on this topic… we are always happy to discuss!