DocsOrganizations

SSO & SCIM

Sign in to INFRO through your own SAML or OIDC identity provider, and provision members from your directory over SCIM 2.0. Included from the Business plan.

INFRO is in private early access. Running these examples requires an early-access account, an active trial or subscription entitlement, and your own provider connection. Self-serve purchasing is not generally open. See Early access.

People sign in to the INFRO console through your identity provider, and your directory can create and deactivate their INFRO membership. Both are included from the Business plan. Application traffic is unaffected: gateway keys authenticate independently of console sign-in, and nothing here changes how a request is authorized.

A provider signs nobody in until its domain is proved. INFRO refuses every assertion from a provider whose domain has not been verified by DNS, which is what stops an organization registering a provider for a domain it does not control.

Register the provider

In the console, open Settings → SSO and add your identity provider. You give the domain your provider is authoritative for and either an OIDC or a SAML configuration. Owner and admin roles may do this; the change is written to the audit log.

Your IdP asks for INFRO's side first, so the console shows it before you register: for OIDC the redirect URI, for SAML the ACS URL, the entity ID and the service-provider metadata URL. Each carries the provider's id, so create the app in your IdP with those values, then paste what it gives you (issuer, client ID and secret; or entity ID, sign-in URL and signing certificate or metadata XML) into the console. The same values stay listed on the provider afterwards. The OIDC client secret is stored encrypted and never shown again.

Prove the domain

The console gives you a TXT record to publish, named _infro-sso-<provider-id> on the domain you registered. Publish it, then press Verify. Until that check passes, every sign-in through the provider is refused with a 401 — that is the intended behaviour and the single commonest reason a new provider appears not to work.

Changing a provider's domain resets its verification. Sign-in through it stops until the new domain is proved, so change the domain and publish the new record together.

What an assertion can and cannot do

Sign in a person whose address is inside the verified domain, and make them a member of the organization that registered the provider.
Grant the admin or developer role when a role attribute on the assertion says so. Everyone else joins as analyst, which is read-only and cannot create a gateway key; an owner or admin can change the role afterwards.
It can never grant ownership. An organization has exactly one owner and ownership moves only through Transfer ownership in the console, so a directory administrator cannot take an organization from the person who pays for it.
It can never exceed the plan's seats. A provisioning that would take a seat the plan does not include is refused, and the person is told so.

An account that already exists

If somebody already has an INFRO account at an address inside your verified domain, their SSO identity links to that account — one person, one account. If that account has not verified its own email address, the link is refused rather than silently forking them into a second user; they verify the address they already control and sign in again.

SCIM provisioning

The SCIM 2.0 base URL is /auth/scim/v2 on the gateway. Mint a bearer token in the same console screen and paste both into your IdP. The token is shown once and stored only as a hash — there is no reveal, so if it is lost, rotate it. Rotating replaces the token on the same connection and the previous one stops working immediately.

INFRO implements the Users resource. When your directory deactivates somebody, their INFRO membership is removed; their user account and any other organization they belong to are untouched. Deprovisioning is never gated on your plan — if a subscription lapses, leavers are still removed.

Revoking the SCIM token stops future provisioning and removes nobody. People the directory already added keep their membership until somebody removes them, exactly as if you had switched the integration off in your IdP.

What is not supported

SCIM Groups. INFRO grants the Users scopes only; group membership is not mapped to roles.
IdP-initiated SAML sign-in is not part of the supported setup — start from the INFRO console.
Signed SAML sign-in requests. INFRO does not sign its AuthnRequests, so an IdP set to require them (WantAuthnRequestsSigned) is refused at registration; turn that setting off, or register with the sign-in URL and certificate instead of the metadata.
Enforcing that an organization may only sign in through SSO. Password and social sign-in remain available to its members.

Application traffic uses INFRO gateway keys independently of console sign-in. Scope keys to the appropriate project and environment, and revoke them when access is no longer needed. See Authentication.