SAML SSO

Set up SAML single sign-on for a Sanka workspace, add SSO users, and troubleshoot login, domain, and access issues.

Last updated: May 28, 2026

Use this guide when your workspace signs in with SAML single sign-on. It explains what Sanka needs for setup, how SSO users are added, what login behavior to expect, and how to troubleshoot common domain, seat, and access issues before treating them as product bugs.

What SAML SSO does

SAML SSO lets workspace users sign in through your identity provider instead of a Sanka password. In Sanka, SSO affects:

The SSO sign-in tab on the login page.
Domain checks that send users to the correct identity provider.
Workspace user creation for people who should use SSO.
Password login and password reset behavior for SSO-only users.
Access troubleshooting when the email domain, user record, workspace seat, or identity provider assignment is not ready.

Sanka currently supports Okta-led SAML setup. Contact Sanka support if you need to confirm support for another identity provider.

Setup information to prepare

Before Sanka support configures SSO, prepare:

Workspace name and workspace owner contact.
Email domain that should use SSO, such as example.com.
Identity provider name, such as Okta.
Identity provider sign-in URL.
Identity provider entity ID.
Identity provider certificate.
The email attribute that Sanka should use to identify the user.
A test user who belongs to the domain and is assigned to the Sanka application in the identity provider.
Whether the workspace should require SSO-only login.

Do not send certificates or sensitive identity provider details through an insecure channel. Use the secure process provided by Sanka support.

Ask AI for a setup checklist

AI can help prepare a checklist and support response, but it should not invent identity provider values or change workspace access rules.

Sample prompt

/sanka Prepare a SAML SSO setup checklist for a Sanka workspace. Include the workspace owner, email domain, identity provider, sign-in URL, entity ID, certificate, email attribute, test user, SSO-only decision, seat availability, and validation steps. Do not invent missing identity provider values or change user access.

Set up SSO with Sanka support

Contact Sanka support and request SAML SSO setup for the workspace.
Share the workspace name, email domain, identity provider, and required SAML metadata through the secure support process.
In your identity provider, create or open the Sanka application.
Add the service provider entity ID and reply URL supplied by Sanka support.
Configure the email attribute so Sanka receives the user's email address.
Assign a small test group before rolling out to the whole company.
Ask Sanka support to confirm when the domain is registered and ready for testing.

Add SSO users

After the domain is registered, workspace admins can add SSO users from the user invitation flow.

Open Workspace > Users.
Choose the option to add a SAML user.
Enter the user's name and email address.
Confirm the email domain matches the registered SSO domain.
Confirm the workspace has an available seat.
Add the user, then ask the user to sign in from the SSO tab.

If the email domain is not registered for SSO, Sanka should reject the SAML user creation and ask you to use another email address or finish the SSO setup first.

Situation	Expected behavior
User enters an SSO-supported email domain	Sanka can redirect the user to the identity provider from the SSO sign-in flow.
Email domain is not registered	Sanka should show that the domain is not supported for SSO.
Workspace requires SSO-only login	Email and password login should be blocked for users in that workspace.
User was created as an SSO user	Password login and password reset should be blocked; the user should use SSO.
User is not assigned in the identity provider	The identity provider may reject login even when Sanka's domain setup is correct.
Workspace has no available seats	Adding a new SSO user should fail until a seat is available or the plan is updated.

Validate before rollout

Search Sanka...

SAML SSO checkpoints

Logs

Search logsAll actionsAll dates

ID / ActionDateTarget / ItemChangeActor

1Domain registeredMay 23, 2026SAML SSOWorkspace domain and identity provider metadata reviewedWorkspace admin

2Test user addedMay 23, 2026Workspace usersTest user email domain matched SSO domain and a seat was availableWorkspace admin

3SSO login verifiedMay 23, 2026LoginTest user signed in through the identity provider before rolloutIT admin

Use these checks before requiring SSO-only login or inviting the full team. Most SSO issues come from domain, identity provider assignment, certificate, email attribute, or seat setup.

Run these checks:

Confirm the SSO tab recognizes a test user's email domain.
Confirm the test user reaches the identity provider sign-in page.
Confirm the identity provider returns the expected email address.
Confirm the user lands in the correct Sanka workspace.
Confirm password login is blocked only for users and workspaces that should be SSO-only.
Confirm password reset is not offered as the recovery path for SSO-only users.

Troubleshoot SSO issues

Issue	What to check
SSO domain is not supported	Confirm the email domain was registered with Sanka support and that the user entered the correct work email.
User cannot be added as a SAML user	Check the email format, registered domain, user permissions, workspace seat availability, and whether the user already exists.
Login redirects to the identity provider but fails there	Check identity provider assignment, group membership, app status, certificate, and email attribute mapping.
User signs in but reaches the wrong workspace	Confirm the email address, workspace membership, and whether the user belongs to multiple Sanka workspaces.
Password login is blocked	Confirm whether the workspace requires SSO-only login or the user was created as an SSO user.
Password reset is blocked	SSO users should recover access through the identity provider, not Sanka password reset.
SSO worked before but stopped	Check certificate rotation, identity provider app changes, domain changes, and whether the user was removed from the identity provider group.

AI-safe support guidance

When a customer reports an SSO issue, AI should first classify it as setup, domain, identity provider assignment, user provisioning, seat availability, SSO-only enforcement, or password recovery behavior. It should not propose a code change until those checks are complete.