Administer
Roles and access
Access to MonitOps is by role, and roles are enforced in every query path, API call and copilot tool. A person has one product role in a tenant.
Roles#
| Role | Can |
|---|---|
viewer | Read incidents, service map and dashboards; use the copilot within their access |
operator | Acknowledge and resolve incidents; request actions |
approver | Approve or reject requested actions |
admin | Manage sources, declared systems, alarm definitions, destinations, dashboards and the action catalogue |
The requester of an action cannot approve their own request (see Actions). A viewer who asks the copilot for data their role cannot see is refused (see Copilot).
Source administration#
| Operation | Viewer | Operator | Admin |
|---|---|---|---|
| Read source configuration | Yes | Yes | Yes |
| Create, update, enable or disable a source | No | No | Yes |
| List, issue or revoke source credentials | No | No | Yes |
| Revoke your own session | Yes | Yes | Yes |
Configuring the tenant, the identity provider, members and their roles is not done in the browser. It is set explicitly when your deployment is onboarded.
Sign-in#
MonitOps supports single sign-on with OIDC and SAML 2.0 through your identity provider.
- An identity provider is bound to one tenant. Administrators configure its callback addresses, issuer details or SAML metadata, and signing certificates.
- Signatures, issuer, audience and expiry are verified on sign-in, and a replayed SAML response is rejected.
- Access is provisioned explicitly. A matching email domain does not admit anyone to a tenant, and a role claim from your identity provider does not grant a role on its own. Mapping an identity provider group to a role is explicit and applies to one tenant.
- Local accounts exist only for break-glass access. A local account is not a fallback for a tenant that requires single sign-on.
- Source credentials are not browser sessions, and tokens from your identity provider are not accepted as source credentials (see Credentials).
Sessions#
Sessions are validated by the server. They have idle and absolute timeouts, and one active session per user, with an exception for operations-centre wall screens. Logout and administrative revocation end the session. A change to a person's membership or role applies to their next request, and when MonitOps cannot validate a session or membership it denies access instead of continuing.
Audit#
Every query, recommendation, approval and action is recorded with identity and time. The incident timeline is the audit trail for what happened to an incident (see Incidents). Authentication and authorisation changes are recorded without credentials or tokens.
What you see in the console#
The copilot refuses requests that go beyond your role and offers what you can see.
Limits and defaults#
- One role per person in a tenant.
- Tenant and role are checked on every query, API call and copilot tool; a tenant selected in the browser is a request, not proof of membership.
Failure states#
| State | Result |
|---|---|
| Invalid signature, wrong issuer or audience, expired or replayed response | Sign-in fails; no session is created |
| Unknown user or unapproved provisioning | Sign-in is refused |
| Identity provider or storage failure | Access is denied, never opened |
| Membership removed or role changed | Applies to the next request |
Related#
Last updated October 2026