Roles

Roles bundle permissions. User roles (auth-chain-derived) versus Owner roles (operator-curated), and the precedence rule that resolves which wins for a given signed-in user.

A Role is a named bundle of permissions. ODD Platform has two distinct kinds of Role — User roles (derived from the auth chain at sign-in time) and Owner roles (operator-curated bundles attached to Owner entities) — and a precedence rule that resolves which kind wins for a given signed-in user.

User roles

There are two user roles:

• USER — a regular user with no permissions by default.

• ADMIN — an administrator with every permission.

User-role assignment is derived from your authentication mode's configuration: the platform inspects the auth-mode-specific group / role / principal mapping (Cognito groups, GitHub teams, Azure roles, LDAP groups, Google admin-principals, etc.) at sign-in time and assigns either ADMIN or USER accordingly. For the full per-provider matrix of how admin promotion works, see Admin promotion across providers.

Owner roles

Owner roles are operator-curated bundles attached to Owner entities, managed at Management → Roles. Unlike User roles (two fixed values: ADMIN / USER), Owner roles are arbitrary — operators define them per deployment and compose the permissions each role bundle should carry.

Attaching a Role to an Owner

Role-to-Owner attachment happens on the Management → Owners surface — open the Owner row, edit it, and pick the Roles to attach. See Owners → Owner roles for the operator workflow. The ROLE_CREATE / ROLE_UPDATE / ROLE_DELETE permissions gate role-bundle authoring; the OWNER_UPDATE permission gates the role-attachment action itself (it is a write to the Owner entity).

Precedence: Owner roles override User roles

When a signed-in user is bound to an Owner (via the User-owner association workflow) and that Owner carries at least one role, the user's effective permissions come from the Owner's roles — not from the User role the auth chain assigned at sign-in. A user who signed in as ADMIN and then binds to an Owner that carries only a Data Engineer role loses the ADMIN privilege and runs with the Data Engineer permission bundle.

The override is conditional on the Owner having roles. If the bound Owner has no roles attached, the platform falls back to the User role the auth chain assigned at sign-in — so binding to a zero-role Owner does not strip a signed-in ADMIN's privileges; that user keeps ADMIN. The override applies only when the Owner's role set is non-empty.

For a non-empty Owner role set the override is permanent for the lifetime of the binding: only an unbind (or a re-bind to a different Owner) restores or changes the effective permission set.

Under auth.type=DISABLED authorization is not enforced at all. Neither User roles nor Owner roles are consulted, and every request runs unrestricted — regardless of any Owner binding or role attachment. The precedence rules above take effect only when authentication is enabled (LOGIN_FORM, OAUTH2, or LDAP). DISABLED is the shipped default; see Disable authentication and switch auth.type to an enforced mode before exposing the platform on any reachable network.

Setting up an initial admin

To set up a signed-in user who should have full ADMIN privileges through the catalog side, do both halves explicitly:

1. Create an Owner with an ADMIN-equivalent Role bundle attached. Either create a new Role on Management → Roles that carries ALL permissions, or pick an existing ADMIN-equivalent Role; then create the Owner on Management → Owners with that Role attached. Skipping this step and trying to "rely on" the user's sign-in ADMIN authority does not work once the user binds to any Owner that lacks ADMIN — the precedence rule above strips the auth-mode ADMIN at bind time.

2. Bind the user to that Owner. The recommended admin path is the Create association button on Management → Associations (gated by OWNER_RELATION_MANAGE) — this is the admin-direct-bind path that writes the binding immediately, without going through the request-and-approve workflow. See User-owner association → Creating a binding directly for the full form fields and behaviour.

The sequence matters: bind the user to an Owner that already carries the ADMIN role bundle. If you bind first and attach the Role second, the binding is effective immediately and the user runs without ADMIN during the gap.

Where to next

• Permissions — the catalog of permission keys you can bundle into Role definitions.

• Policies — the JSON permission grants attached to owners through roles; note that deleting a policy is blocked while any role is still bound to it — detach it from every role first (full note on that page).

• Owners — how Owner entities work and the per-page caveat list for Owner CRUD.

• User-owner association — the binding workflow that triggers the Owner-role-supersedes-User-role precedence.

• Admin promotion across providers — for the per-auth-mode story of how the User role is initially assigned.