Feature: unlocking privileged operations - cockpit-project/cockpit GitHub Wiki

Goal

Allow standard sessions sign-ins to perform privileged actions.

Notes

Stories

Phillip J. Fry is a junior sysadmin at his company who signs into his servers remotely with a Web browser. Usually, he only checks the status on servers, but once in a while, he needs to do perform tasks that require additional privileges.

Phillip signs into Cockpit, without checking the box to "Reuse my password for privileged tasks", as he's planning on checking the system status quickly. While signed in, he notices a problem with resource usage and, rather than spending hours debugging the problem, decides to reboot the server for a quick fix.

Signing out and signing back in with privileges, especially across several servers, is arduous, so Phillip is happy Cockpit lets him quickly gain rights to reboot the server.

Workflows

  1. Sign in as a standard user
  2. Perform an action to escalate privilege
  3. Pass credential check (usually in the form of a password prompt)
  4. Accomplish system task that requires administrator privileges
  5. (Optional) Accomplish additional system tasks
  6. (Optional) De-escalate privilege

Solution

On a first pass, we should concentrate on handling unlocking in a global manner, with an unlock button at the top of Cockpit.

Ideally, it would be best to handle this at a component level as well, to make it more obvious when things need to be unlocked. A prime example of this is the Docker page, which is top-level and also requires admin access to event display anything.

As third-party plug-ins exist, we will always need to handle things that require admin access in a non-admin session.

Later on, we should modify additional components of Cockpit to be aware of the necessity of admin-rights to perform tasks and provide alternate UIs, by either displaying information with some disabled parts or showing placeholders. For the time being, however, only prominent parts of Cockpit (such as the Docker section) should have special handling of admin rights.

UI implementation across Cockpit

  • Global Unlock / Lock button & status
    • In the top-right of Cockpit, next to the dropdown
    • Not visible when signed in with the privileged checkbox on the sign-in screen
  • An escalation prompt
    • Password
    • Would a non-password authentication method be used? (2FA, Kerberos, etc.)
    • Would the auth be saved for the session, or should there be a one-off mode?
      • (I would suggest the auth being saved for the session, which is currently the behavior when signing in with the sign-in page auth checkbox.)
      • Do not re-display when switching from unlocked to locked to unlocked, if saved for the session.
  • Enhancements: When not signed in, there should be alternative UI have a contextual way to trigger the escalation prompt
    • There can be an action combines escalates privilege and the requested action
      • it should not simply unlock, as there's already an action for this
      • it must be clear that admin rights are required before performing the action
      • it must perform the action after unlocking, instead of requiring another step
    • This will require additional work, and we cannot rely on widget modifications for all of Cockpit, especially 3rd party apps
    • In most cases, it will display a similar UI as full admin mode, but in some cases it may make sense to display and alternate placeholder UI instead

Mockups

Contextual unlocking (for Docker)

Top-right unlock button

This mockup shows a minor modification to allow unlock access for Docker by authenticating. It is possible to unlock in the top-right before accessing the Docker page. Also, unlocking in the top right should automatically resolve the access rights to affected components (the Docker page being the example here).

Unlock for Docker

Password prompt (from the unlock button)

It's only a simple password prompt right now. There is no "remember" checkbox, as it should switch to admin privileges once per session, until everything is (optionally) manually locked in the top-right of Cockpit.

The password entry should be automatically focused. Enter should submit the password and hitting escape should be mapped to cancel. The × to close the dialog should also be mapped to cancel.

Unlocking lasts the entire session, until:

  • it is manually locked
  • the user logs out
  • the session times out

This dialog answers the questions:

  1. What happened?
  2. How long will this last? (As a many, but not all, password prompts are one-time, we're basically stating the above list in a simple manner, with an assumption that signing)

Unlock dialog, for Docker

Not-yet-unlocked Animation

Some parts of Cockpit will be locked by default and cockpit must be unlocked before proceeding.

In these instances, it can be helpful to unlock Cockpit from the UI themselves, but it would require extra work to make sure there is a fallback UI and a means for unlocking.

In the default case, there should be a trigger that highlights the unlock button in the top right. This should be done through a means to attract attention.

Example mockup of animation: http://codepen.io/garrett/full/qRjvZw/

This example has a blinking action. We may prefer a wiggling/bouncing effect — however, a side-to-side motion generally expresses a negative meaning, but may vary from culture to culture (like shaking one's head "no"), so a up/down bounce may be preferable (if the blinking action is not acceptable).

Password prompt (from locked UI)

Similar to the above, this dialog answers similar questions, with a few more:

  1. What happened?
  2. Where is this coming from?
  3. How long will this last? (As a many, but not all, password prompts are one-time)

As this is a secondary step, the mockup is still To-Be-Done.

Prior art

GNOME Settings

GNOME Settings

GNOME Auth

TODO: Add current auth dialog UI

Windows

Consent prompt for administrators

This prevents apps from automatically running as admin, but still allows them to perform admin tasks when acknowledged:

Windows 7 consent prompt

Credential prompt

Displayed when a password or some other (pluggable) auth is required:

Windows 7 credential prompt

Mac OS X

OS X users dialog

OS X users dialog re-lock

Open questions

Which parts of Cockpit should require admin rights?

  1. Docker
  2. Tuned (even for just viewing the profile)
  3. ??? (Everyone: Please expand this list)

Oddly, it seems things like rebooting do not require admin rights. Is this intentional?

How are error messages handled?

When there are permission error messages, is that checked and reported upon across Cockpit, or does the component handle the error message itself?

In other words, is possible to hook into the error messages to be notified via an animation of the unlock button to unlock?

Action items

  1. Implement global unlock/re-lock
  • also a nudge notification (animation), with an API to start it as well as hooking it into this-need-admin-access error messages
  1. Enhance critical admin-requiring UI (Docker page, ...?)
  2. Future: Review Cockpit to identify places that require admin access
  3. Future: Modify UI to improve workflow of identified
  4. Future: Add integration info to dev docs for 3rd parties

Feedback

  • Question found above: Do we want to remove the sign-in checkbox from the sign-in page and always have escalation status (such as in the top-right)?

    • Cockpit is an admin console. Because of this focus, and that a majority of users who log into Cockpit will be performing privileged tasks, I think we shouldn't remove this from the log in page. We should make it easy for people to start with privileges if they so choose.

  • Feedback: On Implementation Side

    • While the 'Unlock' button on the docker page example above is sound, it is not always possible to represent the fact that the action failed due to privileges in the UI. We need a general approach perhaps in addition to context specific actions.
    • I would like to suggest that the [Locked] section on the top blinks twice each time the bridge tries to perform a privileged action but we are unable to. Or it could become bold, or red, or otherwise draw attention.
      • I was also thinking about animating it a bit too.
      • Other solutions can include subtle indicators that a component is locked... and it's not even mutually exclusive with the animated top indicator.
      • There also could be a little popover widget coming down from the locked area at the top of the page, which would increase the visibility and actionable region to initiate the auth prompt.