Sign in through your own identity provider
Settings → Single sign-on connects your SAML 2.0 identity provider - Okta, Entra ID, Google Workspace, OneLogin - so that people reach Yekar.AI through the directory you already run, and lose access there when you disable them there.
It is an organization-admin surface, and it is enabled per workspace: if the section is not in your Settings navigation, ask Yekar.AI to turn it on.
What it does not do
Nobody is created by signing in. There is no just-in-time provisioning, deliberately: an assertion from your IdP proves who someone is, not that they should have a workspace here. The account and exactly one membership in this organization must already exist, invited through Settings → Users as usual. A sign-in for anyone else is refused with sso_not_provisioned.
The one thing a successful SSO sign-in does change is an invited membership: it activates it. So an invitation can be sent and then accepted by signing in through your IdP, without a password ever being set.
Set it up
Configuration is one drawer, and it has two halves.
Values to copy into your IdP - shown read-only, each with a copy button:
| Field | What it is |
|---|---|
| Entity ID | The service-provider identifier your IdP will assert to. |
| ACS URL | Where your IdP posts the assertion. |
| Metadata URL | SP metadata as XML, if your IdP prefers to import rather than be typed into. |
| NameID format | The identifier format Yekar.AI expects. |
Values to enter from your IdP:
- IdP entity ID and IdP SSO URL - the issuer and the sign-in endpoint.
- IdP signing certificate - the public X.509 certificate, in PEM format. Once saved, the page shows its subject, its SHA-256 fingerprint and its expiry, so a certificate about to lapse is visible before it lapses rather than after.
- Email attribute - the assertion attribute holding the person's address. Leave it empty to use an email-formatted NameID.
- Allow IdP-initiated sign-in - off by default. With it off, a sign-in must start here and every assertion is correlated to a request Yekar.AI issued.
Status
The connection carries one of three states, and only one of them signs anybody in.
| Status | Meaning |
|---|---|
| Draft | Configured but not live. Sign-in through it is refused. |
| Active | Live. Assertions are accepted. |
| Disabled | Switched off, configuration kept. |
Activate only once every IdP value is complete and a real sign-in has been tested, as the field's own hint says: a half-configured active connection refuses people who have no other way in.
When a sign-in fails
A failed sign-in returns to the Yekar.AI sign-in page with a reason on the URL rather than a stack trace:
| Reason | What happened |
|---|---|
sso_not_configured | No SAML connection exists for this workspace. |
sso_not_enabled | The connection exists but is Draft or Disabled. |
sso_invalid_assertion | The assertion failed validation - signature, timing, or correlation to the request. |
sso_no_email | No usable address in the assertion. Check the Email attribute. |
sso_not_provisioned | No account, or no membership in this organization. Invite them first. |
sso_access_denied | The membership exists but is deactivated. |
Every successful sign-in is written to the audit trail with the protocol, the connection and the assertion id; so is every refusal, with its reason.
What SSO does not replace
SSO binds a session to one organization - the one the connection belongs to - exactly as a password sign-in does. Roles, domain memberships and permissions are unchanged and are still managed in Settings → Users and on each domain; the identity provider decides who may sign in, not what they may do once they have.