Enterprise Row-Level Security via SOI + Portal Groups - is my plan feasible?

[JonJones1]

Hey guys, I've been working an outline for implementing row-level feature filtering with SOIs combined with map/dashboard filtering using Enterprise Portal groups. 

Below is the outline of my approach. Does anyone see any issues or reasons this wouldn't work? I'm particularly interested in feedback from anyone who's implemented something similar - did you run into any pitfalls I should be aware of? The goal is to filter features based on region without creating separate services for each user group.

ArcGIS Enterprise Security Demo: Row-Level Feature Filtering with SOIs

Executive Summary

This demonstration showcases a practical solution to a common enterprise GIS security challenge: providing row-level data access control without requiring individual database accounts. Using a combination of ArcGIS Portal groups and a custom Server Object Interceptor (SOI), we can deliver personalized data views to different user groups while maintaining a single database connection. This approach addresses our current IT constraints while still meeting security requirements.

The solution leverages Portal groups to control dashboard visibility and a PostgreSQL-driven SOI to filter map features dynamically based on user permissions. When users log in, they'll only see the dashboards relevant to their role and, within maps, only the data they have permission to access. This two-tiered approach provides comprehensive security without requiring database-level modifications or individual database credentials.

Current Environment Constraints

Our organization faces several constraints that prevent implementing traditional row-level security directly in the database:

1. Single Database Connection: All feature services connect to PostgreSQL using a single "data-owner" account via .sde files. IT cannot provide individual database logins for each user.

2. Limited IT Support: The IT department cannot assist with database-level security configuration before this demo. Any solution must work within existing infrastructure.

3. Portal-Centric Enterprise: Our ArcGIS Enterprise deployment is heavily Portal-centric, with a requirement to maintain consistent user experiences through Enterprise Sites.

4. Maintenance Overhead Concerns: We must avoid creating and maintaining multiple view layers and separate maps and dashboards for each user group. With our environment expected to grow to over 100 maps, dashboards, and Experience Builder apps, and potentially hundreds of users, managing multiple instances of nearly identical content would create an unsustainable maintenance burden.

5. Security Requirements: Despite these constraints, we need to demonstrate secure, filtered views of the same data based on user permissions.

Solution Architecture: SOI-Based Feature Filtering

We've designed an SOI-based solution that provides row-level security without requiring changes to the database authentication model:

1. Portal Groups for Application Security:

   • Use Portal's built-in groups (West-Users, East-Users, Admin) to control access to entire dashboards/applications
   • Users will only see dashboard cards they have permission to access

2. Java SOI for Feature-Level Security:

   • Deploy a custom Server Object Interceptor (SOI) that intercepts REST requests
   • Extract the requesting user's email from the request
   • Query a PostgreSQL lookup table to determine user permissions
   • Dynamically modify queries to filter features based on permissions

3. PostgreSQL Lookup Table:

   • Simple soi_user_groups table that maps emails to permission groups
   • All database access still occurs via the single "data-owner" account
   • No changes to existing database security model required

4. Single Map Instance Approach:

   • Maintain just one version of each map, dashboard, and Experience Builder app
   • Avoid creating separate view layers for each security context
   • The SOI dynamically filters data based on user permissions
   • Eliminates the need to create and maintain separate content for each user group
   • Ensures consistency across all applications and dashboards
   • Scales efficiently as we grow to 100+ maps and dashboards with hundreds of users

5. Preserved Editing Capabilities:

   • Users with editor privileges in Portal can still edit features
   • Editing is naturally restricted to only the features they can see
   • No separate configuration needed to control edit permissions
   • West users can edit West features, East users can edit East features
   • Admin users can edit all features
   • Enterprise role-based permissions continue to function normally

Demo Implementation

The demo implementation includes:

1. PostgreSQL Components:

   • Lookup table with email-to-group mappings
   • Three sample users: alice@corp.com (West), bob@corp.com (East), carol@corp.com (Admin)

2. Java SOI:

   • QuickDBFilterSOI class that intercepts REST requests
   • User permission caching to improve performance (5-minute TTL)
   • Runtime query modification to filter rows based on the region field
   • Temporary hard-coded database credentials (will move to Credential Store after approval)

3. Portal Configuration:

   • Three user groups controlling dashboard visibility
   • Single Enterprise Site containing all dashboards
   • Appropriate item sharing to implement group-based access control

What This Demo Will Show

This demo will clearly demonstrate to management:

1. Multi-Level Security:

   • Portal groups hiding entire dashboards from unauthorized users
   • Feature-level filtering showing only authorized data to each user
   • All through a single Enterprise Site URL

2. User Experience:

   • Alice (West user) sees West Dashboard and only West region features
   • Bob (East user) sees East Dashboard and only East region features
   • Carol (Admin) sees all dashboards and all features

3. Technical Feasibility:

   • Row-level security without database authentication changes
   • Minimal impact on existing infrastructure
   • Scalable approach that can be expanded to production

What Users Will See

User Portal Group DB Permission Visible Content Visible Features Editing Capability

Alice	West-Users	['west']	• Enterprise Site<br>• Plant Map<br>• West Dashboard	Only features with region='west'	Can edit West features if assigned editor role
Bob	East-Users	['east']	• Enterprise Site<br>• Plant Map<br>• East Dashboard	Only features with region='east'	Can edit East features if assigned editor role
Carol	Admin	['admin']	• Enterprise Site<br>• Plant Map<br>• West Dashboard<br>• East Dashboard	All features (admin sees everything)	Can edit all features if assigned editor role

Key Implementation Requirements

1. Data Layer Requirements

   • Feature layer must have a region field containing values like "east", "west", "admin"
   • These values must exactly match the values stored in the PostgreSQL lookup table

2. Portal Configuration

   • Create three groups: West-Users, East-Users, Admin
   • Share the Enterprise Site to the Organization (everyone can access the URL)
   • Share the base map to the Organization (everyone can see it, SOI filters the rows)
   • Share the West Dashboard only to West-Users group
   • Share the East Dashboard only to East-Users group

3. SOI Configuration

   • Deploy the SOI to ArcGIS Server
   • Enable it on the target feature service
   • Configure constants to match your environment (service name, layer IDs, field name)

Future Enhancements (Post-Demo)

After successful demonstration and approval, we plan to enhance the solution:

1. Move database credentials to ArcGIS Credential Store
2. Add configurable failure modes with user-friendly error messages
3. Implement comprehensive logging and performance metrics
4. Move configuration to external files instead of hard-coded constants
5. Work with IT to evaluate more integrated security options

So is this possible?