Proposal: User Management Improvements

[Mtze]

Proposal: User Management Improvements

Motivation

Managing course instructors and editors currently requires direct access to the Keycloak admin console. This creates an unnecessary dependency on Keycloak expertise and limits who can perform routine course team management. PROMPT should provide a first-class UI for managing course-level roles directly within the application, while Keycloak remains the source of truth.

1. Course Instructor & Editor Management UI

Each course settings page should include a dedicated section for managing the course team:

• List all current lecturers and editors for the course (fetched from the respective Keycloak groups)
• Add users to the lecturer or editor role by searching for them (e.g., by name or email)
• Remove users from the lecturer or editor role
• Clear visual separation between the two roles and their permissions

This UI should be accessible to course lecturers and PROMPT_Admins.

2. Custom Group Management (Future Extension)

In addition to lecturer and editor roles, courses may have custom Keycloak groups (under {SemesterTag}-{CourseName}/CustomGroups/). The UI should also display and allow management of these custom groups. This is not part of the core implementation but should be considered in the API and UI design so it can be added later without rework.

3. User Search & Lookup

To add someone as a lecturer or editor, PROMPT needs to be able to search for users in Keycloak:

• Implement a Keycloak user search endpoint that queries by name, email, or username
• Display search results with enough context to identify the right person (name, email, university login)
• Consider restricting the searchable user pool (e.g., only users who have logged into PROMPT at least once)

4. Security & Access Control

Security is the top priority for this feature. Exposing Keycloak group management through PROMPT's API creates a significant attack surface if not properly constrained.

• Strict course scoping: The server must resolve the target Keycloak group path exclusively from the course's own data (semester tag + course name). The API must never accept a raw group name or group ID from the client. The server derives the group path internally (e.g., /PROMPT/{semesterTag}-{courseName}/Lecturer) so that a caller cannot manipulate the request to target a different course's groups or system-level groups.
• Course-level authorization: Every request must be validated against the caller's role for that specific course. A lecturer of Course A must not be able to modify groups of Course B. The existing CheckAccessControlByID() middleware must be used to enforce this.
• Operation allow-list: The API should only permit adding/removing members from the Lecturer and Editor subgroups of the current course. No other Keycloak operations (group creation, deletion, role mapping, realm-level changes) should be exposed.
• Self-removal protection: Consider preventing the last lecturer of a course from removing themselves, to avoid orphaned courses with no management access.
• Input validation: All user IDs passed to the API must be validated as existing Keycloak users before any group operation is performed.

5. Permission Model

• PROMPT_Admin: Can manage lecturers and editors for any course
• Course Lecturer: Can manage both lecturers and editors for their own course. Lecturers are the administrators of their course and have full management authority over the course team.
• Changes take effect immediately in Keycloak

6. Keycloak Integration

The existing Keycloak integration already supports group management operations. This proposal extends that pattern:

• Reuse and extend the existing KeycloakRealmManager for listing/adding/removing group members
• Ensure proper error handling when Keycloak is unreachable or a user doesn't exist
• The token caching TODO in realm_manager.go should be addressed as part of this work to avoid performance issues with frequent Keycloak API calls

[rappm]

Related Issues

[rappm]

#184