SSO and SCIM

Single sign-on (SSO) lets members sign in to Verdictan through your identity provider, with OIDC or SAML 2.0. SCIM lets that provider create, update, and suspend members in Verdictan. Set up SSO first, then add SCIM if you want it.

Before you make SSO mandatory, test the connection and test sign-in with each recovery account. A broken identity provider must never lock every owner out.

Before you start

Work with your identity provider administrator. In Verdictan, you need org:sso, and for SCIM also sso:read and sso:write. Have these ready:

• The email domain to verify for sign-in discovery.
• For OIDC: the discovery URL, client ID, and client secret.
• For SAML: the metadata URL or XML file of the identity provider.
• The roles and teams to give each directory group.
• A test user who is not an owner.
• Two different recovery owners who can sign in with a password.

Keep test and recovery accounts separate, and never make the only active owner your first SSO test user.

1. Create a connection

1. Open Settings → Single Sign-On and select Add Connection.
2. Under Select provider type, choose OIDC or SAML.
3. Enter a Connection name and the provider values below.
4. Enter your email domain in Domain hint.
5. Select Create Connection.
6. Verify the domain before activation.

Protocol	Fields
OIDC	Discovery URL, Client ID, and Client Secret
SAML	IdP Metadata URL, or IdP Metadata XML when there is no URL

Verdictan encrypts the stored client secret. To keep the saved secret when you edit a connection, leave the secret field empty.

2. Register the callback

The callback is where the identity provider sends the browser after sign-in. It is on the Console of your region.

OIDC

Register the redirect URI of your region:

EU Console

https://console.eu.verdictan.com/sso/callback

US Console

https://console.us.verdictan.com/sso/callback

Scheme, host, port, and path must match exactly.

SAML

On the connection page, select Download SP Metadata and import the file into the identity provider. It sets the entity ID, audience, and assertion consumer service (ACS) address. The ACS path is /sso/callback or /auth/saml/callback on your Console origin. Make sure the provider sends the email and group attributes.

Follow your identity provider's own guide for its side of the application registration.

3. Prepare recovery

1. Select Test Connection and fix any discovery, endpoint, credential, metadata, or certificate errors.
2. Sign in with the password of each recovery owner.
3. Under Break-glass activation, enter both IDs in Recovery owner user IDs.
4. Select Record break-glass activation.

Break-glass access is how owners get in if the identity provider is down. Activation needs a passing connection test, a verified domain, and two different recovery owners. A passing metadata test does not prove sign-in. That comes in step 5.

4. Map groups to permissions

1. Under Group-to-Role Mapping, enter the Group claim name, such as groups.
2. Map each directory group to a role ID and, optionally, a team ID.
3. Optionally set a Fallback role ID for users without a matching group.
4. Keep Sync at each sign-in on to re-evaluate the mappings at every sign-in.
5. Select Save Changes.

For example, map the support-review group to a role that can read request evidence. Never give an administrator role to a large default group.

5. Enable and test sign-in

1. Under Enforcement Settings, select Enable SSO and save.
2. Sign in with the test user's email through the SSO discovery flow.
3. Check the organization, identity, teams, and roles.
4. If you set a fallback role, sign in with an unmapped user.
5. Add a test group at the identity provider, sign in again, and check the new assignment.
6. Remove the test group, sign in again, and check that the assignment is gone.

Keep password recovery available throughout.

6. Make SSO mandatory

Enforcement turns off password sign-in for users in the configured domain. The assigned recovery method stays available.

1. Tell your members about the change.
2. Test password sign-in for each recovery owner.
3. Under Enforcement Settings, select SSO for all members and save.
4. Watch sign-in results.

If the identity provider fails, a recovery owner signs in with a password and turns SSO for all members off. Never use enforcement to find problems in an untested connection.

Optional: synchronize members with SCIM

1. Under SCIM Provisioning, select Enable SCIM.
2. Copy the SCIM Endpoint URL into the provisioning settings of your identity provider.
3. Select Generate New Token and copy it right away. The Console shows it only once.
4. Store the token in the protected credential field of the identity provider.
5. Assign a test user without special privileges to the application.

Check that Verdictan creates the member. Then update the member, change their group, and remove them at the identity provider, and check each result in IAM → Members and Trail.

Keep the SCIM token out of email and tickets. Replace it if it is exposed, and revoke tokens that are no longer in use.

A SCIM group change does not remove every other grant. After deprovisioning, also review direct roles, owned tokens, active sessions, and owned resources.

Verify the complete setup

Test SSO sign-in, recovery owner sign-in, and access. With SCIM, check the create, update, and remove results. Keep the Trail records for your access review.

Troubleshooting

Problem	What to check
An email domain does not start SSO	The domain hint, domain verification, and connection state
OIDC returns a callback error	The exact redirect URI, discovery URL, credentials, and clocks
SAML fails	The imported metadata, entity ID, audience, ACS recipient, certificate, and time conditions
A user gets unexpected access	The group claim, mappings, fallback role, sync setting, and direct roles
SCIM returns 401	The endpoint and an active, complete token. Replace a bad or exposed token.
Access remains after a group is removed	Another team or direct assignment grants the same action
Activation fails	A passing connection test, a verified domain, and two eligible recovery owners

Next steps

• Roles and IAM Policies: permissions for your groups.
• Members and Teams: review synchronized members.
• MFA and Passkeys: protect password sign-ins.