Feature: unlocking privileged operations
Allow standard sessions sign-ins to perform privileged actions.
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.
- Sign in as a standard user
- Perform an action to escalate privilege
- Pass credential check (usually in the form of a password prompt)
- Accomplish system task that requires administrator privileges
- (Optional) Accomplish additional system tasks
- (Optional) De-escalate privilege
- Only needed when signed-in without privileged operations checked
- 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)?
- It may make sense to move the checkbox from the sign-in page to a saved user-pref for those who do not have NOPASSWD rights (which would prompt when enabling)
The following are the different ways to handle privellaged information and actions within Cockpit. We should evaluate what makes sense on a case-by-case basis, but opt for a consistent default.
Hide non-admin actions
- Advantage: For those signed in to view normal-user-only, they'd never see something they cannot interact with.
- Disadvantage: UI elements and locations shift depending on if someone has simple rights versus admin rights.
- Disadvantage: "I could swear I saw this option before" confusion.
- Disadvantage: It renders parts of documentation more complex or irrelevant.
- Too many drawbacks, so I strongly suggest not using this option, therefore it gets a strike out.
- Have admin-only items displayed, but disabled
- Advantage: UI consistency, even if some items cannot be manipulated
- Disadvantage: One would have to unlock before performing actions
- Hybrid Placeholders
- Actual items could be hidden, with a simplified version displayed
- Has the advantages of both #1 & #2 (but still the disadvantage of #2, but none of #1)
Depending on the UI in Cockpit, I would suggest displaying a less featureful version of UI when appropriate (#2), or at least show a placeholder with relevant information (#3). I would suggest not hiding information as the disadvantages are too severe (#1).
It may get a bit trickier with some features within Cockpit, however. Example: The tuned-based performance mode is not displayed properly when in a restricted session. What label can be used for it, if it is not possible to know what mode tuned is in without administration privilege?
- Global Unlock / Lock button & status
- In the top-right of Cockpit, next to the dropdown
- Alternatively, inside the dropdown itself (although it would be buried)
- Not visible when signed in with the privileged checkbox on the sign-in screen
- Disabled UI when not signed in should have a contextual way to trigger the escalation prompt
- In some cases, the entire widget could be selectable, but text should probably be selectable
- There could be a local unlock icon (but this would be redundant)
- For things that do have action buttons, the escalation prompt can display after performing the action
- However, this has the issue of not knowing if one would get the prompt or not when clicking on any action (making it feel like a game of chance)
- 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.
WIP
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).
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.
Note: The mockup is missing a message stating the reason why the authentication prompt is displayed. It's probably a good idea to state why the prompt appeared. (I will add this.)
As this affects multiple parts of Cockpit, more examples will be coming soon.
TODO: Add current auth dialog UI and additionally some non-GNOME examples.
Which parts of Cockpit should require admin rights?
- Docker
- Tuned (even for just viewing the profile)
- ??? (Everyone: Please expand this list)
Oddly, it seems things like rebooting do not require admin rights. Is this intentional?
-
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.