Authentification unique
Connecter un fournisseur d'identité OpenID Connect dans la console, donner des rôles à ses groupes et se connecter avec un compte d'organisation.
Kyvernon connecte les utilisateurs par un fournisseur d'identité qui parle OpenID Connect. Il utilise le flux de code d'autorisation avec PKCE et lit les groupes de l'utilisateur dans un claim du jeton d'identité. Le fournisseur effectue l'authentification, y compris son propre second facteur. Vous avez besoin du privilège Global.Settings sur la racine.
Avant de commencer, enregistrez Kyvernon comme client chez le fournisseur et notez l'adresse de l'émetteur, l'identifiant du client et le secret du client. Faites en sorte que le fournisseur envoie les groupes de l'utilisateur dans un claim, groups par défaut, par exemple avec la portée groups. Conservez l'administrateur local et le compte de secours (break-glass) : ils donnent accès quand le fournisseur est indisponible.
Dans la console
Ouvrez le Menu utilisateur en haut à droite, sélectionnez Administration, puis dans la liste de gauche sélectionnez Authentification unique. Le titre Fournisseur d’identité indique l'état, Configuré ou Non configuré.
(Agrandir)
- Saisissez l'URL de l’émetteur : l'adresse https du fournisseur. Kyvernon lit le document de découverte à
<issuer>/.well-known/openid-configuration. - Saisissez le Identifiant client et le Secret client que le fournisseur vous a donnés. Le secret est conservé et n'est plus jamais affiché. Quand un secret est conservé, laissez le champ vide pour le garder, ou saisissez-en un nouveau pour le remplacer.
- Vérifiez la URI de redirection. La console renseigne l'adresse sous laquelle vous l'avez atteinte, et vous enregistrez exactement cette adresse chez le fournisseur.
- Sous Portées, listez les portées en plus de
openid, séparées par des espaces, par exempleprofile email groups. Sous Revendication des groupes, indiquez le claim qui contient les noms de groupes. Sous Délai pour terminer la connexion (minutes), saisissez un nombre entier de 1 à 60. - Sélectionnez Enregistrer.
La page de connexion propose maintenant le bouton Se connecter avec votre organisation, ou Se connecter avec ... avec le nom d'hôte de l'émetteur, au-dessus de la ligne ou utilisez un compte local et du formulaire de connexion locale. Un utilisateur sélectionne le bouton, se connecte chez le fournisseur et revient à la console.
Un utilisateur fédéré n'a d'abord aucun rôle. Donnez un rôle au groupe que le fournisseur envoie : sur l'écran Autorisations, ajoutez une autorisation pour le Groupe dont le nom est la valeur du claim des groupes, comme décrit dans Rôles et autorisations.
Pour arrêter la connexion par le fournisseur, sélectionnez Supprimer le fournisseur et confirmez. Les comptes restent et la connexion locale continue de fonctionner ; assurez-vous donc d'abord qu'au moins un administrateur local peut se connecter.
Note
L'écran nécessite un plan de contrôle qui propose ce paramètre. Sur un plan de contrôle qui ne le propose pas, il affiche Pas encore disponible sur ce plan de contrôle ; la section Automatisation décrit la méthode qui fonctionne aujourd'hui.
Résultat
Les personnes du fournisseur se connectent avec le compte d'organisation. Un compte fédéré est créé à la première connexion, avec le nom d'utilisateur préféré du fournisseur en minuscules comme nom d'utilisateur, ou oidc:<subject> quand le fournisseur n'en envoie aucun. Kyvernon met à jour les groupes, l'adresse e-mail et le nom affiché à chaque connexion ; un changement de groupe chez le fournisseur s'applique donc à la connexion suivante, et un utilisateur que vous désactivez reste refusé. Un utilisateur fédéré dont le nom est identique à celui d'un utilisateur local est refusé, afin qu'un compte local ne puisse pas être repris. Le journal d'audit consigne chaque connexion sous identity.login.oidc avec l'émetteur ; voir Sessions et audit.
La CLI se connecte avec un mot de passe ou un jeton ; un utilisateur fédéré qui a besoin de la CLI demande donc un jeton d'API à un administrateur.
Automatisation
Avec la CLI
Le fournisseur se définit de façon native, sans modifier le fichier de configuration. Affichez le réglage actuel, définissez le fournisseur et supprimez-le :
kyvernon users oidc
kyvernon users set-oidc --issuer https://idp.example.com --client-id kyvernon \
--client-secret-file /root/oidc-secret \
--redirect-uri https://controller.example.com/v1/identity/oidc/callback \
--scope profile --scope email --scope groups --groups-claim groups --login-ttl 600
kyvernon users remove-oidc--client-secret-file lit le secret dans un fichier, ou sur l'entrée standard avec -. Sans cette option, le secret stocké est conservé ; elle est obligatoire la première fois, sauf si la section [oidc] de controller.toml en contient déjà un. Avant de stocker quoi que ce soit, le contrôleur exécute la découverte OpenID à <issuer>/.well-known/openid-configuration. Un fournisseur qui ne répond pas est refusé avec error.identity.oidc_unreachable, et le fournisseur stocké reste en place.
Le réglage remplace la section [oidc] de controller.toml. remove-oidc supprime le fournisseur, et désactive aussi un fournisseur issu de la section [oidc]. La connexion locale reste disponible.
Vous pouvez aussi définir le fournisseur dans la section [oidc] de la configuration du contrôleur : émetteur, identifiant du client, fichier contenant le secret du client, adresse de redirection, portées et claim des groupes. Redémarrez le contrôleur après la modification, puis vérifiez que la console propose le fournisseur :
kyvernon auth configLa réponse montre oidc avec enabled à true et le libellé du bouton. Donnez un rôle au groupe que le fournisseur envoie :
kyvernon roles list
kyvernon permissions set group-d1 vm-admins --group --role <role-id>group-d1 est le dossier racine et vm-admins est la valeur du claim des groupes.
Avec l'API
GET /v1/auth/config indique à un client, avant que quiconque se soit connecté, si le fournisseur est configuré. Le flux par navigateur utilise GET /v1/identity/oidc/start, qui renvoie l'adresse du fournisseur et définit un cookie liant la connexion au navigateur, et GET /v1/identity/oidc/callback, que le fournisseur appelle. Les clients programmatiques n'utilisent pas ces routes.
Le fournisseur lui-même se gère avec GET, PUT et DELETE /v1/identity/oidc/config. Les trois exigent Global.Settings, et les modifications sont auditées. La vue contient ces champs :
| Champ | Signification |
|---|---|
configured | Indique si un fournisseur est défini. |
issuer, clientId, redirectUri, scopes, groupsClaim, loginTtlSeconds | Les paramètres en vigueur. |
clientSecretSet | Indique si un secret est stocké. Le secret n'est jamais renvoyé. |
source | console, configuration ou none. |
PUT accepte ces champs :
| Champ | Signification |
|---|---|
issuer | L'adresse https du fournisseur. |
clientId | L'identifiant du client. |
clientSecret | En écriture seule. Vide ou absent, il conserve le secret stocké. Obligatoire la première fois, sauf si la section [oidc] de controller.toml en contient déjà un. |
redirectUri | Normalement https://<contrôleur>/v1/identity/oidc/callback. |
scopes | Portées en plus de openid. |
groupsClaim | Le claim qui contient les noms de groupes. Par défaut groups. |
loginTtlSeconds | De 60 à 3600. |
Le secret est scellé avec la clé d'identité du contrôleur dans le store répliqué. DELETE supprime le fournisseur.
Voir aussi
- Rôles et autorisations donne leur accès aux groupes.
- Dépannage de l'identité liste les messages d'une connexion échouée.
Version 0.1. Dernière modification : 2026-11-14