--- title: Sign in with your IdP description: Put a federation connector to work — offer your identity provider as a sign-in button on an application, or force a verified domain's users through it. editUrl: true head: [] template: doc sidebar: order: 5 hidden: false attrs: {} pagefind: true draft: false --- import { CardGrid, LinkCard } from "@astrojs/starlight/components"; Once you have registered a [federation connector](/en-us/domains-federation/federation-connectors/), there are **two** ways to put it to work. They share the same connector, the same login machinery, and the same account model — they differ only in *who decides* that a user signs in through your IdP. | Mode | Who turns it on | Who it affects | |---|---|---| | **Application-managed** | An application developer, per application | Anyone who chooses the "Sign in with …" button on that app | | **Domain-managed (forced SSO)** | A domain owner, via login policy | Every account on a verified domain, on every application, with no opt-out | Both are **Layer-1 authentication methods**, so they compose with the rest of the [three-layer rules model](/en-us/application-rules/overview/) exactly like any other method. ## Application-managed sign-in This is the straightforward "let users of my app sign in with our corporate IdP" case. On an application your organization owns, add a Layer-1 authentication rule: ```json { "method": "ENTERPRISE_FEDERATION_APPLICATION_MANAGED", "payload": { "connectorAnchor": "Bastion-K7Q2-M9XB-3FNP-Covenant" } } ``` - The `connectorAnchor` must reference a connector **owned by the application's own organization** — this is enforced when the rule is saved. - Sudomimus renders a **"Sign in with ``"** button in the authentication UI. - One rule = one button. To offer several IdPs, add several rules (they OR together, like any Layer-1 rules). When the user clicks the button, the browser is redirected to your IdP, returns with an authorization code (browser-driven PKCE), and Sudomimus runs the **same realize pipeline as every other sign-in method**: account-linking decision, identity-row writes, Layer 2 realize, the consent gate, and token issuance. Nothing about federation is special downstream — it produces a normal Sudomimus session. ### How the federated identity links to an account When your IdP returns a user, Sudomimus decides how to attach them, exactly as for a consumer OAuth provider: 1. **Seen this connector subject before** → reuse the existing account (handles the user's email changing at the IdP). 2. **The IdP asserts a verified email that matches an existing account** → link this connector to that account. 3. **Neither** → create a new account. Because the link key is namespaced **per connector**, one Sudomimus account can hold several federated identities across different connectors — signing in through two different IdPs that both happen to use the email `jordan@acme.example` resolves to the same account by step 2. ## Forced SSO (domain-managed) This is the enterprise SSO payoff: **every** user on a domain you own may sign in **only** through your IdP — passkeys, email OTP, and consumer OAuth are taken away from them. It is built from two pieces you have already met: 1. A verified domain with its [login policy](/en-us/domains-federation/domain-login-policy/) set to **`SSO_ONLY`**, bound to one of your organization's connectors. 2. The latent Layer-1 method **`ENTERPRISE_FEDERATION_DOMAIN_MANAGED`** on each application that agrees to accept these logins: ```json { "method": "ENTERPRISE_FEDERATION_DOMAIN_MANAGED", "payload": {} } ``` The payload is **empty** — unlike application-managed, the connector is **not** named in the rule. It is resolved at login time from the user's email domain → the verified domain → the connector bound to that domain's `SSO_ONLY` policy. A different organization's domain can therefore drive the login, which is the whole point: your app says "I accept whatever IdP the user's domain owner mandated." ### What a gated user experiences - **Email-first flows.** When an SSO-gated user enters their email, Sudomimus suppresses every other method and offers **only** the "Continue with ``" path. - **No-email flows** (usernameless passkey, consumer OAuth, Steam). The user is only known *after* they authenticate, so Sudomimus catches them at realize time and redirects them into the SSO flow, then completes the login on the second pass. - **A confirmation screen, not a silent jump.** core-ui shows a "Continue with ``" screen rather than auto-redirecting. An account tainted by **two** different organizations' SSO domains (rare) gets a **picker** — any one bound connector satisfies the gate. - **New employees.** A brand-new user whose email is on a forced-SSO domain is registered *through* the IdP on first sign-in (registration-via-SSO) — there is no separate enrolment step. ### Apps that have not opted in An application that does **not** list `ENTERPRISE_FEDERATION_DOMAIN_MANAGED` simply **rejects** an SSO-gated user — there is no implicit SSO escape hatch injected into an app that did not ask for it. This keeps Layer-1 default-deny intact: forcing SSO never silently adds a method to an application. :::note[Forced SSO overrides Layer 1 only] `SSO_ONLY` changes *which authentication method* a gated user may use. It does **not** override Layer 2 or Layer 3 — an SSO-authenticated user can still be rejected by an application's email allowlist, and the result is still delivered by the application's return rules. Authentication ≠ authorization. ::: ### Offboarding Because enforcement is at login (realize) time, a departed employee whose IdP account is disabled simply cannot obtain a fresh assertion and cannot log in again. Tokens already issued expire by TTL (access 3 hours, refresh 30 days) — this is the standard SSO offboarding window, the same realize-only behavior as `BLOCK_ALL`. ## Related