How we are going to store Metadata - PolicyMetada

[MaferMazu]

Problem

The policy file stores rules, assignments, and inheritance, and based on these, the Casbin enforcement makes a decision on whether someone has access or not. But we don't have a direct relation between those rules and our open edx objects (users, scopes, etc); and also we need to store more info regarding the policy to be able to comply with our business requirements (e.g., descriptions for our roles; or know if a rule came by default or it was by another method).

Options

• Having a 1:1 with an extended policy
• Extend fields in Casbin v6/v7 form
  ...

[MaferMazu]

Proposed solution

• Use a Django Model (e,g,. AuthZRoles) to store the role descriptions (role_id: the same as the Casbin use; role_display_name, role_description).
• Use naming to map the relation of the policies with the open edx objects.
  • user^student123, we know that we are talking about an open edx user with username student123
  • role^library_admin it's related to the new model (AuthZRoles) with role_id="role:library_admin"
  • org^OpenedX, lib^lib:sandbox:LIB1, course^course-v1:demo+Demo101+2025 are objects from openedx.
• Use a Django Model to store PolicyMetadata.
  • Using as ID the Casbin rule.
• Use signals to maintain consistency

Warning

For the MVP, we'll only need to store the role descriptions and have a way to maintain policy consistency, so we will focus only on those cases.

Details:

I divided the problem based on the info we need:

Role description

• Django Model: (role_id: the same as the Casbin use; role_name, role_description), and retrieve the info from the Django model when needed. Pros: Central place to store the description, easy access for admins, easy to integrate with the APIs. Cons: we need a sync logic (for the MVP we will assume all the roles have their description, and are related to a Casbin role)
• Extend fields in Casbin v6/v7: add info to the g casbin rules (related to roles), the description. Pros: Metadata with the policy. Cons: Duplication of information, a hard couple; the vN (v0, v6, v7) are not considered role-specific metadata.
• Store key-value: Use a YAML file or something similar to store descriptions. Pros: Performance. Cons: It is harder to maintain and edit.

Audit metadata

• PolicyMetadata 1:1 with CasbinRules: Pros: Clarity, and flexibility (allows evolution). Cons: Requires two insertions in each policy creation.
  • We should check in detail how we will access that info, but first, we should have a specific metadata to store, needed in the APIs, to test and focus on solving this. Comment related: https://github.com/openedx/openedx-authz/pull/55/files#r2378191395
• Extend fields in Casbin v6/v7: Pros: Simplicity. Cons: Make the filters and search more complex, and we are mixing the business logic with the authorization.

Relation with objects

Using the naming in the policies. e,g, user^student123, org^OpenedX, lib^lib:sandbox:LIB1, course^course-v1:demo+Demo101+2025. Because changes in Casbin do not affect system objects, and we can use signals and listeners/receivers to perform actions on the policy if there are changes in the system.

Consistency

• Signals: Pros: we can use the current events and signals to trigger calls in Cabin, for example, (RemoveFilteredPolicy), and real-time updates. Consequences: implement listeners.
• Periodic Checks: Async task. Pros: capture inconsistencies. Cons: Delay, high cost if a large number of policies are involved.

[mariajgrimaldi]

@BryanttV could you help me analyze this proposal and evaluate how feasible it is for our MVP? For the MVP, the most immediate problems we need to address are:

1. Default role descriptions: We need a way to store them. Since these won’t change at this stage, a simple solution would be fine.
2. User info retrieval: Ideally, we’d return this in O(1) time through a 1:1 relationship with our metadata model. But again, let’s keep the MVP scope in mind so we could go in another direction.
3. Policy consistency: We need to ensure policies remain consistent with changes in Open edX objects (users, libraries, etc.). When an object changes, this needs to be reflected on the policy table.

Even though we're cutting some corners here, these solution must be flexible enough so we can build on it later for more complex use cases.

[mariajgrimaldi]

Related issue about consistency: #74

[mariajgrimaldi]

Here's another use case for metadata: https://www.figma.com/design/q3Knq0BKoVTBbtaxb81n9R/RBAC---Console---Wireframes?node-id=2750-9652&t=6pIwORSpB5HF2ft5-0

See how the permissions are sorted by what type of object they apply? Team, content, etc?

[mariajgrimaldi]

Another solution for our MVP could be: leave the descriptions and other static metadata to the frontend as a temporary solution. What do you think, @MaferMazu @BryanttV?

I'll tag @dcoa since she has more context on the other static metadata the model should manage. Let us know what you think!

[dcoa]

what I can say based on the figma file is the metadata includes:

• Role name = User role
• role description = What the role can do within the scope
• resource name = What part of the application is affected by the scope (teams, collection, etc)
• resource description= What the role can do in that resource
• action label = Readable action name
• action description = What the action allow to do.

I know is a lot of information and sound quite repetitive, the information helps to understand the role and the limitation. I do not have a problem to manage that in the frontend for now.

[BryanttV]

I think storing what we need in Django Models is a good option. What we should define more clearly is how we’ll retrieve that data later on, especially when it comes to policy metadata, since, in theory, we don’t have easy access to the ID.

Regarding the MVP, I agree with @mariajgrimaldi, considering that metadata won’t change much, handling it on the frontend for now sounds reasonable.

[MaferMazu]

For me, it is okay to manage that in the front for the MVP.