Skip to content

feat: user mode in session for admins

What does this MR do?

Migrated from gitlab-foss!31619 (closed) and replaces original gitlab-foss!17987 (closed)

It is a second attempt at implementing a similar functionality as originally proposed in gitlab-foss!17987 (closed), forcing admin users to re-authenticate for administrative (i.e. potentially dangerous) operations. This allows admins to use their accounts as normal users and make them activate admin mode on purpose whenever they need to perform administrative tasks.

In this iteration, we add a user mode button to the topbar, available to administrators of the platform. This allows admins to enable / disable their superpowers:

  • By default, an authenticated admin is logged-in with user mode, no special rights
  • Clicking on the new button or accessing any part of the UI requiring admin rights via the EnforcesAdminAuthentication concern (e.g. the /admin endpoints) will trigger a re-authentication form, that when successful will enable the admin mode

We do this by storing in the user session an admin mode timestamp after the user successfully re-authenticates. The value is stored in the shared session, so an admin enabling the mode in a session will see it in the others.

For a more detailed rationale about the need for this functionality, please see gitlab-foss!17987 (comment 80014893)

The implementation uses the ideas discussed in gitlab-foss!17987 (comment 150628711):

  • Hidden behind a feature flag :user_mode_in_session
  • The base ApplicationController offers a helper method current_user_mode that returns an object that checks all active sessions of the logged in user and checks whether there's any with admin mode active.
  • A new Admin::SessionsController controller offers operations for creating/deleting administrative sessions: check that the user is in fact an admin, offer a re-authentication form, and when successful add a new session entry that stores the timestamp at which the admin mode was enabled. The admin mode can be manually disabled in the web ui, or it will automatically expire after 6 hours.
  • The new infra for sessions Gitlab::Session and Gitlab::NamespacedSessionStore is used to store the user mode
  • Sessionless authentication methods (e.g. PATs) are supported by automatically enabling admin mode in the SessionlessAuthentication concern
  • API calls have admin mode enabled on all requests by setting a temporary session object for the duration of the request. This is not synced to the ActiveSession store.

Limitations / TODOs

  • The UI for re-authentication is just a prototype and might need significant rework. Specifically the "admin mode" button and the re-authenticate form
  • Since a significant number of specs fail when admin mode is not enabled by default, we have enabled it with a flag for all specs. See #31511 (closed) for a follow-up issue.
  • Additionally and for future use in #31511 (closed), admin mode is made available on any test requiring it by using the new helper AdminModeHelper#enable_admin_mode!(user) for a specific user.
  • In order for admins to use this functionality, they are required to have a password set. #31326 (closed) was created to track this issue.

Thanks to @rroger for the first implementation attempt and also for valuable ideas in the original MR, re-used in here.

The development of this MR is sponsored by siemens (/cc @bufferoverflow)

Screenshots:

image image image image

Does this MR meet the acceptance criteria?

Conformity

Performance and testing

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

  • Label as security and @ mention @gitlab-com/gl-security/appsec
  • The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
  • Security reports checked/validated by a reviewer from the AppSec team
Edited by Diego Louzán

Merge request reports