Fournisseurs d'identité

Ronne peut permettre de se connecter avec le fournisseur d'identité de votre entreprise (OpenID Connect) : Google Workspace, Microsoft Entra ID, Okta, Keycloak, authentik, Auth0, ou tout autre qui publie un document de découverte. Root le configure sous Admin › Settings › Authentication, dans le navigateur : rien à taper sur le serveur.

1. Ajoutez un fournisseur à partir de son préréglage, inscrivez Ronne chez le fournisseur avec l'URI de redirection que le formulaire affiche, et rapportez les valeurs qu'il demande (Ajouter un fournisseur).
2. Testez-le : Test connection, puis Test sign-in avec votre propre compte chez le fournisseur. Rien ne change tant qu'il n'est pas activé.
3. Activez-le. La page de connexion affiche Continue with <name>.

Quand quelqu'un se connecte avec lui, Ronne décide de qui il s'agit, dans cet ordre :

• Le fournisseur doit dire que le courriel est vérifié; sinon, la personne est refusée.
• Un compte désactivé est refusé.
• Une personne qui s'est déjà connectée avec ce fournisseur est ce même compte, même si son courriel a changé chez le fournisseur.
• Sinon, un compte qui a exactement ce courriel est relié, puis connecté, si le fournisseur relie par courriel et que le domaine du courriel fait partie de ceux qu'il liste (le compte de root aussi). Son mot de passe continue aussi de fonctionner.
• Sinon, si le domaine du courriel fait partie de ceux que le fournisseur liste, un nouveau compte est créé : un user dans global, avec un espace de travail personnel et sans mot de passe, jamais root.
• Toute autre personne est refusée, avec un message l'invitant à demander à root.

Ensuite, les groupes du fournisseur sont appliqués, et la session dure 24 heures au plus et se termine à la fermeture du navigateur : une personne désactivée chez le fournisseur perd normalement l'accès en un jour au plus. Pour couper l'accès de quelqu'un tout de suite, désactivez son compte dans Ronne : cela met fin à ses sessions et à ses jetons. Avec SCIM, le fournisseur le fait à sa prochaine synchronisation. La connexion à deux facteurs n'est pas demandée : le fournisseur demande sa propre deuxième étape. Root décide si les autres peuvent encore utiliser un mot de passe (Connexion par mot de passe), et root peut toujours se connecter avec un mot de passe (Verrouillage).

Sous Admin › Settings › Authentication › Identity providers, choisissez Add provider, puis la carte de votre fournisseur. Le formulaire remplit ce que le préréglage connaît et, à côté (en dessous sur un téléphone), se trouvent les étapes à suivre chez le fournisseur. Chaque préréglage a son propre guide plus bas.

• Provider id : de 3 à 32 lettres minuscules, chiffres et tirets, commençant et finissant par une lettre ou un chiffre. Il fait partie de l'URI de redirection : il ne peut donc pas être changé plus tard.
• L'URI de redirection, https://ronne.example.com/api/auth/sso/callback/<id> : inscrivez-la chez le fournisseur exactement telle qu'elle est affichée, avec Copy. Le fournisseur renvoie les gens à cette adresse après leur connexion, et seulement à une adresse inscrite chez lui; c'est pourquoi elle doit correspondre : elle est construite à partir de l'adresse publique de l'instance (PUBLIC_URL) et de l'identifiant.
• Display name, sur le bouton de connexion; l'URL de l'émetteur (exactement comme le document de découverte du fournisseur l'écrit, barre oblique finale comprise; le préréglage la construit à partir des éléments qu'il demande), l'ID client et le secret client, et les étendues (openid email profile, plus une étendue de groupes dont certains fournisseurs ont besoin).
• Le secret client est stocké chiffré et n'est plus jamais affiché : le formulaire indique Secret saved, avec Replace.
• Who may sign in : les domaines de courriel que ce fournisseur connecte, et s'il faut relier les comptes existants par courriel vérifié. Une nouvelle adresse de ces domaines obtient un compte à sa première connexion; un compte existant qui en a une est relié si la liaison est activée. Un compte d'un autre domaine n'est jamais relié : un fournisseur ne peut pas prendre une adresse qui n'est pas la sienne. Vide : seuls les comptes déjà reliés se connectent.
• Groups : la revendication de groupes et les associations de groupes (Groupes et rôles dans les espaces de travail).

Ensuite, sur la page du fournisseur :

1. Test connection vérifie le document de découverte du fournisseur, qu'il nomme l'émetteur que vous avez tapé, et ses clés, et indique ce qu'il a trouvé.
2. Test sign-in ouvre le fournisseur dans un nouvel onglet : connectez-vous là-bas avec votre propre compte. De retour sur la page, Ronne montre ce qu'il a reçu (le courriel et s'il est vérifié, le nom, les groupes) et ce qu'une vraie connexion en ferait (connecter, relier, créer ou refuser, et quels rôles dans les espaces de travail changent). Il ne change rien.
3. Turn on exige un Test sign-in réussi, fait par vous, des réglages tels qu'ils sont maintenant. Changer plus tard l'émetteur, le client, le secret ou les étendues le désactive jusqu'à ce qu'il réussisse de nouveau.

Le panneau affiche l'état de chaque fournisseur : Off, Tested, On ou Failing (son dernier test a échoué, trois connexions d'affilée ont échoué, ou son secret ne peut pas être lu après une restauration), et quand quelqu'un s'est connecté avec lui pour la dernière fois. Turn off arrête les connexions avec lui; les liens et les appartenances aux groupes restent. Delete le supprime : les comptes qui lui sont reliés restent et peuvent encore utiliser un mot de passe s'ils en ont un, et les rôles dans les espaces de travail que ses groupes ont donnés sont retirés (dans global, ils redeviennent user). Chaque changement figure dans le journal d'audit.

Erreurs courantes, pour tous les fournisseurs : une URI de redirection qui diffère d'une barre oblique ou de http/https; un émetteur sans la barre oblique finale que son document a (ou avec une qu'il n'a pas); un courriel que le fournisseur ne marque pas comme vérifié; et une revendication de groupes que l'application n'envoie pas. Test sign-in montre chacune.

Un fournisseur peut donner des rôles dans les espaces de travail à partir de ses groupes. Dans le formulaire du fournisseur, définissez la revendication de groupes (habituellement groups; le préréglage la connaît), puis ajoutez des lignes : groupe → espace de travail → rôle (user, moderator ou admin). Un groupe s'écrit exactement comme le fournisseur l'envoie, majuscules et minuscules comprises.

À chaque connexion avec le fournisseur :

• Chaque groupe associé dont la personne fait partie lui donne, dans son espace de travail, au moins le rôle associé. Deux groupes qui donnent le même espace de travail donnent le rôle le plus élevé.
• Un rôle donné par un groupe disparaît quand la personne quitte le groupe (ou descend à ce qu'un autre groupe donne encore), à sa prochaine connexion. Supprimer la dernière association fait de même.
• Une appartenance définie à la main n'est jamais changée, même pour l'élever. Dès que quelqu'un change une appartenance donnée par un groupe (dans Members), elle lui appartient : les groupes n'y touchent plus.
• Dans global, que personne ne quitte, un groupe peut élever le simple rôle user que tout le monde a; quand le groupe ne s'applique plus, le rôle redevient user.
• Root n'est jamais changé par les groupes, et les groupes ne rendent jamais personne root.
• Une revendication de groupes absente ne change rien. Entra l'omet au-delà de 200 groupes : n'assignez à l'application que les groupes que Ronne associe.
• Une association dont l'espace de travail a été supprimé est ignorée, et le formulaire en avertit. Les espaces de travail personnels ne peuvent pas être associés.

Chaque changement figure dans le journal d'audit comme un changement de membre, marqué comme venant du fournisseur. Test sign-in liste les changements que vos propres groupes feraient.