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

Sudomimus first looks for the identity bound to this connector subject:

1. Seen this connector subject before → reuse the existing account, even if the email at the IdP changed.
2. No existing subject binding, and the asserted email is trusted → look up the email owner and link to that account if one exists. Trust requires both an IdP-verified email and the connector organization’s current verified ownership of that email domain.
3. No matching subject or trusted email owner → create a new account for the connector subject. An absent or untrusted email does not establish mailbox ownership; the subject identity still has to pass the application’s Realize rules.

One account can hold identities from several connectors. Two IdPs asserting [email protected] resolve to the same email owner only when each connector independently satisfies the domain-trust requirement. Matching email text alone is insufficient.

Forced SSO (domain-managed)

Domain-managed SSO requires every user on a domain you own to sign in only through the designated IdP. Passkeys, email OTP, and consumer OAuth are unavailable to those users while the policy is enabled. The configuration has two parts:

1. A verified domain with its login policy set to SSO_ONLY, bound to one of your organization’s connectors.

2. The Layer-1 method ENTERPRISE_FEDERATION_DOMAIN_MANAGED enabled on each application that accepts 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 domain owned by another organization can therefore determine the IdP used for login; the application accepts the IdP designated by the user’s domain owner.

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.