Different sharing settings on Map Service and associated Feature Service for editing does not work?

[Jay_Gregory]

I have published a Map Service and associated Feature Service (feature access to enable editing) off my enterprise geodatabase.  It results in a Map Image Layer and Feature Layer in my federated Portal.  The Feature Layer points to server API resource (.../FeatureServer) and the Map Image Layer points to server API resource (.../MapServer). 

I have tried to share the Map Image Layer publicly while keeping the Feature Layer just accessible to me for editing purposes (see screenshot)

 However, if I navigate to my REST endpoints on server as an anonymous user (using an incognito window to ensure no credential caching), I can see both the MapServer and FeatureServer

What's more, as an anonymous user, I can query and edit the features via the Feature Service API endpoints (delete, add, etc).  

We are working on a fully patched 10.9 Enterprise with federated Portal.  This seems like it is not working as designed, and it also seems like I can't be the first person to experience this if its some undiscovered bug.  

Is there anything I could be doing wrong / anything I'm missing?

It really seems to undermine the security of the entire system if otherwise. 

[Scott_Tansley]

Actually I’d say that’s expected behaviour.  The feature server extends the capabilities of the map server.  Effectively they are the same underlying service.  

The way that I have always dealt with this is to have two map services.  One is public.  The other is extended to a feature server and shared with the appropriate groups.  So in your case secure what you have published and then publish an open map service with no feature capabilities.

The more fine grained type security you describe is possible with the hosted feature layers through views.  But security of traditional referenced data sources is much more course.

[Jay_Gregory]

Understood - I was afraid this was by design - though to me it's still unintuitive. 

It might make sense if the Portal somehow updated the sharing of the associated Feature Layer in the UI if you changed the sharing of the Map Image Layer.  Right now in the UI, it looks as if the Map Image Layer is shared anonymously and the Feature Layer is shared with no one, but it is not actually the case when traversing the REST endpoints.

Furthermore, in order to support what is a very intuitive use case (data view accessible by everyone, data edits accessible by a few) you have to publish TWICE.  One MapService with Feature Access enabled (which itself results into two REST endpoints - MapServer, FeatureServer), and one MapService without Feature Access enabled.  I really thought the whole point of having separate MapService and FeatureService was so  you could share them differently (besides the other tradeoffs in MapService vs FeatureService).

[Scott_Tansley]

It’s a logical argument but I would guess this is a legacy thing, as the style of security predates Enterprise.

there are third party solutions that extend the capabilities like you suggest.  I know Esri rely on them for some projects/use-cases.

and I’ve seen the data exposed in different ways across five services in a nod to what you’re trying to do.