Policy Lifecycle: load & clear management #69

Description

The current Public API and REST API for authorization assume that the Casbin enforcer is always up to date with the policy datastore. However, the enforcer only works with what is loaded into its in-memory state, and there is no lifecycle management in place to ensure that the enforcer reflects the latest policies. This creates a risk of stale or incomplete policy enforcement.

Problem

• No automatic lifecycle management: The API does not currently load or clear the enforcer. It relies on an external process to ensure freshness.
• Test suite workaround: Our test cases explicitly clear and reload the full policy between tests, but this is not a production-ready solution.
• Memory concerns: The enforcer loads all specified policy lines into memory through the adapter. Loading everything on each request is not scalable.
• Partial policy loading: We need a strategy for loading only the pertinent subset of policies required for the request context, without overloading the enforcer.

Requirements

1. Define when to load policies into the enforcer:

   • On every API call?
   • On demand when stale?
   • Cached until invalidated?

2. Define when and how to clear policies from memory to prevent stale data.

3. Ensure the API and REST API are self-contained and do not require external orchestration for policy lifecycle management.

4. Support scoped/filtered loading (e.g., by org, lib, or user) to avoid loading the entire policy store unnecessarily.

Acceptance Criteria

• The enforcer always reflects the latest state of the policy datastore when API methods (e.g., get_roles_for_user) are invoked.
• The system has a clear strategy for clearing and reloading policies (documented and implemented).
• Subset loading is supported to avoid memory saturation.
• Tests confirm correctness under concurrent API usage.

Notes

• This issue is not about the policy model itself, but about the operational lifecycle of the enforcer.
• We may need to explore caching + watcher patterns (e.g., Redis invalidation) in later iterations, but the MVP should establish a reliable baseline.