[FC-0099] docs: add ADR proposing how to manage the policy store #59
Conversation
openedx-webhooks
added
open-source-contribution
|
Thanks for the pull request, @mariajgrimaldi! This repository is currently maintained by Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review. 🔘 Get product approvalIf you haven't already, check this list to see if your contribution needs to go through the product review process.
🔘 Provide contextTo help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:
🔘 Get a green buildIf one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green. Where can I find more information?If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources: When can I expect my changes to be merged?Our goal is to get community contributions seen and reviewed as efficiently as possible. However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:
💡 As a result it may take up to several weeks or months to complete a review and merge your PR. |
mariajgrimaldi
requested review from
BryanttV,
MaferMazu,
bmtcril,
rodmgwgu and
sarina
|
|
||
| Do not Handle Grouping and Context Inheritance via Casbin's Built-in Mechanisms | ||
| ------------------------------------------------------------------------------- | ||
| - Grouping resources will not be implemented via Casbin's built-in grouping mechanisms (g, g2) but will be explicitly managed when checking permissions in the application layer. For example, if a user has the ``course_admin`` role in ``org:123``, this will not automatically grant them the ``course_admin`` role in all courses within that org. Instead, the application layer will need to check both the user's role and the specific context (e.g., organization or course) when making authorization decisions. |
There was a problem hiding this comment.
This can probably use an example. It's also the first places where the org:123 syntax shows up so we might need a sentence or link about how contexts are represented? Or just swap the order with the next section.
| Store Dynamic Policies Directly in the Policy Store | ||
| --------------------------------------------------- | ||
| - Consider two types of policies: static policies (shipped with services in ``authz.policy`` files) and dynamic policies (created and managed via the Policy Management API and persisted in the policy store). | ||
| - Dynamic policies created via the Policy Management API will be stored directly in the policy store (MySQL database) using a Casbin adapter. |
There was a problem hiding this comment.
Maybe swap the order of these to so that it's clear at the start what the policy store is?
|
|
||
| Differentiate Between Static and Dynamic Policies | ||
| ------------------------------------------------- | ||
| - Static policies (default) should be differentiated from dynamic policies in the policy store using a metadata field (e.g., ``is_static`` boolean field) and should be immutable after being loaded from the ``authz.policy`` file. |
There was a problem hiding this comment.
Do you have ideas on how this immutability can be accomplished?
|
|
||
| Allow Shared or Separate Policy Stores as Needed | ||
| ------------------------------------------------ | ||
| - By default, all services share the same policy store to ensure consistency and avoid conflicts. |
There was a problem hiding this comment.
I'm not sure what is meant by services here. Are LMS/CMS are one service? Is the expectation that other services like Credentials would use the API to interact with a policy store, and if so which service would own it?
| Allow Shared or Separate Policy Stores as Needed | ||
| ------------------------------------------------ | ||
| - By default, all services share the same policy store to ensure consistency and avoid conflicts. | ||
| - If isolation between services is required, this can be achieved in two ways: (1) by using a namespace or domain field in the shared table, or (2) by creating a separate policy store for a specific service. |
There was a problem hiding this comment.
To avoid large future migrations would it make sense to add a namespacing field up front and plan for future expansion that way?
|
|
||
| Create the Record of the Back-reference Model in the same Transaction as the Policy Creation | ||
| -------------------------------------------------------------------------------------------- | ||
| - To ensure data integrity, the creation of the back-reference model record and the corresponding policy in the policy store should occur within the same transaction. This ensures that both operations succeed or fail together. |
There was a problem hiding this comment.
In the case of non-LMS/CMS services using the policy store over API this may not be possible, but I'm still unclear if that's a case we're supporting.
|
|
||
| #. **Performance Considerations**: The use of dynamic policies and complex matchers may introduce performance overhead. It is essential to monitor the performance of the authorization engine and optimize policies and matchers as needed to ensure that authorization checks remain efficient. | ||
|
|
||
| #. **For Data Integrity Purposes, Place the Policy Store Where the Data is Owned**: To ensure data integrity and consistency, the policy store should be hosted in the same environment as the services that own the data and policies. If this is not feasible, additional mechanisms must be implemented to maintain consistency like an event-bus mechanism. |
There was a problem hiding this comment.
It's still unclear to me how this works with "Clients Share the Same Policy Store" but that probably has to do with my being unclear about what a "service" is in this context and what we're supporting in terms of cross-service authz.
Description
ADR for policy and model (all casbin-related concepts) management fit to our environment. In this ADR we make decisions for:
Merge checklist:
Check off if complete or not applicable: