Identity and roles

Sign-in, the three managed roles, and how access is granted.

1 min read Updated Oct 21, 2026 Sentinel Platform Team
identityoidcrolesrbacmemberssso

Sign-in #

Sign-in is handled by your identity provider over OpenID Connect. Members authenticate there and arrive at Sentinel with an identity.

  • Organisation — which organisation the member belongs to.
  • Email — the member's identity.
  • Client — which application asked for the token.
  • Groups — group claims from your provider.

Managed roles #

Every organisation has three managed roles:

  • Read-only — can see everything, change nothing.
  • Standard — can work with telemetry and the resources built on it.
  • Admin — can additionally manage members, roles and organisation settings.

Custom roles #

Custom roles narrow a member's access to exactly the permissions a job needs. Start from a managed role and remove what the role does not require.

Give each job its own role. A support engineer who only reads dashboards does not need an admin role, and does not need one to do the job.

Group synchronisation #

Groups from your identity provider can be mapped to roles, so membership follows the directory rather than a hand-maintained list.

  • Map a provider group to a managed or custom role.
  • Members in the group receive the role the next time they sign in.
  • Removing someone from the group removes the role on their next sign-in.

Existing members are managed here

Group synchronisation grants roles to members who already exist. Adding a person to a group does not create an account, and reactivating a removed member is done from the members page.

Applications #

Applications are non-human identities with their own key, used by automation that needs to act as somebody without being one.

  • An application key carries the same scopes and roles as a member.
  • Revoking an application key stops every automation using it.
  • Give each automation its own application so it can be revoked alone.

Reviewing access #

  • List members and remove those who have left.
  • Review custom roles for permissions a role no longer needs.
  • Check application keys against the automations you still run.

Onward #

The roles here decide what a person may do; Scoped API keys does the same for a workload, and Organisations and data isolation covers where that data sits. Sign-in and group synchronisation are described in Ingestion controls for the telemetry side, and every grant and revocation is recorded in the Audit trail.