RBAC M4: Building the Console

[MaferMazu]

• Library Management category added to Admin Configuration
  Note, this must be aligned with the user stories Page: User Stories - RBAC MVP: Libraries
• Basic UI for assigning roles and viewing permissions
• Connection between UI and RBAC APIs

[dcoa]

@rodmgwgu we were working on the APIs contract for the Console MVP and we would like to get your feedback and align that with the proposal you have been working on, for now this is the list of endpoints, request and response that was considered:

API contract proposal

• Permission validation - role validation ⇒ this is the same that you described in confluence
  • Endpoint: authz/permission/validate
  • POST
    • Request: Array<{id: number, object: string, action:string, scope?: string}>
    • Response 200 Array<{id:number, allowed:boolean}>
    • Not authorized 403 ⇒ If the user does not have any role in the library
• User management (for libraries = team)
  • Endpoint: authz/role/users/?scope=libraryId
  • GET List of users in the library team, list of user with a role in the library
    • Response 200 { username: string, displayName: string, email: string; Array<roles:string> }
  • PUT Add new user to the library with a role
    • Request: {users: Array<username | email:string>, role:string }
    • Response 200/207 {completed: { Array<{user:string, status:string}>, errors: Array<{user:string, error:string}>}
      • status: role_added, added_to_team, already_has_role
      • error: user_not_found
      • Bad request 400
  • DELETE Delete user role
  • Endpoint: authz/role/users/?scope=libraryId&usename=userId&role=admin (should we consider bulk action for the feature? for the MVP roles are deleted one by one)
    • Response 200
    • Not found 404 / Conflict 409
• List of roles with the corresponding permissions
  • Endpoint: authz/roles/?scope=libraryId
  • GET
    • Response 200 Array<{role:string, description:string, user_count:number, objects: Array<{ object:string, description:string, actions: Array<action:string> }> }>
    • Not found 404
• For the MVP, metadata (e.g., library names, IDs) is retrieved via the Libraries API. Eventually, it should be provided directly by the Console backend.

[rodmgwgu]

@rodmgwgu we were working on the APIs contract for the Console MVP and we would like to get your feedback and align that with the proposal you have been working on, for now this is the list of endpoints, request and response that was considered:

API contract proposal

• Permission validation - role validation ⇒ this is the same that you described in confluence

  • Endpoint: authz/permission/validate

Following these conventions, I think the endpoint would be:

/api/authz/v1/permissions/validate

• POST

  • Request: Array<{id: number, object: string, action:string, scope?: string}>

Wouldn't there eventually be cases where object would be optional? like having a global action? @mariajgrimaldi

* Response 200 `Array<{id:number, allowed:boolean}>`
* Not authorized 403 ⇒ If the user does not have any role in the library

I think for this endpoint, 403 wouldn't apply, as anyone should be able to query for permissions, and this wouldn't be limited to libraries.
The possible errors I see are:

• 400 Bad Request when the request body doesn't match the expected data format
• 401 When the user is not authenticated/logged in at all

[rodmgwgu]

• User management (for libraries = team)

  • Endpoint: authz/role/users/?scope=libraryId

Following these conventions, I think the endpoint would be:

/api/authz/v1/roles/users?scope=libraryId

• GET List of users in the library team, list of user with a role in the library

  • Response 200 { username: string, displayName: string, Array<roles:string> }

Also, following conventions, I think we would need to use display_name instead of displayName.

• PUT Add new user to the library with a role

  • Request: {users: Array<username:string>, role:string }

  • Response 200/207 {completed: { Array<{username:string, status:string}>, errors: Array<{username:string, error:string}>}

    • status: role_added, added_to_team, already_has_role
    • error: user_not_found
    • Bad request 400

• DELETE Delete user role

• Endpoint: authz/role/users/?scope=libraryId&usename=userId&role=admin (should we consider bulk action for the feature? for the MVP roles are deleted one by one)

Same here: /api/authz/v1/roles/users?scope=libraryId&username=userId&role=admin

* Response 200
* Not found 404 / Conflict 409

• List of roles with the corresponding permissions

  • Endpoint: authz/roles/?scope=libraryId

Same here: /api/authz/v1/roles?scope=libraryId

• GET

  • Response 200 Array<{role:string, description:string, user_count:number, objects: Array<{ object:string, description:string, actions: Array<action:string> }> }>
  • Not found 404

• For the MVP, metadata (e.g., library names, IDs) is retrieved via the Libraries API. Eventually, it should be provided directly by the Console backend.

[rodmgwgu]

I've raised a draft PR with my proposal for the permission validation endpoint FYI: #60

[dcoa]

Thank you for reviewing that, if you guys agree I will add the revised version to the frontend US as a guide. @rodmgwgu @MaferMazu

[rodmgwgu]

Thank you for reviewing that, if you guys agree I will add the revised version to the frontend US as a guide. @rodmgwgu @MaferMazu

Sounds good, just please review the latest changes on my PR, I did some changes on the object shapes for the validate endpoint based on recommendations by Braden

[dcoa]

I was reviewing the design for the last endpoint

I think something like this could be more flexible for transforming the data into the different views.

{
  "roles": [
    { "key": "library_admin",, "description": "...", "user_count": 3 },
    { "key": "library_author", "description": "...", "user_count": 1 }
  ],
  "objects": [
    { "key": "library_team", "description": "Permissions to manage user access and roles within the library." },
    { "key": "library_content", "description": "Create and manage content items" }
  ],
  "permissions": [
    {
      "object": "library_team",
      "action": "view_library_team",
      "roles": ["library_admin", "library_author"]
    },
    {
      "object": "library_team",
      "action": "manage_library_team",
      "description": "View the list of users who have access to the library",
      "roles": ["library_admin"]
    }
  ]
}

For the MVP, understanding the context is small I can manage the descriptions by frontend (will be difficult in the future when custom roles can be created, but for now is okay)

@mariajgrimaldi what do you think?