Users & Groups (RBAC)

Snitcher enforces a central permission set. A permission is (Action, ResourceType[, Scope]); every guarded command/query declares the permission it requires, and a user holds a permission if any of their groups grants it. Manage this under Administration.

Permissions

Permissions are built from an action (Create · Read · Update · Delete) applied to a resource type, with an optional scope for finer-grained grants:

Resource type	Actions	Scoping
Dashboard	Read	—
Target	Create · Read · Update · Delete	All / by Label / by Resource ID
Scout	Create · Read · Update · Delete	All / by Label
Alerting	Create · Read · Update · Delete	All / by Label
StatusPage	Create · Read · Update · Delete	All
Group	Create · Read · Update · Delete	All
User	Create · Read · Update · Delete · Reset password	All
AuditLog	Read	All
Settings	Read · Update	All

A request without the required permission is rejected with HTTP 403 (and audit-logged as Denied); the UI also hides nav items and actions a user can't use.

Label-scoped grants

A Target, Scout, or Alerting grant can be scoped to only the targets, Scouts, or alerting objects (alert rules + alerters) carrying certain labels — matched by OR across the grant's label set — instead of every one of that type in the system. This lets you give a team "manage" access to just their own services without full admin on that resource type. A Target grant can also be scoped to a specific resource ID for one-off delegation (id-scoping is Target-only — Scout and Alerting grants scope by label or All).

Your Target read scope also follows you into features that surface targets indirectly, even though those features aren't separately scopable in the table above: the Dashboard overview (resource tallies, recent events, recent alerts) and the Maintenance windows list only show targets — and windows/alerts tied to them — within your Target read scope. A maintenance window covering no specific targets (a global window) is always visible, same as it applies to every target regardless of scope. Assigning a Scout to resources (Scout → Assign resources) also checks each requested resource against your Target:Update scope, so a narrowly-scoped Scout admin can't re-point targets outside their scope.

Groups

Groups are DB-driven — create as many as you like under Administration → Groups, each with a name, description, and an arbitrary list of grants (resource type + action toggles + scope picker). A user's effective permissions are the union across all their groups.

Three groups are seeded on first start:

• Administrators — holds every permission. This is the only immutable group: it's shown read-only and can't be edited or deleted, and the local admin belongs to it.
• Operators and Viewers — convenience starting points for a typical "manage things" and a read-only role. Unlike Administrators these are ordinary groups: open each under Administration → Groups to see its exact grants, and edit, rename, or delete it to fit your setup.

Users

• The local admin (Auth__Username) is seeded into Administrators and holds every permission.
• OIDC users are provisioned automatically on first sign-in (see SSO with OIDC); their group membership is synced from the identity provider's groups claim by matching group names. So to grant an SSO user "Operators" access, put them in an "Operators" group in your IdP and create a DB group named Operators with the desired permissions.
• Each user has a notification email (defaults to their verified provider/login email, editable) and display preferences (theme, time format, date order).
• Admins can assign groups, send a password reset link, or delete a user. Deleting an OIDC user only removes the local record — they're re-provisioned automatically the next time they sign in through the identity provider.
• Sending a password reset link requires the fine-grained Reset password permission on User (held by Administrators by default) — deliberately separate from User: Update, so delegating user management does not let someone take over another account. The admin never sets the password: Snitcher mails the account owner a single-use, expiring link (lifetime configurable under Security settings, default 1 hour), and the owner sets their own new password via that link. Local accounts only (OIDC users manage their password with their IdP).
• A signed-out user doesn't have to wait for an admin: the "Forgot password?" link on the sign-in page requests the same kind of link themselves, by entering their username or email and solving the captcha. The response is always the same generic confirmation ("If this email is registered, a link has been sent.") regardless of whether the account exists, is local, or is OIDC — Snitcher never confirms or denies account existence over this endpoint. An OIDC account still gets an email, but it points them to their identity provider instead of a reset link.
• Users can self-service: change their own password, update their notification email/profile, and update their own display settings. Changing the notification email sends a notice with a single-use revert link to the previous address; using it restores the old email and forces a fresh password reset — so an attacker who changes the email and resets the password is locked back out when the real owner reverts.

The Administration → Users page lists everyone who has signed in, with a capability list per user showing which group grants which permission, last login, and group-membership toggles.