DocsAdministerSSO and SCIM

SSO and SCIM

Two halves of the same job. SSO decides who is signing in. SCIM decides who exists at all.

Running SSO without SCIM is the common half-measure, and it means a departing employee keeps an account until somebody remembers.

OIDC

Any OIDC provider works. Okta, Entra, Auth0 and Keycloak are the ones people bring most often, and none of them needs anything specific from Memnox beyond the configuration below.

json
{
  "oidc": {
    "issuer": "https://acme.okta.com",
    "jwksUri": "https://acme.okta.com/oauth2/v1/keys",
    "audience": "memnox-cloud",
    "roleClaim": "groups",
    "roleMapping": { "memnox-admins": "admin", "eng": "reviewer" }
  }
}

The signature is verified against the provider's JWKS before a single claim is read, and only asymmetric algorithms are accepted, so alg: none and HMAC forgeries are rejected outright.

A verified user whose groups map to nothing is rejected, unless you set defaultRole. Failing closed here is deliberate: a mapping typo should lock people out loudly, not quietly grant everyone the default.

Machine bearer tokens keep working alongside SSO, so nothing your team automated breaks on the day you switch it on.

SAML

Settings → SSO publishes the service-provider metadata. Hand that link to whoever administers the IdP; it contains everything they need to configure the application, so nobody has to transcribe entity ids by hand.

SCIM

Standard SCIM 2.0. Your IdP creates accounts when somebody joins, updates them when they move team, and deactivates them when they leave.

Mapping groups to roles

Keep the mapping small and boring:

IdP group

memnox-admins

admin

eng-leads, security

reviewer

everybody else

viewer, or nothing

Two failure modes to avoid:

  • Mapping a group everybody is in to reviewer. Approvals then mean nothing, because approval is only worth something when the approver was chosen.
  • Mapping nothing and setting defaultRole: admin. This is the same as having no SSO configuration at all, with extra steps.

Which sign-in do I get?

Configuration

Google only

Google sign-in; roles from provisioned accounts

OIDC configured

Both work: your IdP for people, bearer tokens for machines

SAML configured

Sign-in through your IdP, alongside whatever else is configured

Nothing configured

No interactive sign-in at all; bearer tokens only

Plan

SSO is an Enterprise feature. The runtime itself never needed an account of any kind, so this applies to the hosted control plane only.