Connect your identity provider (IdP) to whoot. via SAML SSO. Automate user provisioning, enforce authentication policies, and eliminate password sprawl.
Overview
If you intend to use directory roles, emit a group claim too. whoot. reads groups, group, roles, memberOf, and the Entra ID and SAML group claim URIs, from either the assertion or the user profile.
Directory Roles
Single sign-on decides who somebody is. Directory roles decide what they are: a group in your directory maps to a role in whoot., so membership of your "Security Leads" group makes somebody an administrator here, and leaving that group takes it away.
Set it up under Admin → Security → Single Sign-On → Directory roles. It is off in every workspace until you turn it on.
How a mapping is applied
SSO — the group claim is read at every sign-in, not only the first. A change in your directory reaches whoot. the next time the person signs in.
SCIM — group membership pushed by your directory is read whenever it changes.
One role each — a member holds exactly one role, so when somebody matches several mapped groups the mapping with the lowest Order wins. Order 10 beats order 20.
No match — by default the member keeps the role they already have. Turn on Members matching no group to reset them to a fallback role instead, making the directory the only source of truth.
Setting up a mapping
Check what your provider actually sends. Entra ID emits group object IDs rather than names unless the app registration is configured to emit names — paste whichever it sends.
Under Directory roles, choose the source (SSO or SCIM), enter the group value, pick the role, and set the order.
Turn on Apply on SSO sign-in, or Apply on SCIM provisioning, or both.
Sign in as a member of that group and confirm their role under Admin → Application → Users.
Test with one group before adding more. A mapping applies to everyone in that group at their next sign-in, so a wrong group value can change a lot of people's access at once. Note that pausing or deleting a mapping does not put anyone's role back — it only stops the mapping being applied from that point on.
What mapping cannot do
It cannot exceed your own access. You can only map a group to a role whose permissions you already hold — the same rule as assigning a role by hand.
It cannot lock you out. If applying a mapping would remove the last member able to assign roles, the change is skipped and recorded. A directory misconfiguration cannot leave a workspace with no administrator.
It cannot reach another workspace. A mapping can only name a role belonging to this one.
It needs two permissions. Editing directory roles requires both Manage SSO providers and Change user roles, because a mapping is a standing instruction to assign roles.
Every automatic role change is written to the audit log, recording the group that matched and the role before and after.
whoot. supports SAML 2.0 SSO, allowing your team to sign in with their existing corporate credentials. Supported identity providers include but are not limited to:
Okta
Azure Active Directory (Entra ID)
Google Workspace
OneLogin
Any SAML 2.0-compliant IdP
Prerequisites
Admin access to your whoot. tenant
Admin access to your identity provider
Step 1: Configure Your Identity Provider
In your IdP admin console, create a new SAML application with these settings:
If you're not logged in, the generic configuration values are:
Name ID Format:urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
Attribute Mapping
Map the following SAML attributes in your IdP:
If you intend to use directory roles, emit a group claim too. whoot. reads groups, group, roles, memberOf, and the Entra ID and SAML group claim URIs, from either the assertion or the user profile.
Step 2: Configure whoot.
In whoot., go to Admin → Security → Single Sign-On
Paste the IdP Metadata XML or enter the IdP SSO URL and certificate manually
Click Save
Use the Test Connection button to verify the integration works before enforcing it
Step 3: Set Enforcement Mode
Choose how SSO interacts with other login methods:
Optional — Users can sign in with SSO or email/password
Required — All users with the verified domain must use SSO (email/password login disabled for those users)
Step 4: Testing Your Configuration
whoot. includes a built-in IdP testing tool:
Click Test Connection in the SSO settings
You'll be redirected to your IdP
Sign in with your corporate credentials
If successful, you'll see a confirmation message with the returned SAML attributes
If it fails, the error message will tell you exactly what went wrong
Directory Roles
Single sign-on decides who somebody is. Directory roles decide what they are: a group in your directory maps to a role in whoot., so membership of your "Security Leads" group makes somebody an administrator here, and leaving that group takes it away.
Set it up under Admin → Security → Single Sign-On → Directory roles. It is off in every workspace until you turn it on.
How a mapping is applied
SSO — the group claim is read at every sign-in, not only the first. A change in your directory reaches whoot. the next time the person signs in.
SCIM — group membership pushed by your directory is read whenever it changes.
One role each — a member holds exactly one role, so when somebody matches several mapped groups the mapping with the lowest Order wins. Order 10 beats order 20.
No match — by default the member keeps the role they already have. Turn on Members matching no group to reset them to a fallback role instead, making the directory the only source of truth.
Setting up a mapping
Check what your provider actually sends. Entra ID emits group object IDs rather than names unless the app registration is configured to emit names — paste whichever it sends.
Under Directory roles, choose the source (SSO or SCIM), enter the group value, pick the role, and set the order.
Turn on Apply on SSO sign-in, or Apply on SCIM provisioning, or both.
Sign in as a member of that group and confirm their role under Admin → Application → Users.
Test with one group before adding more. A mapping applies to everyone in that group at their next sign-in, so a wrong group value can change a lot of people's access at once. Note that pausing or deleting a mapping does not put anyone's role back — it only stops the mapping being applied from that point on.
What mapping cannot do
It cannot exceed your own access. You can only map a group to a role whose permissions you already hold — the same rule as assigning a role by hand.
It cannot lock you out. If applying a mapping would remove the last member able to assign roles, the change is skipped and recorded. A directory misconfiguration cannot leave a workspace with no administrator.
It cannot reach another workspace. A mapping can only name a role belonging to this one.
It needs two permissions. Editing directory roles requires both Manage SSO providers and Change user roles, because a mapping is a standing instruction to assign roles.
Every automatic role change is written to the audit log, recording the group that matched and the role before and after.
Troubleshooting
SSO login not working?
Verify your domain is verified (check DNS records)
Ensure the ACS URL and Entity ID match exactly
Check that the IdP certificate hasn't expired
Use the Test Connection tool for diagnostic information
Next Steps
Security & Compliance — Configure MFA and audit logging