Documentation

Users and permissions.

Two separate things decide what a person can do in your account. A permission tier decides which operations their session is allowed to perform. A partition decides which compartment a key belongs to. They are orthogonal: adding somebody to a partition grants them nothing, and giving them a tier does not move any key.

The tables on this page are generated from the scope definitions your session is authorized against, not written by hand. When a capability is added to the product, this page changes in the same build. There are currently 32 scopes across 4 tiers.

The four tiers

There are four, and the set is closed. Nothing else in your directory is a permission tier, and no custom tier can be created.

What each tier can do

Every operation the API exposes is gated by a named scope. A tier is nothing more than the set of scopes it carries. The matrix below is the whole permission model: if a scope is marked for a tier, a session holding that tier may perform it, and if it is not, the API refuses the request.

Administrative scopes are split into a read variant and a write variant. Holding the write variant implies the read: a tier granted admin:partitions:write can list partitions without also needing admin:partitions:read.

Marked cells are granted. Unmarked cells are refused.

Holding several tiers

A user may hold more than one tier. The session then receives the union of every tier held, not the highest one. The tiers are not ranked at sign-in time, so there is no precedence contest to reason about: if any tier you hold grants a scope, you have it.

The practical consequence is that granting a second tier can only ever widen a session and can never narrow it. That is what makes adding a tier a safe action: you cannot accidentally take a capability away from somebody by giving them another one.

To reduce what a user can do, remove a tier. Removing all of them leaves them with nothing, which is covered next.

A user with no tier

A user who holds no tier gets no permissions at all. This is deliberate and it fails closed: the session is issued with an empty capability set rather than a default one, so a misconfigured or half-provisioned account can never inherit access by accident.

What that looks like in practice: the person signs in successfully and the console loads, but every action is refused. The Users tab shows no tier against their name, and the tier editor warns you before you save an empty selection.

This is the normal state of a brand new federated user. Single sign-on proves who somebody is; it does not decide what they may do. See federated users arrive with no permissions.

Partitions are not permissions

A partition is a named compartment for organizing keys, for example firmware-signing or payments. Every key carries exactly one partition, keys land in default unless you say otherwise, and you can list keys by partition. Partition names are lowercase letters, digits and hyphens, up to 64 characters.

Partition membership records which compartments a person is associated with. It is a separate axis from permission, managed on its own tab, and saving a user’s tiers never changes it. Be precise about what it buys you today: a partition organizes and labels keys, and it does not by itself restrict which keys an authorized session can call. A user who holds a tier granting crypto:sign can sign with any key in the account, regardless of which partition either of them sits in. If you need a hard boundary between two sets of keys, the boundary that exists is the account: SanctiKey puts exactly one tenant in one account, and a second account is a second, fully separate deployment.

You cannot change your own tier

An administrator changing their own permission tiers is refused. The check compares the caller against the target user before anything is written, and the request fails with Admins cannot modify their own permission tiers. It applies to the API and to the console equally, because the console calls the same endpoint.

The reason is self-escalation. Without the guard, any account that could edit users could promote itself, which collapses every tier below the top one into the top one. With it, raising your own privileges requires a second administrator, and that second action is recorded in the audit trail against their name.

Two operational consequences worth planning for. Keep at least two SystemAdministrators, or you will have nobody able to change the one you have. And if you need to lower your own tier, ask the other administrator to do it.

Assigning a tier

Tier assignment requires the SystemAdministrators tier. In the console:

1. 1Open Admin and select the Users tab. Each row shows the user’s email, status, current tiers, and creation date.
2. 2Select Groups on their row. The row expands into a panel with three parts: Permission Tiers, Partitions (read only here), and, if they have one, the directory-managed group.
3. 3Select any combination of the four tiers. The selection is a toggle, not a radio button, because tiers are additive. Selecting none is allowed and leaves the user with no permissions; the panel warns you when you are about to do that.
4. 4Select Save Tiers. Only tier membership is written. Partitions and the directory-managed group are untouched by this action, by construction rather than by convention.
5. 5Have the user sign in again. Permissions are fixed into their session when it is issued, so a change made while somebody is signed in does not reach the session they are already holding.

Every tier change is written to the audit trail with the identity of the administrator who made it, the target user, and the tiers added and removed.