Database Authorization & Row Level Security
Relevant source files
The following files were used as context for generating this wiki page:
Database Authorization and Row Level Security (RLS) manage access to financial data within the repository. The system uses a centralized configuration layer to enforce security boundaries between production and development environments. This architecture ensures that sensitive operations, such as asset graph rebuilds and administrative data access, remain restricted to authenticated and authorized actors.
The security framework coordinates between FastAPI backend services and the underlying database layer. It relies on environmental variables, JSON Web Tokens (JWT), and strict database connection management to protect the integrity of financial asset relationships.
Authentication and Authorization Architecture
The system implements a centralized authentication and authorization flow. It uses the Settings class to load security configurations, including the SECRET_KEY and administrative credentials.
Identity Management and JWT
The application uses JWT for identity propagation. The SECRET_KEY signing mechanism ensures that only valid tokens facilitate access to protected endpoints. In non-development environments, the system enforces a minimum length of 32 characters for the SECRET_KEY to prevent weak configurations.
Sources: src/config/settings.py:34-40, SECURITY.md:38-42
Administrative Access Control
The system seeds administrative users based on configuration variables. These administrators possess elevated permissions for managing the asset graph and user database.
| Configuration Field | Description | Default/Behavior |
|---|---|---|
ADMIN_USERNAME | Username for the primary administrator | admin |
ADMIN_PASSWORD | Password for the primary administrator | Must be set via env var |
ADMIN_DISABLED | Toggle to disable the admin account | False |
Sources: src/config/settings.py:100-110, AGENTS.md:65-72
Database Security and Connection Management
Database security is enforced through connection string resolution and explicit path management. The system supports multiple database types but maintains strict validation for SQLite paths to prevent unauthorized file access.
Connection Resolution
The api/database.py module manages database connections using the DATABASE_URL. It implements a custom resolver to prevent common SQLAlchemy path errors that could lead to unwritable or misconfigured database files.
The diagram shows the flow from configuration loading to database connection resolution, highlighting environment-specific security gates.
Sources: api/database.py, AGENTS.md:180-195
Connection Constraints
Connection management is handled via context managers to ensure absolute disposal of sessions and file handles. This prevent resource leaks that could lead to denial-of-service conditions or stale data exposure.
Sources: GEMINI.md:30-35
Row Level Security and Data Access Patterns
Access to specific financial records and relationship metrics is governed by ownership and environment policies.
Asset Graph Isolation
The production architecture separates the FastAPI backend from the Gradio demo interface. Administrative rebuilds and data modifications must validate the execution_id to ensure execution safety. This prevents stale mutations and ensures that only the current authorized executor can modify the graph state.
Sources: AGENTS.md:140-150
Multi-instance and Lock Management
To prevent race conditions and unauthorized state changes in multi-instance environments, the system uses deterministic lock context managers.
- TTL Bound: Lock managers have a maximum ceiling of 300 seconds.
- Back-off: Acquisition uses deterministic back-off with a 30s ceiling.
- State Protection: Stale owners are prohibited from mutating state after a lock loss.
Sources: GEMINI.md:25-30, GEMINI.md:52-55
Security Policy Enforcement
The repository follows a structured vulnerability disclosure and secret management policy to maintain the authorization boundary.
Secret Rotation Schedule
The project mandates specific rotation intervals for authorization artifacts:
- JWT Signing Keys: Every 90 days.
- CI/CD Tokens: Every 90 days.
- Database Credentials: Every 180 days.
Sources: SECURITY.md:25-35
Validation Procedures
The system uses the following procedure to validate the security state of a hosted deployment:
- Initialize
RealDataFetcheror sample data mode. - Invoke
scripts/check_hosted_readiness.py. - Perform bounded liveness and readiness probes against endpoints.
- Verify that JWT authentication is required for
/api/users/me.
Sources: AGENTS.md:115-130, AGENTS.md:200-205
Summary
Database Authorization and Row Level Security in this project provide a defensive layer around the financial asset graph. By centralizing settings, enforcing strict JWT validation, and managing database connections through custom resolvers, the system protects against unauthorized data access and ensures administrative operations remain idempotent and secure. Significance of this system lies in its ability to support both a production API and a non-production demo environment while maintaining clear security boundaries.