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.
Require single sign-on
Require single sign-on (in the configuration drawer) makes your identity provider the only way into this organization. While it is on and the connection is Active:
- Signing in with a password or Google still proves who someone is, but does not let them into this organization. Someone who belongs only to your organization is told to use single sign-on, with a Continue with single sign-on button that starts it.
- Someone who also belongs to other organizations signs in to those as usual. Choosing yours from the workspace switcher sends them through your identity provider instead.
- Accepting an invitation to your organization is done by signing in through your identity provider, not by setting a password.
- It applies to everyone, Owners and Admins included.
Share the Sign-in link shown under Signing in with your members - it starts a sign-in through your identity provider.
To turn it on, the connection must be Active and you must have signed in through it yourself in the session you are using, which proves it works before anyone depends on it. Turning it on signs out everyone currently signed in to your organization another way; they sign back in through your identity provider. Each refused sign-in is written to the audit log as Sign-in refused: single sign-on required.
If the connection is set to Draft or Disabled, or single sign-on stops being part of your plan, the requirement pauses on its own and passwords and Google work again, so nobody is left with no 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.