Skip to main content

Federate your identity provider

Automentic does not ask you to run a second identity system. It federates with the identity provider you already operate, so agents and their human approvers inherit the same groups, policies and joiner-mover-leaver rules as your people.

Outline — pending the product API

The model below is settled; the exact configuration steps depend on the Automentic control plane, which is not yet available. This page will be completed with real screens, field names and values once it is.

What is described here is accurate. What is missing is marked [pending].

What you need​

  • An identity provider that speaks OpenID Connect or SAML 2.0. Both are supported; OIDC is preferred for new deployments.
  • Permission to register an application (client) with it.
  • A claim that carries the customer organisation or tenant.

Any compliant provider works, because federation happens at the protocol level rather than through per-vendor connectors.

How it fits together​

Your IdP  ──OIDC/SAML──▶  Automentic control plane
                              │
                              │ issues X.509 / SPIFFE identity
                              ▼
                          Your agents  ──mTLS──▶  Your systems

Two distinct things are happening, and it is worth keeping them separate:

  • Humans authenticate against your IdP. Automentic never sees a password.
  • Agents authenticate with an identity Automentic issues, anchored to a CA you choose.

Steps​

  1. Register a client with your IdP. Redirect URI: [pending — control plane callback URL]
  2. Choose scopes. At minimum openid profile email, plus whichever scope exposes the organisation claim.
  3. Map the tenancy claim. Keycloak and Auth0 commonly use a custom organisation; Microsoft Entra ID exposes tid. [Pending: where this is configured.]
  4. Map groups to roles. [Pending: the role model.]
  5. Test with one user before enabling it for everyone.

A working reference​

The customer portal built for this project already implements this pattern end to end — OIDC Authorization Code with PKCE, tokens held server-side only, tenancy read from a configurable claim — and is verified against a local OpenID Connect provider. It is a working reference for how federation behaves, and it runs entirely on localhost.