Row level security, ArcGIS Pro and Server Object Interceptors?

[MartinAmeskamp]

Hi,

we've been thinking about row level security on and off, and there are some threads on Geonet about this, but the general consensus seems to be that this can't really be done properly: Oracle has Label Security (Enterprise Edition only!), SQL Server suggests using views, but integrating these things into a geodatabase with versioning, complex datatypes (not to mention geometric networks) etc. doesn't seem to work very well.

Recently, Esri has come up with some new technology: ArcGIS Pro is a lot better than ArcMap in transparently editing feature services (no need for local FileGDB caches), and ArcGIS Server has introduced Server Object Interceptors, which can modify service requests and results.

Has anyone thought about or even tried implementing fine-grained access control with these techniques? Like label security (access based on a feature attribute) or spatial access control (access based on intersection with a polygon)? Obviously, there would be limitations since feature service editing doesn't (yet) handle things like geometric networks, but what can be done?

Thanks, Martin

[nicogis]

... There are some nonsimple data types (for example, network edges), must be versioned for you to edit them through a feature service.

The following data types are not supported in feature services:

• Annotations
• Dimensions
• Group layers
• Layers and tables based on views
• Query layers that contain virtual columns, where clauses, or joins
• Raster datasets
• Terrains

Layers that are part of nonsimple types, such as geometric networks, topologies, and network datasets, are supported, but the types themselves are not returned by the service. For example, you can query the layers that are part of a topology, but you cannot query the topology  itself. ...

Author feature services—Documentation (10.3 and 10.3.1) | ArcGIS for Server

In soi you can access fine grained arcobjects (in init you have server object) so you can do your logic for geometric network using current user from login service

[VinceAngelo]

The main problem to this approach is the fact that the database would be completely ignorant of such modifications.  The hypercomplexity of modifying all tools to behave in a manner fundamentally different from the database really makes this a non-starter.

- V

[JerryGarcia]

Good response V.  Row level security remains a dark path.

[MartinAmeskamp]

So, what do I tell the client who has 800 copies of their 30-table schema and a couple of thousand ArcGIS Server services to handle all these copies: Yes, that's the way to go, just get more hardware!?? Your security requirements are all wrong, open up!??

Sorry if this sounds a bit contrary, but these are real problems.

Martin

[JerryGarcia]

We are dealing with the same exact architecture.  "800 copies of their 30-table schema and a couple of thousand ArcGIS Server services" It is a major problem for our customer.