Select to view content in your preferred language

Remove "Share with Everyone" requirement when publishing WFS and WMS

2981
9
07-25-2019 11:57 AM
Status: Open
AndrewStearns1
Occasional Contributor

We have a need to publish some Features and Maps as Web Feature Services (WFS) and Web Map Services (WMS). Currently there is a requirement when publishing WFS that it has to be shared will all. We never publish and share to all due to data security concerns.

https://enterprise.arcgis.com/en/portal/latest/use/publish-wfs.htm

9 Comments
KoryKramer

Have you looked at Securing WFS Services?

KoryKramer

We've marked this Idea as Reviewed but I wanted to provide some further background after looking into this further.

There had been a bug logged for this previously: https://support.esri.com/en/bugs/nimbus/QlVHLTAwMDA5NTkzOQ==  See the Additional Information section there.

So it looks like we're waiting for the OGC spec to support OAuth2.

AndrewStearns1

Thanks for the follow up and links Kory!

Geoeki
by

Any news on this Kory Kramer‌? Did OGC implemented OAuth2 support by now? Thanks!

KoryKramer

This is what I see when I look at the support issue linked to above.  See the Additional Information section.

Marc_Graham

Hi @KoryKramer ,

According to this bug: https://support.esri.com/en-us/bug/secured-open-geospatial-consortium-ogc-services-from-ar-bug-00009... security for OGC services is available.

The ability to secure OGC services is present within ArcGIS Enterprise. Refer to, https://enterprise.arcgis.com/en/server/latest/publish-services/windows/ogc-support-in-arcgis-server....

However it appears to be limited and not include SAML/OpenID as per https://enterprise.arcgis.com/en/server/11.3/publish-services/windows/ogc-support-in-arcgis-server.h... :

Services that are expected to be accessed through OGC interfaces should be secured using HTTP Basic, HTTP Digest, or Integrated Windows Authentication.

Additionally, in a fresh 11.3 ArcGIS Enterprise deployment, signed in as the primary site administrator I get a 499 error on the Sample World Cities WMS and OGC Feature layers as described here: https://support.esri.com/en-us/knowledge-base/error-499-error-occurred-while-processing-request-0000... 

Marc_Graham_1-1732580188188.png

This is resolved when sharing all the layers publicly.

Can you please confirm the exact sharing/security settings that work with OGC layers. In addition please enhance the error reporting to explain if a layer needs to be shared in a specific way to work, so the user doesn't have to google html response codes.

Thanks, Marc

JeffSmith

Hi @Marc_Graham,

A couple of thoughts on this.  If you want to secure an OGC layer, the recommended way is to publish it to an ArcGIS Server that is not federated with a Portal.  In addition, this ArcGIS Server needs to be configured with web-tier authentication (Basic, Digest, IWA, or client-certificate auth).  When an OGC client tries to access the layer, they will be prompted to enter credentials (or provide a client certificate) prior to gaining access.  This should work.  

The problem with other configurations (Server federated with Portal or Server configured with non-web-tier authentication) is it utilizes token-based authentication and most OGC clients do not know how to handle that.  The 499 response code that is returned when trying to access a secured OGC layer is only understood by ArcGIS clients.  There is not a comparable response code that I'm aware of that indicates to an OGC client that an OAuth2 access token needs to be generated and used to access the OGC layer.

There are a few OGC clients that can handle generating and sending an access token (QGIS and FME are  two I can think of), but it is not part of the OGC spec so I don't think there are many others.  This is why we document that OGC layers need to be open and shared with everyone or secured with web-tier authentication to be accessible.

Marc_Graham

Hi @JeffSmith ,

Thanks for that additional insight.

Perhaps in this documentation

Marc_Graham_0-1733443438281.png

 

you could specifically call out that the server should not be federated with Portal.

Thanks,
Marc

JeffSmith

@Marc_Graham - That's a good suggestion.  I'll try to get that updated.