Feature-level authorisation in ArcGIS Server REST services

Question

Is feature-level authorisation even remotely possible when accessing ArcGIS (10) via the REST APIs? From what I understand I can secure individual services but at most this gives me control over who can read / write data across the service, and doesn't cover individual layers or features. Is this the case?

I was surprised that there are lots of REST-based (e.g. JavaScript) examples on editing but nothing obvious that looks at who is allowed to edit data - a primary concern in any real-world application.

If feature-level security is not possible what are my options? So far it seems like I must implement my own editing service (possibly through a Server Object Extension?) which can consult Access Control Lists whenever an edit operation is requested. I imagine I could reuse a lot of what's already in the JS API for editing via the Geometry Service but just point it at my own service and fill in the gaps.

Any thoughts much appreciated.

Answer 1

I believe in ArcGIS Server 10.1 there is feature-level ownership-based access control. See this video for a demo (starts at about 40 minutes in): http://video.esri.com/watch/1175/building-web-editing-applications-with-arcgis-10.1-for-server

Answer 2

After a bit more research I found this product. The fact that this exists suggests feature-level authorisation is not available out of the box.

Answer 3

What you say in your second para is a very good place to be. The use of a SEO that can accept other inputs besides just the usual REST input that can be validated on the server side prior to insertion.

My applications require a HTTPS login and the login page pulls a number of values into the user/session/viewstate that are then used to validate the inputs. The use of the usual stock REST API call to filter the display as appropriate ties into this to limit the number of views. From here you can reply back to the JS/API with feedback of if a change was allowed or denied giving you some of the feedback you require.

Adding to this a proxy layer to reduce the amount of exposed information in the raw services is highly recommended.

My primary apps are C# ASP.Net 3.5 that wrap to REST/SOAP with JS/API providing the ESRI interface; yes there is a mixed stack of code but based on the tools exposed with the shutdown of the ADFs it was the best place we could find.