What SSO covers
SSO lets your team sign in to the Finn dashboard through your own identity provider instead of a Finn password. It covers dashboard access only. API keys are separate credentials and are not affected by SSO state — see authentication.
SSO is configured in the dashboard under Settings → Team. There is no public API for creating or editing an SSO connection.
What is settled
| Item | Status |
|---|---|
| SAML 2.0 sign-in for the dashboard | Supported |
| Configuration surface | Dashboard only (Settings → Team) |
| API key lifecycle | Unaffected by SSO |
| SCIM directory sync | Not yet settled — do not plan around it |
| Enforced-SSO (blocking password login) | Not yet settled |
| Group-to-role mapping | Not yet settled |
Anything marked "not yet settled" is not a roadmap promise. If your rollout depends on it, contact support before you commit a date.
Setting up a SAML connection
You do this from both sides. Have your IdP admin console open in a second tab.
- Go to Settings → Team → Single sign-on.
- Copy the ACS URL and Entity ID Finn shows you.
- In your IdP, create a new SAML application and paste those two values in.
- Copy your IdP's metadata URL (or download the metadata XML).
- Paste the metadata back into Finn and save.
- Test with one account before you tell anyone else. A broken connection locks out everyone who has no fallback.
Keep at least one workspace member on password login until you have confirmed SSO works. If the IdP metadata is wrong and every member is SSO-only, you have no way back in from the dashboard and recovery goes through support.
Attributes Finn reads
| Attribute | Required | Used for |
|---|---|---|
NameID | Yes | Matching the member record |
| Yes | Member identity in the workspace | |
| Display name | No | Name shown in the members table |
Finn matches an incoming assertion to an existing workspace member by email. If no member with that email exists, the sign-in fails. Invite the person first under Settings → Team → Members, then have them sign in through the IdP. There is no just-in-time provisioning.
What goes wrong
| Symptom | Cause |
|---|---|
| Sign-in returns to the login page with no error | Clock skew between your IdP and Finn. Assertions outside the validity window are rejected. |
| "User not found" after a successful IdP login | Email in the assertion does not match any invited member. Check for a work alias vs primary address mismatch. |
| Everyone locked out after an IdP change | Certificate rotated on the IdP side without updating Finn. Re-paste the metadata. |
| One person can sign in, nobody else can | The IdP application is scoped to a single user or group. Widen the assignment in the IdP. |
Certificate expiry is the failure that hurts most. Your IdP signing certificate has an expiry date, and when it passes, every SSO sign-in fails at once with no warning from Finn. Track that date yourself and re-paste the metadata before it lapses.
Removing a member
Removing someone from your IdP stops them signing in. It does not remove them from the Finn workspace, and it does not revoke API keys they created. Do both:
- Remove the member under Settings → Team → Members.
- Rotate any API keys they had access to. See authentication.
Without SCIM, deprovisioning is a manual step on the Finn side. Build it into your offboarding checklist rather than assuming the IdP handles it.
Related pages
- authentication — API keys, which SSO does not govern
- compliance — what the platform handles versus what you handle
- data-residency — where workspace data is stored
- retention — how long call data is kept