Approaches
Oso Cloud provides two complementary approaches to list filtering, each optimized for different scales and use cases. Both use the same Polar policies and facts, so you can migrate between them or use both for different resource types.Centralized List Filtering
Uses Oso Cloud’slist
API to retrieve authorized resource IDs, which you then use to query your database. All authorization logic and data lives in Oso Cloud.
How it works:
- Request authorized resource IDs from Oso Cloud.
- Query your database for those IDs.
- Return the filtered results to your user.
Local List Filtering
Uses Oso Cloud’slist_local
API to combine centralized fact evaluation with database-level filtering. Oso Cloud returns SQL WHERE
clauses you can apply directly to queries.
How it works:
- Oso Cloud evaluates centralized facts (e.g., user roles).
- Generates a SQL
WHERE
clause for local relationships (e.g., resource ownership). - Your database applies both in a single query.
When to Use Each Approach
Use Centralized Filtering when:
- Users typically access hundreds to thousands of resources.
- All authorization facts live in Oso Cloud.
- Simple implementation is preferred.
- Network latency between your app and Oso Cloud is minimal.
Use Local Filtering when:
- Users access millions of resources.
- You need complex database queries with joins, aggregations, or advanced filtering.
- Network latency between your app and Oso Cloud matters.
- You want to keep resource relationships in your database.
- You need database-level pagination, sorting, or other operations.
Implementation Requirements
Centralized List Filtering Setup
Centralized filtering works with your existing Oso Cloud configuration. No additional setup is required beyond your standard client initialization and fact synchronization.Local List Filtering Setup
Local filtering requires additional configuration:- Data Bindings Configuration: Map your local database schema to Oso Cloud resources and relationships.
- Client Configuration: Configure the Oso Cloud client to use local data bindings.
- Database Schema Alignment: Ensure your local database schema matches the relationships defined in your data bindings.
Performance Characteristics
Centralized Filtering
- Optimal Range: Up to ~10,000 authorized resources per user.
- Network Overhead: One API call to Oso Cloud per list operation.
- Database Impact: Simple ID-based queries in your database.
- Memory Usage: Resource IDs stored in app memory.
Local Filtering
- Optimal Range: Millions of resources per user.
- Network Overhead: Minimal - only authorization rules evaluation.
- Database Impact: Single query with complex
WHERE
clauses. - Memory Usage: Minimal - filtering happens at database level.
Troubleshooting
Empty results from `list` API
Empty results from `list` API
- Verify facts exist using
get_facts()
. - Check policy syntax with
query()
. - Confirm resource type matches your policy exactly.
- Validate user permissions are configured.
Malformed SQL from `list_local`
Malformed SQL from `list_local`
- Validate your local authorization configuration file.
- Ensure column names match the database schema exactly.
- Confirm relationships are defined in data bindings.
- Verify database connection and permissions.
Performance Issues
Performance Issues
- Review database indexes on columns used in authorization filters.
- Monitor query execution plans for optimizations.
- Apply database-specific optimizations for complex
WHERE
clauses.
Next Steps
- Set up Local Authorization for
list_local
implementation. - Explore API documentation for detailed parameters and options.
- Review enforcement strategies for broader authorization patterns.
Need help implementing list filtering in your application? Schedule a call with an Oso engineer.