Identité, SSO et contrôle d'accès
DuoKey s'intègre à votre fournisseur d'identité (IdP) existant afin que les utilisateurs s'authentifient avec leurs identifiants d'entreprise — aucun annuaire d'utilisateurs distinct à gérer, et un alignement complet avec vos politiques de gouvernance des accès.
Fournisseurs d'identité pris en charge
DuoKey prend en charge tout IdP conforme aux standards via OpenID Connect (OIDC) et SAML 2.0 :
| Fournisseur d'identité | Protocole | Remarques |
|---|---|---|
| Microsoft Entra ID (Azure AD) | OIDC / SAML | IdP d'entreprise le plus courant |
| Keycloak / Red Hat SSO | OIDC / SAML | Recommandé pour les environnements entièrement on-prem / air-gap |
| Okta | OIDC / SAML | SaaS ou agents on-prem |
| Ping Identity | OIDC / SAML | |
| ADFS | SAML / OIDC | Fédération Active Directory on-prem |
| LDAP / Active Directory | LDAP(S) | Liaison directe via Keycloak ou OpenShift OAuth |
Pour les environnements déconnectés, Keycloak (build Red Hat de Keycloak) déployé on-premise agit comme courtier entre DuoKey et votre AD/LDAP interne — aucune dépendance SaaS externe.
Flux d'authentification (SSO OIDC)
Authentification unique (SSO) et MFA
- SSO — les utilisateurs s'authentifient une seule fois auprès de votre IdP et sont connectés de manière transparente à DuoKey ; les sessions suivent les politiques de durée de vie et de révocation de votre IdP.
- MFA — l'authentification multifacteur est imposée au niveau de l'IdP, si bien que DuoKey hérite automatiquement de votre politique MFA existante (TOTP, FIDO2/WebAuthn, carte à puce / PIV/CAC).
- Carte à puce / PIV / CAC — pour les environnements de défense, l'authentification par certificat est prise en charge lorsqu'elle est fournie par un IdP ou un reverse proxy qui effectue la négociation par certificat client.
Provisionnement automatisé (SCIM)
Lorsque votre IdP prend en charge SCIM 2.0, le cycle de vie des utilisateurs et des groupes peut être automatisé :
- Les événements d'arrivée / mutation / départ se propagent automatiquement.
- Le déprovisionnement est immédiat lorsqu'un utilisateur est désactivé dans l'IdP.
- Aucune gestion manuelle des comptes dans DuoKey.
Mappage des rôles et RBAC
Les revendications de groupe de l'IdP sont mappées aux rôles DuoKey, imposant le moindre privilège :
| Groupe IdP (exemple) | Rôle DuoKey | Capacités |
|---|---|---|
duokey-admins | Administrateur | Configuration complète, gestion des utilisateurs et des politiques de clés |
duokey-operators | Opérateur | Opérations de cycle de vie des clés, supervision |
duokey-auditors | Auditeur | Accès en lecture seule aux journaux et à la configuration |
duokey-users | Utilisateur | Consommation des clés selon la politique assignée |
Pour les clients réglementés et de défense, configurez la séparation des tâches afin que, par exemple, les auditeurs ne puissent pas modifier les politiques et les opérateurs ne puissent pas lire la configuration d'audit. Les définitions de rôles sont adaptées lors de l'onboarding.
Accès au niveau de la plateforme (OpenShift)
L'accès administratif au cluster OpenShift lui-même est également géré via votre IdP par l'intermédiaire du serveur OAuth d'OpenShift (fournisseur d'identité OIDC/LDAP), de sorte que les administrateurs de plateforme utilisent les mêmes identités d'entreprise et le même MFA. Le RBAC du cluster est configuré selon le moindre privilège — voir Renforcement.
Bonnes pratiques
- Centralisez toute l'authentification au niveau de l'IdP — désactivez les comptes locaux à l'exception d'un administrateur de secours (break-glass) scellé, stocké dans votre coffre d'accès à privilèges.
- Imposez le MFA pour chaque rôle ; exigez des facteurs résistants au phishing (FIDO2 / PIV) pour les administrateurs.
- Utilisez des durées de session courtes et une révocation pilotée par l'IdP.
- Passez en revue les mappages groupe-vers-rôle dans le cadre de la recertification périodique des accès.