Define Standard Format for Scope IDs in Casbin Policies

[BryanttV]

Description

When using the REST API to assign roles to users through Casbin, there’s a problem related to case sensitivity in the scope field (in this specific case, for libraries)

Example request: /api/authz/v1/roles/users/

{
    "users": ["admin"],
    "role": "library_admin",
    "scope": "lib:openedx:csprob"
}

The actual library ID is lib:OpenedX:CSPROB, However, during validation in the serializer, the following check is performed:

if not scope.exists():
    raise serializers.ValidationError(f"Scope '{scope_value}' does not exist")

Since the exists() method internally performs a case-insensitive lookup:

def exists(self) -> bool:
    try:
        library_key = LibraryLocatorV2.from_string(self.library_id)
        ContentLibrary.objects.get_by_key(library_key=library_key)
        return True
    except ContentLibrary.DoesNotExist:
        return False

In [1]: lib_id = "lib:openedx:csprob"

In [2]: library_key = LibraryLocatorV2.from_string(lib_id)

In [3]: ContentLibrary.objects.get_by_key(library_key=library_key)
Out[3]: <ContentLibrary: ContentLibrary (lib:Openedx:CSPROB)>

the validation passes, even if the scope value casing doesn’t match the real ID in the system. As a result, the policy is stored with the incorrect scope ID in the casbin_rule table.

Later, when a GET request or permission check is made, the stored policy doesn’t match because of the case mismatch; the system expects the exact lib:OpenedX:CSPROB, but finds lib:openedx:csprob.

Impact

• Policies are stored with incorrect scope identifiers.
• Authorization lookups and role retrieval fail due to casing mismatches.
• The issue could also affect other scope types (e.g., Course, Organization, etc.), not only Library.

Possible Approaches

• Normalize all scope IDs before saving policies (e.g., resolve them to their canonical forms or convert them to lowercase).
• Modify the exists() function to return not only a boolean value but also the correct canonical identifier. It’s important to note that the same approach should be applied to all exists() methods of each new scope type.

[BryanttV]

I was reviewing the approaches, and I have two related branches with an initial implementation:

1. Verify in the exists() method that the library_key defined in the instance is the same as the library_key of the object. This is a simple solution, but it must be explicitly called by the developer to ensure that it actually exists and to avoid storing incorrect IDs. Proposal 1

2. Add a new attribute called normalized_key that contains the same namespaced_key but in lowercase. This normalized_key would be used in the other API functions (enforce, add/remove users from roles, get filtered policy, etc.) instead of namespaced_key. With this change, all records in the Casbin table would be stored in lowercase, and all checks would always be performed in that format. Proposal 2

What do you think about this? Do you happen to have any other alternatives we could implement?

@bmtcril @mariajgrimaldi @MaferMazu

[bmtcril]

I think proposal 1 makes the most sense since we don't know if other types of keys will be case sensitive or insensitive, the person developing the key type will have to make that call on a case by case basis.

We should update your code snippet to put in a clear comment as to why we're doing that check there, though, since it's not obvious.

[bmtcril]

I'm actually a little curious how this input was generated in the first place, since anywhere we're using the library locator it should be the canonical version of the key. Was this test input or is something in the UI changing case?

[BryanttV]

Thanks for your comment! In that case, I think we can go with the first proposal, so I'll create a PR with the changes. We can discuss whether we need anything else over there.

I'm actually a little curious how this input was generated in the first place, since anywhere we're using the library locator it should be the canonical version of the key. Was this test input or is something in the UI changing case?

Yeah, it was a test using the REST API in the remote environment. I didn’t know why the permissions validation was failing until I realized that the ID was wrong in the Casbin table.

[mariajgrimaldi]

I think this was done? Closing it for now!