Identity Provider Integration

For routine sign-in, AlmaForge authenticates operators through your existing identity provider over OIDC or the GitHub OAuth integration. The cluster does not store passwords or offer local password accounts. SSO provides who the operator is. RBAC decides what they can do. Break-glass access uses the local admin identity on an Auth host for initial setup or emergency recovery when SSO is unavailable.

The bridge between the two is claimsToRoles: each OIDCConnector maps IdP groups or claims to AlmaForge roles. A user signs in through the IdP, the connector resolves their claims, and the matching roles are attached to the short-lived certificate the cluster issues.

Choose a provider

Per-provider setup with the exact app type, redirect URI, scopes, and claim shape:

• OIDC (generic) - use this for an OpenID Connect provider without a dedicated guide below.
• Google Workspace
• Microsoft Entra ID
• Okta
• GitHub
• Multi-SSO - run more than one connector at the same time and let operators pick at login.

Admin bootstrap

Configure the first connector through either deployment files or the local admin identity on an Auth host:

• Startup drop-in: place the connector under /etc/almaforge/almad.d before starting almad. See Step 4 of the Linux deployment guide or Kubernetes Step 5.
• On-host administration: after the cluster starts, run sudo alma login --breakglass on an Auth host and open the one-time link to configure the connector in the Web UI. You can also apply the connector directly on that host with sudo alma apply -f oidc-connector.yaml. Both paths require access to the root-owned Auth data directory. Follow the Standalone guide for the complete procedure.

Map an IdP group or claim to the admin role in that connector, then complete an SSO sign-in before adding further role mappings.