nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Ensure Security Settings Are Enforced Across All Portal Items Generated from Map Service Capabilities

BrandonBackman

1. What’s the idea?
Ensure consistent and enforceable security settings across all Portal items created when publishing a map service with additional capabilities (e.g., Feature, WFS, WMS). Currently, mismatched sharing settings can allow unintended public access to secured data.

2. Why does it matter?
Even if a feature layer item is secured (e.g., shared only with the organization), it can still be accessed via the public map service REST endpoint — creating a false sense of security and potential data exposure.

3. What should change?

Enforce consistent sharing across all related items during publishing.
Prompt users to align visibility settings across capabilities.
Warn when mismatched sharing could lead to unintended access.
Restrict access to secured capabilities through public endpoints unless permissions explicitly allow it.

4. Who benefits?
GIS admins and publishers in ArcGIS Enterprise/Portal — especially those managing secure or public-facing data — by preventing unintentional exposure and improving compliance.

5. How to reproduce the issue?

Publish a map service with Feature Access enabled.
Share the map service item with Everyone.
Keep the feature layer item restricted.
Visit the REST endpoint: the secured feature service is still accessible publicly.

Find more posts tagged with

Status: Open

Comments

ChristopherBowering

I think the concept of Views has a beneficial purpose when it comes to hiding certain fields or specifying desired settings/configurations. However, the issue of sharing remains. In the use cases involved in this thread, the full map image layer and feature layer (without filtering or limitations) components of a service are needed with each serving a difference audience (public vs private).

I agree that maintaining Views could become an overwhelming prospect! I do not use them often as part of my SOP.

D_Atkins

I've been following along for a bit now, and I generally agree on all of the above -- whether the described behavior is intended or not, clear notifications and clearer documentation are always helpful.

I'm curious if anyone else here as explored using Portal Item _view layers as 'standard practice'? We have a couple large datasets subdivided out to user-groups with _views, but nothing we've done as a standard, per se. It makes sense in reading, at least following this fellow:

Securing your Data using ArcGIS Online Views - YouTube and also this ESRI Blog:
Give the REST a Rest

Our concern has been the overhead of maintaining _views and also the Service, but we may be blowing this out of proportion -- once our maps and apps are setup, they usually coast along awhile. And if configuring a _view becomes SOP, well, just one little step to double check when republishing a service. And ... and of course, ignore me completely if your configurations require MapServer/FeatureServer REST URLs for any reason...

ChristopherBowering

I wanted to add my two cents since I am also visiting this post after submitting a case. My case went nowhere and I was told to post an Idea as @BrandonBackman was told to do. The case I submitted was a request for clearer notifications in Portal regarding what actually happens when sharing is different between map image and feature service layers. I was told that a near identical enhancement was submitted in May of this year and the outcome was "will not be addressed" and "will not be in the current product plan".

I was not even asking for changes to ESRI's sharing workflow, merely better alerts to users as misperceptions could lead to very risky outcomes. ESRI is dropping the ball on this.

It would be very easy for a user to assume that when sharing settings are changed for the feature layer service, only, that it would affect both Portal and REST access the same. On the surface, this would seem logical, so why wouldn't someone think this? This could lead to a user unknowingly making sensitive data available to the public while thinking it was secure. The only reason I stumbled upon this is because our GIS consultant dug thru documentation and discovered this nuance. Even then I wasn't sure why this behavior existed as such until I asked ESRI to explain it to me. This needs to be better clarified for Portal users.

SamLibbyTesting

Thanks for posting, I didn't realize you got here through a case already.

BrandonBackman

@SamLibby I appreciate the response - prior to submitting this idea, I submitted case #03876989, but was told that the software works as expected and was directed to this location to provide this as an idea.

SamLibbyTesting

If that is the case, please submit a tech support case to get that reviewed. It may already be logged as an enhancement or bug request, but your scenario helps to further the investigation.

BrandonBackman

@SamLibby I have updated the idea to better reflect the concepts based on your response. In ArcGIS Portal, a "Feature Layer" item results from a map service with "Feature Access" enabled.

Part of your response:
"If you enable Feature Access on that Map Service, a second item is created, with a Feature Layer item type. This item should control access to the /FeatureServer/* endpoints, but has nothing to do with the Map Service endpoints. "

Is also what I believed to be true, but if you test this by changing a map service sharing settings to "Everyone", you will be able to access the feature service from the REST endpoints without logging in, regardless of how you shared the "Feature Layer" (which corresponds to the feature service) item in ArcGIS Portal.

SamLibbyTesting

To get specific on a few topics.
1. A Map Service is what you are publishing, results in a /MapServer or Map Service endpoint,

2. A Map Service can optionally have a capability enabled called Feature Access, which creates a second endpoint at ServiceName/FeatureServer, a Feature Service endpoint.

3. Feature Layers can be created from either a Map Service Layer or a Feature Service Layer, i.e. /ServiceName/MapServer/0, or /ServiceName/FeatureServer/0.

These things are true of ArcGIS Server without Portal and items in the mix.

When your ArcGIS Server site is federated to the Portal, publishing a Map Service results in the creation of a Map Image Layer item, the sharing of which controls access to that /MapServer/* endpoint - only users who can "see" the item in Portal can "see" the MapServer endpoint (and access it either as a dynamic map service layer, or as a feature layer from one of the layers in the Map Service.

If you enable Feature Access on that Map Service, a second item is created, with a Feature Layer item type. This item should control access to the /FeatureServer/* endpoints, but has nothing to do with the Map Service endpoints.

With that context, your last line "Visit the REST endpoint: the secured feature layer is still accessible publicly" - is this referring to the Map Service endpoint or the Feature Service endpoint?