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. An OIDC provider returns an authorization code to the fixed callback; a SAML provider posts a signed assertion to the fixed ACS. Sudomimus validates either proof and 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 when there is one satisfiable connector. If verified domains require different connectors, the UI shows a terminal authority-conflict explanation instead. It never asks the user to choose which domain owner to bypass.
• 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 login requires a fresh IdP assertion, a departed employee whose IdP account is disabled cannot start a new session. Already-issued access tokens are not revoked immediately; they expire by TTL (3 hours by default). Existing refresh sessions continue only while their original login still satisfies the current domain policy: Session API /refresh and the OIDC refresh-token grant re-check BLOCK_ALL and SSO_ONLY, so switching the domain to BLOCK_ALL or repinning SSO_ONLY to a connector the session did not use cuts it off at the next refresh. Disabling only the user at the IdP does not make an existing Sudomimus refresh token contact the IdP retroactively.

If the same account later owns verified emails under domains pinned to distinct IdPs, neither IdP wins. Interactive login, code redemption, device/native issuance, and refresh all fail closed until the conflict is repaired. Multiple domains pinned to the same connector remain usable.

Related

Federation connectorsRegister the OIDC or SAML identity provider both modes use.

Configure OIDCCreate and test an OIDC federation connector end to end.

Configure SAMLCreate and test a SAML federation connector end to end.

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

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