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.

[SamLibby]

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?

[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. 

[SamLibby]

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 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.

[SamLibby]

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