User Management
All users are created just-in-time the first time that they authenticate using single sign-on (SSO) with Open ID Connect (OIDC). We do not currently support SCIM provisioning and deprovisioning. In a future release, Authentication Users and Directory Users will be linked. This will allow us to automate creating Auth Users automatically when they are provisioned in the Integration (ex. Okta). With tightly integrated features with Directory Users, we will be able to deprovision the Auth User as well as many other resources and user accounts that have been provisioned over time.Single Sign-On (SSO)
Provisionr uses your single sign-on (SSO) provider for all human user authentication. When signing in, the SSO provider ID, first and last name, and email address is received in the SSO authentication response and is encrypted and saved in the Provisionr database. You can choose any of the following vendors when installing Provisionr:- Okta Workforce Identity
Password Management
We rely on your SSO provider for authentication. No passwords are managed or stored in Provisionr. You can configure password policies in your SSO provider. You can also configure passkey support in your SSO provider for a streamlined user experience.Two Factor Authentication
We rely on your SSO provider for authentication. You can configure two factor policies and assign them to the Provisionr application configuration in your SSO provider.API Authentication
The API endpoints are authenticated using access tokens and refresh tokens that are associated with a service account or user account. Each endpoint is associated with a permission that the service or user must be granted to be able to use the endpoint.Personal Access Tokens (PAT)
When you need to test a GET, POST, PATCH, or DELETE endpoint, you can use a personal access token that is created in the UI at/user/pat.
Provisionr PATs are only valid for 4 hours since they are designed for testing, not perpetual access with the full level of permissions that your user account has. This prevents the bad practice of an engineer using a PAT in their script or service that should use Service Accounts instead.
Service Accounts
Provisionr uses a secure-by-design approach with non-human (machine-to-machine) access to the API using Service Accounts with granular permissions. A Service Account is similar to a User Account, however it can only be authenticated with API tokens and there is no UI experience or SSO for service accounts. Service Accounts are for inbound requests to the Provisionr API from scripts or vendor services. The default permissions of a service account only include the ability to perform an authentication test and generate an access token using the service account’s refresh token. Each URL endpoint has a near 1:1 permission mapping that allows service accounts to only be granted access to the endpoints they actively use. Each Service Account has users associated that have permission to manage the service account. We refer to these as Service Account Managers and support least privilege and separation of duties.admin: Can create/rotate tokens and grant permissionspermissions: Can grant permissions but cannot create/rotate/view tokenstokens: Can create/rotate/view tokens but cannot edit permissionsaudit: Has read-only access to see the metadata about the service account and the permissions, but cannot make any changes or create/rotate/view tokens.
- Refresh token with up to 365 day expiration (configurable) with short-lived access tokens that last 60 minutes (configurable)
- Access token with up to 365 day expiration
Roles and Permissions
Provisionr has fine-grained access control using roles and permissions that are assigned to human users and service accounts.Permission Schema
{namespace}.{entity}.{action}
Here is an example of the permissions for the DirectoryAttribute actions.
directory.attribute.view(applies to list and describe)directory.attribute.exportdirectory.attribute.createdirectory.attribute.updatedirectory.attribute.activatedirectory.attribute.deprecatedirectory.attribute.deactivatedirectory.attribute.destroydirectory.attribute.sync
directory.attribute.user.view
Role Schema
We were inspired by Google Cloud Platform (GCP) IAM roles and have created a standardized schema for role-based access control (RBAC) that has pre-defined the permissions that users need. We only assign users to roles that have predefined permissions, not to permissions directly.Role Personas
- Admin: Can perform all actions. Intended for change management practitioners or system administrators.
- Ops: Can perform day-to-day changes and get things up and running. Must use deprecate to deactivate records.
- Contributor: Can view and create records in a draft state, but cannot update, activate, deactivate, or deprecate them.
- Auditor: Read-only with export permissions for CSV, JSON, YML, and Google Sheets.
- Viewer: Read-only for exploring what is configured. Some companies may restrict this to specific users, while others may expose it to all employees for self-service information.
Role and Permission Mapping
Entity Roles
Global Roles
Default Roles
When a new user authenticates, they are assigned the following roles by default. You can customize which roles are assigned by default to new users in the workspace settings.Default Role Catalog
Provisionr has a default catalog of roles and permissions that can be assigned to users. You can also create custom roles with specific permissions as needed.List of Provisionr Roles