This documents aim to clarify what is going to be delivered for Ulmo to comply with the AuthZ MVP as a whole, taking into account the base architecture for the authz system, the implementation of the roles and permissions on content library v2, and the user interface, which the different stakeholders could manage the roles and permissions.

The roles and permissions core

We perform a comparison of technologies for authorization based on a complete requirements list and other criteria. However, it is crucial to scope what will be implemented as the core role and permissions, given our tight deadline, so we can incrementally enhance the capabilities of the authorization system to take advantage of it in future releases.

Proposed Scope for the AuthZ Core

• Role and Permission Management API: The system must provide a mechanism to create, read, update, and delete (CRUD) roles, permissions, and role assignments (grants).

• Authorization Evaluation and Enforcement

  • Decision Mechanism: to evaluate whether a user has a specific permission for a given action on an object.

  • Policy Store: to store the defined roles, permissions, and grant associations.

• Default Roles and Provisioning: The system must support the provisioning of a predefined set of default roles and permissions (needed for the content library case)

• Granularity and Scope: The system must support object-level permissions.

• Auditability: The system should provide mechanisms to audit permission assignments and changes related to role management.

About the Content Library Roles and Permissions: Library Roles and PermissionsPreview

Out of the scope for the MVP

• Implied Permissions: The ability for one permission to automatically grant another (e.g., 'edit' automatically includes 'read').

  • Implication: All roles must have every permission explicitly defined, leading to redundant policy rules.

  • MVP Trade-off: It simplifies the initial model and policy by avoiding the complexity of rule chaining.

• Advanced Granularity: The ability to apply permissions to multiple resources at once or to resource groups.

  • Implication: You'll have to create an individual policy rule for each resource (library).

  • MVP Trade-off: It keeps the initial implementation focused on the immediate use case: object-level permissions.

• Extensibility: A mechanism for external plugins to define and register their own roles and permissions.

  • Implication: The core authorization system will not be dynamically extensible by other services.

  • MVP Trade-off: Focus on a static, known set of roles and permissions from Content Library to validate the core functionality.

Console MVP

The scope is to develop and integrate a lightweight solution, a new AuthZ Panel module, into the existing Authoring MFE. This panel will use AuthZ service APIs to manage permissions, and the UI will be restricted to library administrators.

All the details: Technical Approach: Console MVP (AuthZ-Scoped, Ulmo Release)Preview

Technical evolution: Long-Term Technical ApproachPreview

User stories (flows) we are going to cover

We aim to develop two key user flows for library administrators: managing team members (adding, editing, removing users, and viewing user lists) and viewing roles and permissions (examining role details and comparing permissions across roles).

All the details: UX/UI Design Guide & DocumentationPreview

The described user stories integrate:

• The wireframes RBAC / Console - WireframesPreview ,

• The product requirements MVP - Administrative Console: AuthZPreview ,

• And the technical approach Technical Approach: Console MVP (AuthZ-Scoped, Ulmo Release)Preview

1. View team members

Description

As library admin, I want to view all the users in the assigned library and the corresponding roles, so I can understand who has access and at what level.

Acceptance Criteria:

• Should be integrated as a tab (Team Members) in the general view.

• Shows a table with columns: Name, Email, Roles, Actions (Edit/Delete)

• Supports filters by Name, Email, Role

• Access control: Non-admin users see read-only or a permission denial view

• Table should be paginated by 10 rows per page.

• There is a API GET endpoint created to retrieve the library team members

2. Filter and sorting users

Description

As library admin, I want to search and filter the user list by name, email or role, so that I can quickly locate specific users.

Acceptance Criteria:

• TextFilter field for filtering by email or name

• MultiSelectDropdownFilter for role (displaying the name and the number of user associated to it)

• Sorting by name and creation_date

• Client-side filtering and sorting

3. View permissions overview

Description

As library admin, I want to view available roles and their permissions set, so that I can understand each role’s capabilities.

Acceptance Criteria:

• Should be integrated as a tab (Permissions) in the general view.

• Table layout with:

  • Rows = Permissions grouped by categories (e.g., Content, Team, Collections)

  • Columns = Roles Names

  • DataCell is a checkmark (✓) or cross (✕) showing access

• There is a API GET endpoint to retrieve all the roles and associated permissions for the current scope.

4. View roles overview

Description

As a library admin, I want to see a detailed explanation of each role and its permissions, so that, I can better decide which role to assign to a team member.

Acceptance Criteria:

• Should be integrated as a tab (Roles) in the general view.

• Each role is a Card with a Collapsible that include

  • Role title followed by number of user on it.

  • Short description

  • Accordion of list permissions grouped by category (e.g., Content, Team, Collections)

  • Permissions are displayed as Chips enable of disable according tot the role.

• There is a API GET endpoint to retrieve all the roles and associated permissions for the current scope.

5. Add new team member

Description

As a library admin, I want to add a new user to the library and assign a role, so they can gain access to the library as a team member.

Acceptance Criteria:

• There is an “Add New Team Member” action button at the same level as the page title.

• A modal is displayed to introduce 1 or more usernames or emails in a Textarea and a Select is displayed to Select the desired role.

• The list of roles must be only for the scoped context (library).

• Submission triggers Toast notification (“User added successfully”) or error

• There is an API PUT endpoint that add a new team member for the scoped library.

6. Modify/delete roles for a user

Description

As a library admin, I want to modify/delete the role assigned to a user, so I can manage the team members properly.

Acceptance Criteria:

• The edit action in the Team members table should open a view for the selected team member.

• The Role Card component (in the roles overview) should be used to display the assigned roles for the current user. the header of the card should display the edit and delete actions.

• There is an “Add New Role” action button at the same level as the page title (that is the name of the user and the email as subtitle).

• Remove role trigger a confirmation modal.

• The add/modify action trigger a modal with a role selector.

• Updates to UI and toast notification upon success or error.

• There is an API PATCH/DELETE endpoint that modify/delete a current team member for the scoped library.

7. Permission‑Aware Access & Routing

As a library admin, I want that only team members with admin role can access the panel so unauthorized users cannot modify access

Acceptance Criteria:

• From the info sidebar in the library, the “Manage Access” button should redirect admin users to the panel

• Users in roles different to admin should keep the current experience.

• Validate the user role, in case is not admin show a read-only view.

• Context (library name and ID) displayed in header as title and breadcrumb

• Route via Authoring MFE: /console/authz/libraries/:library_id

• There is an API GET endpoint that validates the user role for the UI rendering.