Identity, SSO & Access Control
DuoKey integrates with your existing identity provider (IdP) so users authenticate with their corporate credentials — no separate user store to manage, and full alignment with your access-governance policies.
Supported identity providers
DuoKey integrates with a defined set of OpenID Connect (OIDC) identity providers — it is not an arbitrary "any standards-compliant IdP" integration. SAML 2.0 is not supported, and configuring a provider outside the list below is rejected.
| Identity provider | Protocol | Notes |
|---|---|---|
| Microsoft Entra ID (Azure AD) | OIDC | Most common enterprise IdP |
| Okta | OIDC | SaaS or on-prem agents |
| Keycloak / Red Hat SSO | OIDC | Recommended for fully on-prem / air-gap; also brokers LDAP/Active Directory and ADFS behind it |
| Ping Identity | OIDC | |
| RSA SecurID Access | OIDC | |
| ForgeRock | OIDC | |
| UAE Pass | OIDC | UAE national digital-identity provider |
For disconnected environments, Keycloak (Red Hat build of Keycloak) deployed on-premise acts as the broker between DuoKey and your internal AD/LDAP (or an on-prem ADFS) — no external SaaS dependency, and no direct DuoKey connector for LDAP/AD/ADFS is needed.
Authentication flow (OIDC SSO)
The Cockpit redirects the user to your IdP for OIDC authentication and MFA; the IdP returns an ID token with group and role claims, and the Cockpit establishes an RBAC-mapped session.
Single Sign-On (SSO) & MFA
- SSO — users authenticate once against your IdP and are transparently signed in to DuoKey; sessions follow your IdP's lifetime and revocation policies.
- MFA — multi-factor is enforced at the IdP, so DuoKey automatically inherits your existing MFA policy (TOTP, FIDO2/WebAuthn, smart card / PIV/CAC).
- Smart card / PIV / CAC — for defense environments, certificate-based authentication is supported when fronted by an IdP or reverse proxy that performs the client-certificate handshake.
Automated provisioning (SCIM)
Where your IdP supports SCIM 2.0, user and group lifecycle can be automated:
- Joiner / mover / leaver events propagate automatically.
- Deprovisioning is immediate when a user is disabled in the IdP.
- No manual account management inside DuoKey.
Role mapping & RBAC
IdP group claims are mapped to DuoKey roles, enforcing least privilege:
| IdP group (example) | DuoKey role | Capabilities |
|---|---|---|
duokey-admins | Administrator | Full configuration, user & key policy management |
duokey-operators | Operator | Key lifecycle operations, monitoring |
duokey-auditors | Auditor | Read-only access to logs and configuration |
duokey-users | User | Consume keys per assigned policy |
For regulated and defense customers, configure separation of duties so that, for example, auditors cannot modify policy and operators cannot read audit configuration. Role definitions are tailored during onboarding.
Platform-level access (OpenShift)
Administrative access to the OpenShift cluster itself is also brokered through your IdP via the OpenShift OAuth server (OIDC/LDAP identity provider), so platform admins use the same corporate identities and MFA. Cluster RBAC is configured for least privilege — see Hardening.
Best practices
- Centralize all authentication at the IdP — disable local accounts except a sealed break-glass administrator stored in your privileged-access vault.
- Enforce MFA for every role; require phishing-resistant factors (FIDO2 / PIV) for administrators.
- Use short session lifetimes and IdP-driven revocation.
- Review group-to-role mappings as part of periodic access recertification.