Edit public facing feature services on arcgis.com using web-tier auth - DOES NOT WORK

5839
7
06-20-2014 12:04 PM
PF1
by
Occasional Contributor II
We have public facing web-services with the 'feature access' capability enabled.  Operations include create, update, delete (and geometry updates).  We are also attempting various offline capabilities using the newly offered 'sync' operation.  We are unable to get any of this to work using web-tier authentication (NTLM, Kerberos,Http Basic, etc).  The public facing web-services are configured similar to the Multiple firewalls with reverse proxy and Web Adaptor in a perimeter network on the ArcGIS server help documentation:


  • web-tier authentication

  • User store: windows domain

  • role store: built-in

  • web-adaptor server sitting in our DMZ

  • GIS Site sitting in our internal network

  • Reverse proxy communication from DMZ to internal network. 

  • Web-app Firewalls (WAF) in front of and behind the web-adaptor server in the perimeter DMZ environment



on the web-adaptor server we have deployed two web adaptors to Supporting a mix of public and private services.  One web-adaptor is deployed over both port 80 and 443 but allows strictly anonymous access (for consuming and unauthenticated access).  The second web-adaptor we have anonymous access disabled and have enabled Integrated Windows Auth (IWA) using both kerberos and NTLM as providers.  We have also tested using HTTP Basic. 

If we add feature service content to an arcgis online map, it tells us that its an internal only service and editing is disabled.  The services are accessible from the dirty internet.  It appears that arcgis.com map executes a request to the service info page (https://www.myserver.com/arcgisauth/rest/info?f=json) and also tries to proxy the request like so:

Request URL:https://www.arcgis.com/sharing/proxy?https://www.myserver.com/arcgisauth/rest/services/FeatureServices/MyService/FeatureServer/0?f=json
Request Method:POST
Status Code:504 Gateway Timeout


Both of those fail because the public facing server returns an HTTP Error code 401 with the 'www-authenticate' headers as the options the client has available to authentication.  We have tried Kerberos, NTLM, and HTTP Basic.  It appears that the arcgis.com map ignores he 'www-authenticate' header and just disables the editing capabilities rather than attempting to obtain the user credentials. 

We can successfully configure the public facing web-server to use GIS Token based authentication (anonymous enabled and IWA disabled on the web-adaptor server), but that security configuration is really not ideal for our customer base. 

Is this a known limitation?  Is there something we are doing wrong?  I would have expected web-tier authenticated services to have editable capabilities if users supplied their credentials.

Thanks for any help/guidance!
Tags (2)
0 Kudos
7 Replies
MikeMinami
Esri Notable Contributor
Only token based editing is supported.

Thanks,

Mike
0 Kudos
PF1
by
Occasional Contributor II

Hi Mike (or others), Do we know if this was addressed at the latest December 2014 release of arcgis.com? 

Basically - is there a way to use the collector for arcgis applications to complete off-line data collection with web-tier protected web-services?  Thanks!

MikeMinami
Esri Notable Contributor

Patrick Foppe

Only token based editing is supported. As far as I know, there are no plans to support web tier authentication.

Thanks,

Mike

0 Kudos
PF1
by
Occasional Contributor II

Thanks Mike Minami‌ for the update.  I've started an ArcGIS Ideas post to see if we can get some headway on this limitation: ArcGIS Idea - ArcGIS Server Web-Tier authentication: Enable editing in ArcGIS Online web maps, Porta...

DuarteCarreira
Occasional Contributor II

It would be reasonable to assume documentation about choosing arcgis server security model would advise on what does not work with each option:

Configuring ArcGIS Server's authentication tier—ArcGIS Server Administration (Windows) | ArcGIS Ente... 

I have been working up to having web tier with windows authentication only to find out later on in a totally unrelated documentation page that printing does not work and is not supported at all:

Print maps that contain secured services—Documentation (10.5) | ArcGIS Enterprise 

It's on the very last paragraph...

It's a discovery process with esri's "Enterprise" products. You may well find out that all your invested time was just wasted. At this point I don't know what else might not work with WIA...

0 Kudos
PF1
by
Occasional Contributor II

Hi Duarte,

Understand your frustrations... we've had to run a duplicative stack with

both web tier and token support due to various limitations either by the

esri products or the nature of windows authentication. We are striving to

only deploy to our token stack if there is a technology limitation

impacting a business need (ex: field data collection with collector and/or

access from devices/platforms that are not 'trusted' in our domain)... so

most of ournservices are in the webtier stack. As for printing with

webtier... there is a known workaround and ideas post you may consider

voting up -

https://community.esri.com/ideas/13647-support-for-printing-web-maps-containing-web-tier-services

Best of luck!

0 Kudos
PF1
by
Occasional Contributor II

Just updating this thread (marking as resolved).  We have successfully been able to take our internal 'web-tier' arcgis for server services offline with collector, collect some data, and sync that data with the web-tier feature service.  We have only been able to confirm this with windows 10 based devices and those devices are trusted in our Active Directory domain.  I think it would still be a challenge to get this working with Android and/or iOS.  

we tested this with a Portal for ArcGIS running 10.4.1 setup with Integrated Windows Authentication (IWA) and an ArcGIS for Server environment v10.4.1 also running IWA.  ArcGIS Server user-store was set to windows domain, role-store set to 'built-in'.  Both servers running on different Windows 2008 R2 hosts with different Fully Qualified Domain Names (FQDN).  

0 Kudos