[BUG] Self management of roles

[dustinbyrne]

Users with administrative privileges are currently able to modify their own roles. The expected behavior is that an admin should not have the ability to change their own roles to prevent potential misuse, such as elevating permissions beyond intended limits or removing restrictions placed by other administrators.

Any role change requests involving their account should be disabled or restricted by the system.

[dustinbyrne]

Role Management in Waltz

Introduction

This document describes the role management process within the Waltz application and addresses a specific issue regarding the modification of roles by administrative users.

Current Behavior

Currently, users with administrative privileges possess the ability to modify their own roles. This functionality potentially allows administrators to elevate their permissions beyond the intended limits or to remove restrictions placed by other administrators, which poses a risk of misuse.

Expected Behavior

To prevent potential misuse, a system restriction should be enforced to disable or restrict any role change requests involving an administrator's own account. Ensuring that administrators cannot self-modify their roles preserves the integrity of role assignments and protects against unauthorized privilege escalation.

Sequence Diagram of Role Management Flow

The sequence diagram below illustrates the flow for updating user roles within the Waltz application:

sequenceDiagram
    participant Client as "HTTP Client"
    participant API as "API Endpoint"
    participant WebUtils as "WebUtilities"
    participant UserRoleService as "UserRoleService"
    participant UserRoleDao as "UserRoleDao"

    Client->>API: POST /api/user/admin/roles
    activate API

    API->>WebUtils: requireAnyRole(ADMIN)
    activate WebUtils
    WebUtils->>UserRoleService: hasAnyRole(userName, ADMIN)
    activate UserRoleService
    UserRoleService->>UserRoleDao: getUserRoles(userName)
    activate UserRoleDao
    UserRoleDao-->>UserRoleService: userRoles
    deactivate UserRoleDao
    UserRoleService-->>WebUtils: rolesVerified
    deactivate UserRoleService
    WebUtils-->>API: roleCheckPassed
    deactivate WebUtils

    API->>UserRoleService: updateRoles(userName, newRoles)
    activate UserRoleService
    UserRoleService->>UserRoleDao: replaceRoles(usersAndRoles)
    activate UserRoleDao
    UserRoleDao-->>UserRoleService: updatedRolesCount
    deactivate UserRoleDao
    UserRoleService-->>API: rolesUpdated
    deactivate UserRoleService

    API-->>Client: Success/Failure Response
    deactivate API

Action Plan

To enhance the security and governance of role management, the following action steps are recommended:

• Implement restrictions to disable role modification for an admin's own account.
• Monitor role change activities and maintain auditing logs to trace changes.
• Enforce additional role validation checks in the service layer to prevent unauthorized updates.

Conclusion

By addressing these concerns and implementing the suggested restrictions, the Waltz application can ensure a more secure and controlled role management process.