Administration
Users, roles and permissions, organizational units, identity providers and authentication.
Users
Users are the identities that sign in to a tenant. Each user carries a full authentication state and can be assigned roles and organizational units.
| Aspect | Detail |
|---|---|
| Password | Protected with strong, industry-standard password hashing |
| Two-factor | TOTP 2FA with recovery codes |
| Lockout | Failed-login counter with automatic lockout and timed release |
| Approval | Pending users can be approved / rejected before activation |
| Assignment | Roles and organizational units assigned at creation or later |
Administrative actions include approve, reject, lock / unlock, suspend / unsuspend, reset password, manage TOTP, and review or revoke active sessions and sign-in logs.
Roles and permissions
Authorization is role-based (RBAC). A role is a named bundle of permissions; users are granted roles, and each user's effective permissions are the combined set expanded from all of their roles.
Hierarchical permissions
Permissions are organized as a hierarchy, so granting a broad permission (for example "manage keys") automatically implies the more specific actions beneath it.
Host vs tenant scope
Each permission is scoped to the host, a tenant, or both, so host-only actions never appear inside a tenant — a foundation for separation of duties.
Built-in & default roles
Built-in roles cannot be deleted and stay aligned with the current capability set; a role can be marked default so new users receive it automatically.
Permissions are grouped by area — Administration (users, roles, settings), Operations (the cryptographic capabilities such as key management, vaults, PKI and PQC), Host, and cross-cutting areas like access policies, identity providers, notifications and billing. See Features for how the capabilities these permissions govern are toggled per edition.
The platform has a dedicated host super-administrator. Its authority is managed separately from ordinary tenant roles (see Host).
Organizational units
Organizational units (OUs) add a second scoping layer inside a tenant. They form a tree that mirrors teams or departments, and resources like apps can be scoped to a specific OU (or left visible to the whole tenant). Roles can be assigned at the OU level, and membership is managed per OU.
Identity providers and SSO
External identity providers let users sign in with corporate credentials. Providers are configured with their client credentials, authority/metadata URLs, scopes and claim mappings, and can auto-provision users into default roles.
| Provider | Status |
|---|---|
| Azure AD / Entra ID | Supported |
| Okta | Supported |
| Keycloak | Supported |
| UAE Pass | Supported |
| Ping Identity | Supported |
| RSA SecurID Access | Supported |
| ForgeRock | Supported |
Single sign-on is governed by the identity-provider entitlements: the provider must be enabled for the tenant's edition — see Features.
Authentication mechanisms
| Mechanism | Detail |
|---|---|
| Password | Strong, industry-standard password hashing, with a configurable password policy (see Host settings) |
| TOTP 2FA | Time-based one-time passwords with recovery codes |
| WebAuthn / FIDO2 | Passkeys, security keys and Windows Hello |
| External SSO | Azure AD, Okta, Keycloak and other supported identity providers via the identity-provider module |
Sessions can be invalidated on password change, revocation or logout, so access can be cut off immediately when needed.
Access policies (ABAC)
Beyond RBAC, administration includes an attribute-based access-policy engine (ABAC) that governs runtime cryptographic operations by user, IP, location, time and group. That model is documented in full on the Access Policies page.
API reference
Administration exposes management operations for users, roles, organizational units, identity providers, access policies and impersonation, each governed by the corresponding administration permissions.