Skip to content
Olivares AI docs

SSO, SCIM & identity sources (firm attribution)

Identity is the hard dependency under the whole access map: native audit attributes an access to a credential, and only an identity roster can bind that credential to an agent or person. This page wires the three identity surfaces: console SSO login, SCIM provisioning into the control plane, and the roster sources (LDAP, Okta, Entra ID) that make attribution attributed instead of approximate.

1. Console SSO (OIDC / SAML)

Section titled “1. Console SSO (OIDC / SAML)”

Federated login is served through the engine’s federation seam. The posture is honest by construction:

  • The login flow endpoints exist in every build, and the engine keeps every secret-bearing flow value server-side — the CSRF state, the OIDC nonce, the PKCE verifier (only the S256 challenge goes to the provider). Authorization Code + PKCE is always on.
  • Single-IdP OIDC/SAML login is available in every edition, Community included. Configure it through the console’s managed SSO settings. When no managed configuration exists, the engine uses the boot environment (OLIVARES_SSO_PROTOCOL, OLIVARES_OIDC_* or OLIVARES_SAML_*). Without a configured provider, the existing NoFederation fallback returns 501 sso_not_configured; this indicates missing configuration, not a protocol reserved for the commercial editions.
  • The redirect/ACS URI your IdP must carry is exact (…/v1/auth/federation/callback on your console origin — RFC 9700 exact matching, no prefix tricks).

The console’s Identity & NHI → SSO & SCIM tab documents the live configuration, checks your IdP’s redirect URI against the exact expected value, and shows the connection state — and where a panel’s backend is a declared contract not yet live, it says “backend pending” rather than rendering fabricated data:

The Identity & access view: users and groups, SSO sign-in, machine identities (NHI) and key posture. The Identity & access view: users and groups, SSO sign-in, machine identities (NHI) and key posture.

2. SCIM provisioning (inbound) — Business

Section titled “2. SCIM provisioning (inbound) — Business”

The inbound SCIM server is a Business capability (Identity & Scale). A Community server mounts the same URLs, authenticates the token and then answers HTTP 501 in the SCIM error shape, naming Business; nothing is read or written. In Community you remove a person from the organization in the console (People) or with DELETE /v1/members/{id}.

With Business, the control plane is a standard SCIM 2.0 (RFC 7644) service provider at:

/v1/scim/v2/Users
/v1/scim/v2/Groups
  • Auth: a tenant-bound admin/owner API token on the SCIM integration — the same opaque-token model as the rest of the API, no separate SCIM secret type. The URLs are always mounted (not feature-gated); Community answers 501 there.
  • Users provisions and deprovisions principals. Changes depend on delivery and successful processing of the SCIM request; check its response and the affected access rather than treating an HR event as proof of completed revocation. SCIM does not remove operating-system accounts.
  • Groups carries identity-to-group reference data. Each group can map to a control-plane role via mapped_role — and that mapping is operator-owned: it is set on the control-plane side and audited (scim.group.role.map); an IdP push never silently escalates a role. Unknown members in a pushed group are skipped and audited, not invented.

3. Roster sources: LDAP, Okta, Entra ID — Business/Enterprise

Section titled “3. Roster sources: LDAP, Okta, Entra ID — Business/Enterprise”

Roster sources feed module VI’s identity inventory and — this is the point — give module III the bindings that upgrade attribution:

{
  "sources": [
    {
      "name": "corp-ldap",
      "kind": "ldap",
      "tenant": "<tenant-id>",
      "config": {
        "url": "ldaps://ldap.corp.example:636",
        "bind_dn": "cn=olivares-ro,ou=svc,dc=corp,dc=example",
        "bind_password": "<reference>",
        "base_dn": "dc=corp,dc=example"
      }
    },
    {
      "name": "okta",
      "kind": "idp",
      "tenant": "<tenant-id>",
      "config": { "provider": "okta", "base_url": "https://corp.okta.com", "api_token": "<reference>" }
    }
  ]
}

Key LDAP options (from the shipped descriptor): user_filter / group_filter, privileged_group_dns (groups whose membership is itself a privileged-access signal), nhi_dn_suffix (which subtree holds non-human identities), start_tls, page_size. The idp kind takes provider: okta (with api_token) or provider: entra (with tenant_id / client_id / client_secret); okta and entra also work directly as the kind.

How this upgrades attribution — precisely

Section titled “How this upgrades attribution — precisely”

A roster source registers identities (by external id) and, where the directory declares them, permitted grants. When an observed edge’s origin matches a non-shared roster identity, module III ties the access to that identity and the edge’s confidence is upgraded to attributed. Identities that several workloads share stay honestly approximate — the roster cannot un-share a credential; only issuing per-agent identity can (the bridge to governance).

Dedicated agent-identity and workload-identity kinds (the agent federation sources — Entra Agent ID, AgentCore, SPIFFE and peers) are the firm per-agent signal; group/directory rosters sharpen people and service accounts.

Honest limits

Section titled “Honest limits”
  • Single-IdP SSO is included in Community. Multiple-IdP routing and login-time group mapping are provided by the corresponding private identity module. They do not change the availability of general users, groups and permission management.
  • A roster cannot fix a shared credential. It can only tell you, honestly, that the credential is shared.
  • SCIM is inbound provisioning — the control plane does not push identities back to your IdP, and the Security-Event-Token receiver is an inbound surface, not an outbound webhook.
Section titled “Related”