Shipped server-side — API-first
Estimated 26.9.1· first week of September — ADFS pilot
Identity Gateway
Customer SSO for the applications you cannot rewrite
RealmSSO sits in the middle as an identity gateway: your customers sign in with their own corporate identity provider — Okta, Entra ID, or any SAML or OIDC provider — while each of your applications keeps trusting the identity system it already trusts. You register a product once and grant it per account; RealmSSO provisions that product a SAML or OIDC client in each granted customer realm, default deny, and serves each product team the per-customer values its own side needs. Where an application sits behind existing federation infrastructure, such as an on-premises ADFS farm or a private single sign-on server, that trust can be repointed at RealmSSO instead of rebuilt, so the application joins customer SSO with no rewrite. One gateway in place of a point-to-point trust for every application and every customer — and your customers keep full control of their users, MFA policy, and offboarding. All of it is driven over the API today; there is no configuration UI yet.
Why Identity Gateway?
Everything you need for enterprise-grade identity federation.
No application rewrites
An application keeps the identity system it trusts today. The existing trust is repointed at RealmSSO rather than rebuilt, so the application can join customer SSO without a code change or a new authentication library.
Grant-scoped provisioning, default deny
A product is registered once, and a grant pairs it with one account. Provisioning follows the grants: the product’s client is created in the realms of accounts that hold a grant and nowhere else. There is no implicit reach — an account with no grant has no client for that product, and revoking the grant is the operation that removes the route in.
SAML and OIDC, provisioned per realm
Each leg of the chain speaks whichever protocol that side already speaks. RealmSSO accepts SAML or OIDC from a customer’s provider and provisions a SAML or an OIDC client downstream per granted realm, so a protocol mismatch between the two ends stops being a blocker.
Per-customer values, served over the API
A handout endpoint returns exactly the values one product team needs for one account: the SAML descriptor URLs for that realm, or the OIDC discovery URL and client credentials. The hand-off between the identity team and an application team is an API call rather than an email with settings pasted into it.
A scoped role for the product team
A product-IdP-admin role unlocks exactly one read — one named account’s handout for one product — and nothing else. Secrets, mutations, provisioning, grants, and any unfiltered listing stay operator-only. The role is mutually exclusive with account membership, checked on every request, revoked with a single delete, and every read it makes is audited with the authority that admitted it recorded — including the reads that came back empty, so probing for which customers exist is not free and not invisible.
Customers keep control of their users
Authentication always happens at the customer’s own provider. Credentials, MFA policy, and joiner/leaver lifecycle stay with their IT team — a password is never presented to anything on your side of the gateway, and disabling a user at their provider closes that user’s route in without a ticket to you.
What is and is not built
The control plane ships: registrations, grants, SAML and OIDC provisioning, the handout API, and the scoped product-IdP-admin role — all of it over the API. There is no configuration UI for any of it yet, so operating the gateway today means calling the API or running the onboarding scripts. Those scripts cover ADFS and Keycloak, and no login has yet been driven through either leg: the ADFS cmdlets have never been executed against any ADFS farm, and while the Keycloak script’s writes have been observed against a real Keycloak and both scripts carry a committed smoke test, the end-to-end chain is unproven. A pilot on one real customer realm is what closes it, and it is the thing to wait for before planning a rollout. Talk to us about being part of it.
Interested in early access?
The gateway control plane is built: product registrations, per-account grants with default deny, SAML and OIDC client provisioning per granted realm, the handout API, and the scoped product-IdP-admin role. What is not there yet is a configuration surface — every one of those is an API call or a script today, not a screen — and no login has yet been driven through either onboarding leg: the ADFS cmdlets have never been executed against any ADFS farm, and while the Keycloak script’s writes have been observed against a real Keycloak and both scripts carry a committed smoke test, the end-to-end chain is unproven. A pilot on one real customer realm is what closes it. Talk to us if you want to drive it over the API now, or to be that pilot.