Sign in with your IdP

Once you have registered a federation connector, 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 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:

{
  "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 <connector display name>” 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 [email protected] 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 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:

   {
     "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 <connector>” 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 <connector>” 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.

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

Federation connectors Register the OIDC identity provider both modes use.

Domain login policy The SSO_ONLY policy that drives domain-managed forced SSO.

Layer 1 — Authentication rules How both federation methods sit in the three-layer rules model.