Skip to content

[WIP] Start drafting sudo mode RFC #10653

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 7 commits into
base: main
Choose a base branch
from
Draft

Conversation

davidcornu
Copy link
Member

@davidcornu davidcornu commented Jun 17, 2025

Summary of the problem

#6346

Describe your changes

Rendered

@YodaLightsabr
Copy link
Contributor

A couple of thoughts:

  • I think keeping the current Login model (which you outlined as option 1) might be the best path forward. we would likely need to make some changes to make it support both initial logins and re-authentication steps, but it helps keep the controller/view logic in 1 place
  • this idea of re-authentication could be extended beyond sudo mode. instead of logging people out completely, we could just require 1 factor to re-authenticate. Google does this a lot, and it helps keep your account secure even if sensitive actions aren’t being taken.
    • I think it might be beneficial to consider both time-based expiration and inactivity-based expiration. if we implement re-authentication, we could re-authenticate after inactivity but still force a full login after a set period of time (say, 30 days).
  • for question #\2, I don’t think we should send re-authentication emails. that’s probably overkill.
  • re question #\3, I’m totally onboard with ending impersonation sessions after 2 hours.
  • for question #\4, I think it would be cool to include them inactivities.
  • your approach to #\5 seems good

Comment on lines +81 to +85
**Option 1 - Treat it as a new `Login`**

Given that we have an existing flow for authenticating users, we could treat re-authentication as a new login flow which, once complete, swaps in a new `UserSession`.

We would ideally link the new `Login` to the previous one so we can distinguish it as a re-authentication, apply different rules (e.g. only requiring one factor), and maintain a chain of `Login` records (for auditing purposes).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this a good idea, we could do something like voided_by_id to store the ID of the past Login


<img src="login_notification_email.png" width="200"/>
3. How do we want to handle sudo actions for users that are being impersonated? Is re-authenticating the impersonator enough?
- _Opinion_: We should strongly consider making this question go away by capping impersonated sessions to 2 hours. I don't think there's a use case for having these persist for longer than that.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes- this is a good idea

<img src="login_notification_email.png" width="200"/>
3. How do we want to handle sudo actions for users that are being impersonated? Is re-authenticating the impersonator enough?
- _Opinion_: We should strongly consider making this question go away by capping impersonated sessions to 2 hours. I don't think there's a use case for having these persist for longer than that.
4. Should re-authentications appear in activities?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes but with custom copy

1. We currently show users a list of their sessions including how long ago they logged in. Should we also surface information about re-authentications?

<img src="sessions.png" width="200"/>
2. We send users an email when there is a new login on their account. Would we want to do the same for re-authentications?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We normally only do this if the context is unrecognised, I think it's ok to not do this


**Open questions**

1. We currently show users a list of their sessions including how long ago they logged in. Should we also surface information about re-authentications?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes but imo we should flatten them into one Login

github-merge-queue bot pushed a commit that referenced this pull request Jun 24, 2025
## Summary of the problem

Admin users have the ability to impersonate other users for debugging
and support purposes. However while thinking through the implications of
implementing a sudo mode (see
#10653 (comment)) we
realized these impersonated sessions live for as long as the
impersonated user's `session_duration_seconds`, which could be much
longer than necessary.

## Describe your changes

- `spec/rails_helper.rb` now eagerly-loads all files in `spec/support`
so we can put shared code in there
- Added `SessionSupport` module to make writing controller tests easier
- Updated the `:user_session` factory to populate the `session_token`
field
- Updated the logic in `SessionHelper#sign_in` to cap impersonated
sessions to one hour
- Added a test for the above

---------

Co-authored-by: Manu G <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants