Identity Gateway

Registration records a product’s name, its slug and its protocol: OIDC, SAML or both. Registering provisions nothing. A platform operator registers a product through the API or on the connector board. An API key cannot.

A product grant pairs a registered product with one account. The product’s client exists only in the realms of accounts that hold a product grant. An account with no product grant has no client for that product. A new realm copies only its own account’s product grants. Creating a product grant provisions nothing by itself: a separate provision call does that, and the connector board does both in one step. Revoking a product grant removes the client at once.

For each product grant, RealmSSO provisions a SAML or an OIDC client for the product in that account’s realm, as the product grant’s protocol requires. A realm is the separate sign-in space RealmSSO keeps for each account. Each realm holds its own client, so no client is shared across customers. An integration test shows that the SAML assertion names the requesting product as its only audience.

A handout lists, for each account that holds a product grant, the values one product team copies: the OIDC discovery URL and client ID, or the SAML descriptor URL, and the registered URLs. It also reports whether each client is provisioned, absent or unreachable. That status is read live, not stored. Every read is audited per account, including a read for one named account that found nothing. A platform operator reads a handout through the API, and the connector board shows the values of one product grant.

A platform operator reads a product’s client secret with a POST call, never a GET, and RealmSSO audits each read. RealmSSO’s database stores no product secret. The sign-in service holds it. The connector board cannot show a secret. API only.

A platform operator rotates the OIDC client secret of one product grant. The call needs a note that coordinates the change with the product team. The rotation is designed as an immediate cutover, with no overlap between the old secret and the new one, and there is no rollback. That the old secret stops at cutover comes from the sign-in service’s documentation, and we have not measured it. A SAML product grant has no client secret, so rotation is refused. There is no product-wide rotation, by design. API only.

A platform operator can give a product team a role that reads the handout of one named account for one product. The role reads nothing else. Someone who is a member of any account cannot hold it, and RealmSSO checks this on every request. An API key cannot hold it. Removing the role takes effect on the next request. A platform operator gives and removes the role through the API, and no screen exists for it.

The connector board is a dashboard page that shows accounts against products. On it, a platform operator registers, renames, deactivates or deletes a product, creates a product grant, provisions it, revokes it, and shows the handout values of one product grant. The board does not edit a product grant, rotate or reveal a secret, or manage the product-team role: those stay API calls. A platform operator can also read the whole customer-by-product matrix through the API. Each read of that matrix writes an audit row. No screen exists for customers or product teams.