RBAC & SSO
Cendriix is multi-tenant: a workspace is the unit of isolation, and every person and machine that touches it carries a role. This guide covers the role model, single sign-on, and directory sync.
Built-in roles
Every workspace has four built-in roles. Roles are assigned per workspace, so the same person can be an owner of one workspace and a viewer of another.
| Name | Description |
|---|---|
owner | Full control: billing, connectors, members, policies, and deletion of the workspace. |
maintainer | Approves gated runs, edits workflows and policies, manages agents. Cannot change billing or remove the workspace. |
developer | Triggers runs, authors workflows and MCPs, reads logs. Cannot approve production gates. |
viewer | Read-only access to runs, audit log, and cost meters. Cannot trigger or approve anything. |
What each role can do
Approval gates are the sharpest edge of the role model: a gate declares the role its approver must hold. A gate set to { role: maintainer }can only be cleared by a maintainer or owner, a developer who triggered the run cannot approve their own work past it. This separation of duties is enforced by the orchestrator, not by convention, and every approval records the approver's identity in the audit log.
Assigning roles
Invite members and set roles from the dashboard or the CLI:
# Invite a member with a role
cendriix workspace member invite \
--email alice@acme.com --role maintainer
# List members and their roles
cendriix workspace member list
# Change a role
cendriix workspace member set-role \
--email alice@acme.com --role ownerSingle sign-on
Cendriix supports SAML 2.0 and OpenID Connect single sign-on with any compliant identity provider, including Okta, Microsoft Entra ID, and Google Workspace. With SSO enabled, members authenticate through your IdP and cannot create standalone passwords.
| Field | Description |
|---|---|
protocol | SAML 2.0 or OIDC. Most enterprise IdPs support both; OIDC is simpler to configure. |
metadata_url | Your IdP metadata endpoint. Cendriix reads signing certificates and endpoints from it. |
default_role | Role assigned to a member on first SSO login if no SCIM mapping applies. Defaults to viewer. |
enforce | When true, all non-service logins must go through SSO. Recommended for production workspaces. |
enforce: true. An owner account with a password is your recovery path if the IdP configuration is wrong.Directory sync (SCIM)
With SCIM 2.0 provisioning enabled, your identity provider becomes the source of truth for membership. Adding a user to a mapped group in your IdP grants the corresponding Cendriix role; removing them deprovisions access automatically. This keeps offboarding immediate and removes the risk of orphaned accounts.
Service accounts
Machines authenticate with service accounts, not member identities. A service account carries a role and issues bearer tokens for the API and CLI. Use service accounts for CI pipelines and automation, never a personal token. Tokens can be scoped read-only or read-write and revoked individually from Workspace Settings.
# Create a read-write service account for CI
cendriix workspace service-account create \
--name ci-pipeline --role developer
# Authenticate the CLI with its token in CI
cendriix login --token $CENDRIIX_TOKEN