Policy Lifecycle: load & clear management

[mariajgrimaldi]

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.

[mariajgrimaldi]

#55 (comment)

[mariajgrimaldi]

I'm going to do some load and clear management for the has_permission call in case it needs to be self-contained for other services to directly consume from the public API. I think that for the rest API we can do some of this management at the view level. Another solution could be to have a decorator that uses the load_filtered_policy.

[mariajgrimaldi]

This was addressed by #103

Should we close it? And open a different one if we're going to consider to load_filtered_policies in the future @BryanttV

[BryanttV]

Yes, I agree with that.