Interactive SQL Query Rewriting Demo
See how PlainID dynamically modifies SQL queries based on user context and policies.
Select User Context
Original SQL Query
Modified Query Result
Query Results
How It Works
PlainID intercepts SQL queries before they reach the database and modifies them based on:
- User identity and attributes
- Configured PBAC policies
- Resource access rules
- Environmental context
System Architecture
Query Processing Flow
Core Components
- SQL PDP Service (Docker container)
- Policy Decision Point
- Integration Libraries (.NET, Spring Boot)
- Runtime Resolution API
Configuration
- Environment variables
- Database connection settings
- Runtime URL configuration
- Logging levels
Supported Databases
- PostgreSQL
- Microsoft SQL Server
- Amazon Redshift
- Google BigQuery
- And more...
docker run -d -t -i \ -e RUNTIME_URL=http://runtime:8080/api/runtime/resolution/v3 \ -e HTTP_PORT=8080 \ -e DB_USER=sa \ -e DB_HOST=YOUR_MSSQL_SERVER \ -e DB_PORT=1433 \ -e DB_DEFAULT=testdb \ -e DB_ENABLED=true \ -e DB_DRIVER=sqlserver \ -p 8080:8080 \ --name authz-sql-pdp-modifier \ plainid/authz-sql-pdp-modifier:latest
Key Features
Row-Level Security
Automatically adds WHERE clauses to filter rows based on user permissions. Control data access at the most granular level.
Column-Level Filtering
Dynamically removes or masks columns from SELECT statements based on user attributes and classification levels.
Cell-Level Masking
Combines row and column controls to provide cell-level data protection. Mask sensitive data like SSNs or credit card numbers.
Real-Time Processing
Query modification happens in milliseconds, ensuring minimal latency while maintaining security.
Dynamic Policies
Policies are evaluated at runtime based on current context, allowing for adaptive security based on risk signals.
Audit & Compliance
Comprehensive logging of all query modifications for compliance reporting and security auditing.
Query Modification Examples
Example 1: Row Filtering
SELECT * FROM orders
SELECT * FROM orders
WHERE region = 'North America'
Example 2: Column Filtering
SELECT * FROM employees
SELECT id, name, department, title
FROM employees
// Salary and SSN columns removed
Example 3: Data Masking
SELECT name, ssn, salary
FROM employees
SELECT name,
CASE WHEN 1=1 THEN 'XXX-XX-' + RIGHT(ssn, 4) END AS ssn,
CASE WHEN role = 'manager' THEN salary ELSE '[REDACTED]' END AS salary
FROM employees
Integration Guide
Select an integration method to view implementation details and code examples.
Spring Boot
Java-based integration with Spring Boot applications using interceptors
.NET Framework
C# integration with Entity Framework Core for .NET applications
Direct API
REST API integration for custom implementations in any language
Policy Configuration
Action: Add filter WHERE region = User.Region
Resources: orders, customers, sales_data
Action: Mask column values
Resources: All tables with PII columns
Action: Remove columns: salary, ssn, performance_rating
Resources: employees table
Policy Definition Example
{
"policyName": "Customer Data Access",
"description": "Controls access to customer data based on user attributes",
"rules": [
{
"name": "Regional Filter",
"condition": {
"userAttribute": "region",
"operator": "equals",
"value": "${user.region}"
},
"action": {
"type": "ROW_FILTER",
"filter": "customer_region = '${user.region}'"
}
},
{
"name": "Sensitive Data Masking",
"condition": {
"columnClassification": "SENSITIVE",
"userClearance": {
"operator": "lessThan",
"value": 3
}
},
"action": {
"type": "COLUMN_MASK",
"maskingFunction": "PARTIAL_MASK"
}
}
],
"priority": 100,
"enabled": true
}
Policy Best Practices
- Start with coarse-grained policies and refine as needed
- Use attribute-based conditions for flexibility
- Test policies in a non-production environment first
- Monitor policy performance and query impact
- Document policy decisions and business justifications
- Regularly review and audit active policies