What this section is for
Set up login through your organisation’s identity provider, member permissions and an activity log. SSO supports SAML and OIDC. SCIM creates and updates users automatically. Roles control available actions, and the log shows who performed them and when.
When to use
- When the organization requires SSO for all internal tools.
- When employee access should be created and disabled through the organisation’s identity provider.
- When checking access changes or preparing audit evidence.
Quick start
- 1Create the organization and set its domain.
- 2Configure SSO with the values from your identity provider — entity ID and SSO URL and certificate for SAML, or client ID, secret and issuer for OIDC.
- 3For SAML, generate a login link and test it with a regular account before rolling it out to the organisation.
- 4Create a SCIM token with the required permissions, save it immediately in a secret store and connect user synchronization.
- 5Define roles with explicit permissions and assign them to members.
Key settings
| Setting | What it does | How to use it | Common mistake |
|---|---|---|---|
| SSO configuration | Connects authentication to your identity provider. | Test the generated login URL with a normal user account, not just an administrator, before switching it on. | Enabling SSO before testing and locking every member out, including the person who configured it. |
| SCIM token | Authenticates your identity provider for automated user provisioning. | Store it in a secret manager the moment it is generated — it is displayed exactly once. | Closing the dialog before copying the token, which means generating a new one and reconfiguring the provider. |
| Roles and permissions | Defines allowed actions for each role. | Grant the permissions a member needs for their work. Add others when a task requires them. | Giving everyone administrator access instead of roles suited to their tasks. |
| Audit logs | Records the user, action, resource and time for security-related events. | Filter by action and check the log after changes to SSO, roles or user synchronization. | Considering setup complete without checking that the expected events were logged. |
Usage example
Scenario: Security requires SSO and automated deprovisioning within the quarter.
- 1Configure SSO, generate the SAML login URL and test it with a pilot group.
- 2Create a SCIM token with the required scopes and connect provisioning in the identity provider.
- 3Define roles, assign them to existing members, then enable SSO organization-wide.
- 4Test creation and deactivation of a user and check the corresponding log entries.
What this shows: You have tested corporate login, permissions and user synchronization, with the actions recorded in the log.
FAQ
I lost the SCIM token. Can I see it again?
No, the token is shown only when created. Revoke the lost token, create another and update it in your identity provider.
Can SSO and password login coexist?
That depends on how you configure it. Keep at least one administrator able to sign in without SSO until you have confirmed the integration works.
Which permissions should a role have?
Only the ones its holders use. Permissions are explicit strings such as org:admin, audit:read and sso:manage, so a role can be as narrow as you need.
Tips
- Test SSO with a non-administrator account to check the normal login path.
- Revoke unused SCIM tokens and keep active ones in a secret store.