Authentication & authorization
Canyon plugs into your existing identity provider via SAML 2.0 or OIDC. Once signed in, users carry their roles and attributes into every generated app. Permissions are enforced at the semantic data layer, down to the row and column.
Identity & SSO
Users sign in with the identity provider you already run. Canyon supports SAML 2.0 and OIDC out of the box, so any major IdP slots in without custom work. Groups and attributes from your IdP flow through to Canyon and become the source of truth for every permission decision.
Supported identity providers
How identity flows through Canyon
┌──────────────────────────────────────────────────────────────────────────────┐ │ IDENTITY FLOW │ │ │ │ User ──► Your IdP (Okta / Entra ID / Google / …) ──► Canyon │ │ │ │ │ ▼ │ │ Identity, groups, attributes │ │ │ │ │ ┌───────────────────────────────────────────┴────────────────┐ │ │ ▼ ▼ │ │ RBAC (roles) ABAC (attrs) │ │ │ │ │ │ └───────────────────────────────┬────────────────────────────┘ │ │ ▼ │ │ Canyon semantic data layer enforces │ │ row- and column-level permissions on │ │ every query, for every generated app. │ │ │ │ • Short-lived tokens, rotated automatically │ │ • Every access logged to an immutable audit trail │ │ • Service accounts inherit the same RBAC/ABAC rules │ └──────────────────────────────────────────────────────────────────────────────┘
Session & token hygiene
- Short-lived access tokens, rotated automatically. No long-lived secrets on devices.
- Refresh-token rotation with reuse detection: a stolen refresh token invalidates the entire session family.
- Explicit session revocation from the admin console; effective within seconds across every app.
- Service and agent accounts inherit the same identity and scope model as human users.
Roles & permissions
Canyon is multi-tenant by design. A user may belong to any number of organizations with different roles in each. Organizations contain teams, teams contain projects, and every project carries its own role assignment. Permissions resolve to the most specific scope — a projectEDITOR role overrides an organization MEMBER role.
Organization roles
| Role | Permissions |
|---|---|
| OWNER | Full control, including delete. |
| ADMIN | Manage members and teams. |
| MEMBER | Create projects and apps. |
| VIEWER | Read-only access. |
Project roles
| Role | Permissions |
|---|---|
| OWNER | Full control plus sharing. |
| EDITOR | Read and modify the app, its data contracts and its deployment. |
| VIEWER | Read-only access to app and data. |
AUDITOR or DATA_STEWARD) with bespoke permission matrices. Contact us to scope a custom role model for your org.ABAC & data scoping
Roles are only half the story. Every attribute your IdP exposes — region, cost centre, plant, customer segment — can drive attribute-based access control inside Canyon. ABAC is enforced at the Canyon semantic data layer, which means every app, every agent, every query honours the same rules automatically.
Resource visibility
Every Canyon resource — an app, a data contract, a deployment — carries a visibility label in addition to its RBAC and ABAC rules.
ORG_PUBLICVisible to all organization members.TEAM_PRIVATEVisible to team members only.ORG_PRIVATEVisible to admins and owners only.