Users, roles and capabilities
Access in Overseer rests on three things that are kept apart - your account, the role you hold and the capabilities that role carries. This page explains each one and the safeguards around them.
Three separate questions
Administration in Overseer answers three questions and keeps them apart.
- Who you are. That is your account. It identifies you, and what you do is recorded against it.
- What you may do. That is your role. A role is a set of capabilities, and a capability is a named trust decision such as "may deploy software to a computer". A capability is never granted to a person. It is granted to a role, and people hold roles.
- Where you may do it. That is your access by client. It is set separately from your role, and it either covers every client or is limited to particular clients.
Accounts
People, under Show more, lists the people Overseer knows about. A person becomes a user when they are given an account and a role.
Accounts themselves are managed in the suite's Settings. Each account holds a role.
Managing accounts is reserved for the Administrator role. A control you are not allowed to use is absent from the screen, instead of being shown and then refused.
An Administrator's actions on an account include:
- Set role. Moves the account onto any role. It takes effect on that person's next request, because the role is read every time.
- Revoke. Ends all current access at once. Use it when access must stop immediately, for example when a credential may have been stolen.
Roles
A role is a name that capabilities attach to. It carries no permissions of its own. The capability grid decides what the name means.
Two roles are built in and cannot be deleted:
- Administrator holds every capability, always, and cannot be edited. Permissions are the one place where a mistake could stop you from fixing that mistake, so one role must be impossible to lock out.
- Technician is the ordinary technician role.
Every other role, such as a read-only viewer, is one you create.
- Naming. Give a role a description as well as a name. The description is what a later Administrator reads when deciding whether to put someone on it.
- Created empty. A new role starts with nothing. It is never copied from an existing role, so it can never arrive holding a capability that nobody chose to give it.
- No nesting. Roles do not inherit from each other. Each role holds exactly the capabilities chosen for it.
- Fixed name. To rename a role, create the new one, move the accounts across and delete the old one.
- Deleting. A role can be deleted only when no account holds it. If accounts still hold it, Overseer refuses, says how many, and asks you to move them first.
Capabilities
A capability is a named trust decision. Capabilities are not a permission for every screen. They are the small number of decisions where getting it wrong matters, each one named so that a refusal can say what was required.
Capabilities are shown as a grid of roles against capabilities. Anyone with an account can read the grid. Only an Administrator can change it.
Capabilities decide, for example, whether a role may:
- create an enrolment token, which lets a new computer join, or revoke one
- retire a computer, or restore one
- act on computers
- curate the library by adding, editing and removing software and tasks
- write one deployment that reaches every client at once
- read back a computer's local administrator password
A capability says what a role may do. Which clients a person may do it for is set separately: particular clients, or every client.
Two capabilities to grant with care
Acting on computers is the widest capability. Underneath it is the ability to run code on a client's computer. It covers deployments, schedules, onboarding, restart policy, maintenance windows, standing authorisations and tags. If you are building a restricted role, this is the capability that quietly makes it unrestricted.
Reaching every client is kept separate. Reaching one client and reaching all of them are different decisions. A role that holds the first does not gain the second unless you grant it.
Safeguards that cannot be switched off
- You cannot lock yourself out. You cannot change your own role or delete your own account, and the last remaining Administrator cannot be demoted or deleted.
- A role cannot give itself more power. Only an Administrator changes the capability grid, so no other role can edit its own capabilities.
- Nothing is granted by accident. A new role starts empty, and every capability it holds was chosen for it.
Keeping access in good order
- Grant the least that does the job. Add only the capabilities the work needs.
- Review who holds what. Check accounts and their roles at regular intervals. Account and capability changes are recorded in the audit log.
- Remove access promptly. When someone leaves, revoke their access straight away.