Federation connectors
A federation connector is your organization’s own external OIDC identity provider, registered with Sudomimus once and reused everywhere. If your company runs Microsoft Entra ID, Okta, Google Workspace, Ping, Auth0, or any standards-compliant OIDC provider, you register it as a connector and then either:
- offer it as a “Sign in with …” button on one of your applications (application-managed), or
- force a verified domain’s users through it (domain-managed / forced SSO).
The connector is the shared mount point for both. Sudomimus acts as a relying party (OIDC client) against your IdP — it consumes your provider; your provider stays the source of truth for those identities.
What a connector stores
Section titled “What a connector stores”You register a connector from the With portal on one of your organizations. It holds:
| Field | What it is |
|---|---|
| Display name | Shown on the login button and in management UIs (e.g. “Acme Corp SSO”). |
| Issuer | Your IdP’s issuer URL (https://login.acme.example). Sudomimus fetches its OIDC discovery document from <issuer>/.well-known/openid-configuration. |
| Client ID | The OAuth client ID Sudomimus presents to your IdP. |
| Client secret | The confidential client secret. Encrypted at rest and write-only — see below. |
| Scopes | The scopes Sudomimus requests; must include openid. |
Each connector is addressed by an opaque connector anchor (a value like Bastion-K7Q2-M9XB-3FNP-Covenant) — the developer-facing identifier you reference from rules and policies. The internal identifier never leaves the system.
The client secret is never revealed back to you
Section titled “The client secret is never revealed back to you”The client secret is encrypted the moment you save it. On every read — the connector list, the detail page, the API — it is simply absent: the portal can never display it back to you. To rotate it, supply a new secret; to keep the existing one when editing other fields, leave the secret blank.
Validation at save time
Section titled “Validation at save time”When you create or update a connector, Sudomimus fetches your IdP’s discovery document then and there. If the issuer is unreachable or does not publish a valid OIDC discovery document, the save is rejected (FederationConnectorDiscoveryFailed) rather than storing a dead connector — the failure is loud and immediate, not a surprise at first login.
The redirect URI to register at your IdP
Section titled “The redirect URI to register at your IdP”Sudomimus uses a single, platform-fixed redirect (callback) URI for all connectors — your IdP distinguishes flows by the per-login state value, not by the redirect URI. The connector page shows this URI read-only; register it as an allowed redirect URI in your IdP’s application configuration:
https://via.sudomimus.com/oauth/enterprise-federation/callbackManaging connectors
Section titled “Managing connectors”- Disable a connector to retire it without deleting it — useful when you are migrating IdPs.
- Delete removes it entirely.
Each organization can hold a limited number of connectors (default 3). Sudomimus staff can raise the limit on request. The quota is enforced on the self-service surface only.
Browsing connectors
Section titled “Browsing connectors”The With portal has a top-level Connectors view that lists every connector across all your organizations, with an organization switcher.