Authentification, utilisateurs et groupes

Ce domaine répond à deux questions de gestion : comment les personnes prouvent leur identité, et comment Opfield limite ce qu’elles peuvent modifier. Le responsable des identités maintient la connexion et la récupération ; les responsables des ressources définissent les groupes opérationnels ; les administrateurs de sécurité examinent les accès privilégiés. Le succès signifie que les personnes peuvent récupérer leur accès sans contourner les contrôles, et qu’un changement de rôle peut être appliqué et audité sans réécrire chaque ressource.

Opfield prend en charge des méthodes d’authentification indépendantes : OIDC, mot de passe local et code à usage unique par e-mail. Les passkeys s’enregistrent après la création du compte. La politique de MFA peut exiger l’enrôlement avant qu’un utilisateur ne reçoive une session normale. Les méthodes de connexion, l’authentification multifacteur, le fournisseur OIDC et le provisionnement des identités se configurent dans Settings > Authentication.

Utilisez les groupes comme frontière de permissions normale. Gardez un groupe d’administrateurs restreint et auditable, et séparez les opérateurs, les développeurs, les observateurs et l’automatisation. Bloquer ou supprimer un utilisateur révoque son accès tout en préservant l’attribution historique. Restaurer un utilisateur supprimé laisse le compte bloqué jusqu’à son activation explicite.

L’usurpation d’identité (impersonation) est un processus de support administratif et doit rester identifiable dans l’objet de la session et dans les enregistrements d’audit. Arrêtez l’usurpation pour rétablir la session d’administrateur d’origine ; n’émettez pas de jetons d’API normaux depuis une session d’usurpation.

Opfield ne fournit pas encore SCIM. La prise en charge de SCIM est prévue ; d’ici là, utilisez l’API d’administration prise en charge avec une automatisation OAuth limitée lorsque votre système d’identité peut appeler des API externes, ou maintenez un processus manuel documenté.

Conception de l’authentification

Activez au moins deux chemins de récupération pour les administrateurs avant de dépendre d’un fournisseur d’identité externe. Testez le comportement de redirection et de déconnexion OIDC, l’envoi des e-mails, la récupération du mot de passe local, l’enrôlement MFA et les codes de récupération avec des comptes hors production.

OIDC prouve l’identité mais n’accorde pas automatiquement un accès étendu au produit. Les permissions d’Opfield restent explicites. Si le fournisseur externe est indisponible, seules des méthodes configurées indépendamment peuvent rétablir l’accès.

Connecter votre fournisseur SSO (OIDC)

Opfield connecte les utilisateurs via un seul fournisseur OIDC par installation, comme Keycloak, Authentik, Microsoft Entra ID, Okta ou Google Workspace. Changer de fournisseur nécessite settings:opfield:edit et admin:system ; modifier les méthodes de connexion et le provisionnement des identités nécessite settings:opfield:edit.

Avant de commencer, vérifiez que Public URL dans Settings > General correspond à l’adresse qu’ouvrent les utilisateurs, par exemple https://opfield.example.com. L’URI de redirection est construite à partir d’elle.

1. Enregistrez Opfield dans le fournisseur d’identité. Créez une application web OpenID Connect (un client confidentiel avec le flux authorization code). Enregistrez l’URI de redirection <Public URL>/auth/callback, par exemple https://opfield.example.com/auth/callback. Le schéma, le nom d’hôte, le port et le chemin doivent correspondre exactement. Notez l’URL de l’émetteur (issuer), l’identifiant client et le secret client.

2. Renseignez le fournisseur. Ouvrez Settings > Authentication > OIDC provider :

   Champ	Valeur à saisir
   Display name	Le nom affiché sur le bouton de connexion : Sign in with ce nom. Laissez vide pour afficher Sign in with SSO.
   Issuer URL	L’émetteur du fournisseur, par exemple https://id.example.com/application/o/opfield/. Opfield y lit le document de découverte pour trouver les points de terminaison d’autorisation, de jeton et de clés.
   Client ID	L’identifiant client de l’étape 1.
   Client secret	Le secret de l’étape 1. Opfield le stocke chiffré et n’en affiche ensuite que les quatre derniers caractères. Lors d’une modification, laissez-le vide pour conserver le secret stocké.
   Redirect URI	La même URL de rappel que celle enregistrée à l’étape 1 : <Public URL>/auth/callback.
   Scopes	Séparés par des espaces ; openid est obligatoire. La valeur par défaut openid email profile fournit à Opfield l’adresse e-mail et le nom de l’utilisateur.

   Appuyez sur Save.

3. Décidez comment les comptes apparaissent. Dans Settings > Authentication > Identity provisioning :

   • Auto-create users on OIDC sign-in crée un compte Opfield la première fois qu’un utilisateur se connecte via le fournisseur. Désactivez-le lorsque chaque utilisateur doit d’abord être créé dans Administration > Users avec la méthode de connexion OIDC ; sa première connexion OIDC avec la même adresse e-mail revendique ce compte.
   • Require verified OIDC email n’accepte l’adresse e-mail que lorsque le fournisseur envoie email_verified: true.
   • Default group for new OIDC users est le groupe que reçoivent les utilisateurs créés automatiquement.

4. Activez OIDC. Dans Settings > Authentication > Sign-in methods, activez OIDC. Opfield le refuse avec OIDC_NOT_CONFIGURED tant que le fournisseur n’est pas enregistré.

5. Testez la connexion. Gardez votre session actuelle ouverte. Dans une fenêtre privée, ouvrez Opfield, choisissez Sign in with suivi de votre nom d’affichage et connectez-vous avec un compte de test. Vérifiez que l’utilisateur arrive dans le groupe attendu, puis connectez-vous une fois en tant qu’administrateur via le fournisseur.

6. Faites migrer les administrateurs. Dans Administration > Users > Configure User, définissez Sign-in method sur OIDC pour chaque administrateur qui doit utiliser le fournisseur. Changer de méthode déconnecte l’utilisateur partout ; le compte est lié au fournisseur lors de sa prochaine connexion.

7. Désactivez les autres méthodes si vous le souhaitez. Seulement après qu’un administrateur s’est connecté via le fournisseur, désactivez Email and password ou Email sign-in code dans Sign-in methods.

Ce qu’Opfield lit auprès du fournisseur

Claim	Usage
sub	L’identité de l’utilisateur chez le fournisseur. Associée à l’émetteur, elle lie le compte Opfield. Obligatoire.
email	Fait correspondre un utilisateur créé à l’avance et devient l’adresse e-mail du compte. Obligatoire lors de la première connexion.
email_verified	Vérifié lorsque Require verified OIDC email est activé.
name	Le nom de l’utilisateur dans Opfield. Les noms des utilisateurs OIDC sont gérés par le fournisseur et ne peuvent pas être modifiés dans Opfield.
picture	L’avatar de l’utilisateur.

Opfield ne fait pas correspondre les groupes ou les rôles du fournisseur. Les groupes et les scopes sont attribués dans Opfield ; les nouveaux utilisateurs reçoivent le groupe par défaut.

Un utilisateur qui s’est connecté via un fournisseur reste lié à son émetteur. Si vous remplacez Issuer URL par un autre fournisseur, ces utilisateurs ne peuvent pas se connecter via le nouveau (OIDC_ISSUER_MISMATCH). Pour faire migrer un tel utilisateur, passez sa Sign-in method dans Configure User à une autre méthode, puis de nouveau à OIDC ; il est lié à nouveau lors de sa prochaine connexion.

Remove, dans le panneau OIDC provider, supprime le fournisseur après confirmation et désactive la connexion OIDC.

API : PUT /api/admin/auth-settings avec oidc (issuer, clientId, clientSecret, redirectUri, scopes, displayName), methods ou oidcProviderAction: "remove" ; MCP et assistant : update_opfield_settings avec les mêmes champs.

Se connecter avec le compte Opfield

Une installation connectée à Opfield Cloud peut utiliser votre compte Opfield comme fournisseur OIDC au lieu d’enregistrer son propre SSO. Opfield demande au compte un client de connexion ; vous ne saisissez ni émetteur, ni identifiant client, ni secret. Allow remote management n’est pas nécessaire.

1. Vérifiez que Public URL est défini dans Settings > General. Le compte renvoie les utilisateurs vers <Public URL>/auth/callback ; sans URL publique, la demande est refusée avec PUBLIC_URL_REQUIRED.
2. Dans Settings > Authentication > OIDC provider, choisissez Use Opfield account. Le panneau affiche « Waiting for your Opfield account… Sign-in with it is set up as soon as it answers » et un bouton Cancel request. Choisir à nouveau le bouton n’envoie pas de seconde demande.
3. Lorsque le compte répond, Opfield ajoute le fournisseur « Opfield account » et active OIDC dans Sign-in methods. L’installation n’a qu’un seul fournisseur OIDC ; le compte Opfield remplace donc le fournisseur que vous aviez. Le panneau se met à jour de lui-même.
4. Laissez les personnes se connecter avec lui. Les utilisateurs sont mis en correspondance comme avec tout fournisseur OIDC : attribuez à un utilisateur existant la Sign-in method OIDC dans Configure User, et sa première connexion avec le compte Opfield de la même adresse e-mail revendique le compte ; les nouveaux utilisateurs sont créés lorsque Auto-create users on OIDC sign-in est activé. Testez-le dans une fenêtre privée avec Sign in with Opfield account.

Cancel request retire une demande à laquelle le compte n’a pas encore répondu. Si le passage au compte Opfield ne laissait aucun administrateur capable de se connecter, Opfield se contente de conserver le client reçu et ne modifie rien ; attribuez à un administrateur une méthode qui reste active, puis choisissez à nouveau Use Opfield account. Une fois que l’installation dispose d’un client, Use Opfield account rétablit immédiatement le fournisseur, par exemple après que vous l’avez supprimé ou que vous avez essayé votre propre SSO.

Lorsque quelqu’un perd l’accès à l’installation dans le compte Opfield, Opfield bloque son utilisateur, et Administration > Users affiche Blocked by the Opfield account. Sa prochaine connexion avec le compte Opfield, une fois que le compte lui a rendu l’accès, le débloque ; Unblock user fonctionne aussi. Voir Accès retiré dans le compte Opfield.

Le compte Opfield peut remplacer le secret client via la connexion tant que l’installation se connecte avec le fournisseur « Opfield account ». Lorsque vous déconnectez l’installation d’Opfield Cloud, ou que le compte la déconnecte, Opfield oublie le client, supprime le fournisseur « Opfield account » et désactive la connexion OIDC. Si aucun administrateur ne pouvait alors se connecter, le fournisseur est conservé et le panneau OIDC provider l’indique : attribuez à un administrateur une autre méthode de connexion, puis choisissez Remove.

API : PUT /api/admin/auth-settings avec oidcProviderAction: "opfield_account" ou "cancel_opfield_account" ; MCP et assistant : update_opfield_settings avec le même champ. Les paramètres signalent opfieldAccountSignIn avec available (connecté à Opfield Cloud), clientIssued, pendingRequest et detached. Sans connexion, l’action est refusée avec OPFIELD_ACCOUNT_CLIENT_MISSING.

Connexion par mot de passe et par code e-mail

Email and password et Email sign-in code dans Sign-in methods envoient des liens et des codes par e-mail ; ils nécessitent donc un SMTP vérifié dans Settings > Advanced > SMTP configuration : envoyez-y d’abord un test. Sans lui, l’activation de l’une ou l’autre méthode est refusée avec SMTP_NOT_VERIFIED. La méthode propre à un utilisateur se définit dans Administration > Users > Configure User > Sign-in method ; passer à Email and password envoie un lien de définition du mot de passe.

Le dernier administrateur garde un accès

Opfield refuse un changement après lequel aucun administrateur système ne pourrait se connecter. Il le vérifie lorsque vous désactivez OIDC, Email and password ou Email sign-in code, supprimez le fournisseur OIDC ou enregistrez un fournisseur doté d’un autre émetteur. Le changement est refusé avec LAST_ADMIN_SIGN_IN : « No administrator could sign in after this change. » Un administrateur ne compte que si sa propre méthode de connexion reste active et, pour OIDC, que s’il n’est pas lié à un autre émetteur. Les passkeys ne comptent pas. Attribuez à un autre administrateur, ou à vous-même, une méthode qui reste active, connectez-vous avec elle, puis effectuez le changement.

Sur une installation gérée par Opfield Cloud, le fournisseur commence par « Opfield account » et suit les mêmes règles ; voir Installations managées.

Cycle de vie des utilisateurs

1. Créez ou invitez l’utilisateur via un chemin d’authentification approuvé.
2. Exigez la MFA conformément à la politique avant d’accorder des scopes sensibles.
3. Ajoutez l’utilisateur à des groupes basés sur les rôles plutôt que de lui attribuer des permissions ponctuelles lorsque c’est possible.
4. Vérifiez que l’utilisateur peut accéder à une ressource prévue et se voit refuser une ressource hors périmètre.
5. Examinez les sessions, les jetons et l’appartenance aux groupes lorsque le rôle de l’utilisateur change.
6. Bloquez immédiatement le compte lorsque l’accès doit s’arrêter.
7. Ne supprimez qu’après le transfert des responsabilités et des dépendances d’automatisation.

Le blocage arrête toute nouvelle utilisation sans effacer l’attribution. La suppression reste visible dans l’historique d’audit. Restaurer un enregistrement supprimé ne le réactive pas silencieusement.

E-mails d’invitation

Un e-mail d’invitation informe un nouvel utilisateur qu’un administrateur a créé son compte Opfield et renvoie vers la page de connexion, avec une indication propre à sa méthode de connexion : le fournisseur d’identité, un code par e-mail ou l’e-mail distinct qui définit son mot de passe. L’envoi nécessite un SMTP vérifié et l’URL publique d’Opfield.

• Send invitation email, dans Administration > Users > Configure User, panneau Account, l’envoie à la main. Il est proposé une seule fois par utilisateur, et seulement jusqu’à sa première connexion ; après l’envoi, le panneau indique quand il a été envoyé. Il nécessite admin:users sur cet utilisateur.
• Settings > Authentication > Identity provisioning > Send an invitation email when an account is created l’envoie pour chaque compte créé dans la Console, l’API ou MCP. Il est désactivé par défaut et sa modification nécessite settings:opfield:edit. Si l’envoi échoue, le compte est tout de même créé et l’invitation peut être envoyée plus tard à la main.

API : POST /api/admin/users/{id}/invitation ; MCP et assistant : opération send_invitation de manage_user. La liste des utilisateurs renvoie lastLoginAt et invitationSentAt pour chaque utilisateur.

Conception des groupes

Séparez l’administration de la plateforme, l’administration de la sécurité, l’exploitation des applications, le développement, l’observation en lecture seule et l’automatisation. Utilisez des droits limités à un dossier, une Route, un nœud, une charge de travail, une base de données ou un projet Pages au lieu d’accorder toute une zone du produit.

La boîte de dialogue de groupe et les permissions supplémentaires d’un utilisateur présentent les accès sous forme de liste de lignes. Add Access en ajoute une : un Role, l’endroit où il s’applique (Where : Everywhere, In a project folder, In an app environment ou Specific resources) et ce qu’il couvre (Covers), ou un niveau d’accès sur des dépôts Git. Review N scopes ouvre les scopes eux-mêmes ; l’en-tête de chaque section y indique la portée des scopes de la section (Everywhere, un seul endroit ou N places) et permet de les limiter à des dossiers, des apps ou des environnements. Voir Restreindre les jetons et les autorisations OAuth.

Gardez le groupe d’administrateurs restreint et maintenez un chemin d’accès d’urgence documenté. Testez les changements de permissions avec une vraie session non administratrice ; une vue d’administrateur ne peut pas prouver que les refus fonctionnent.

Usurpation d’identité et support

N’utilisez l’usurpation d’identité que pour une investigation de support délimitée. La session doit rester visiblement marquée et auditable. Ne modifiez pas d’identifiants, ne créez pas de jetons d’administrateur durables et n’effectuez pas de travail sans rapport pendant que vous usurpez l’identité d’un autre utilisateur. Arrêtez l’usurpation avant de revenir à l’administration normale.

Provisionnement en attendant SCIM

Le provisionnement SCIM n’est pas encore disponible et aucune date de sortie n’est garantie. D’ici là, tenez une liste de contrôle des arrivées, mobilités et départs, et réconciliez les utilisateurs et les groupes manuellement ou via l’automatisation prise en charge par l’API REST et OAuth. N’accordez au client d’automatisation que les scopes d’utilisateurs et de groupes dont il a besoin, rendez les requêtes idempotentes et vérifiez un droit attendu et un refus attendu après chaque changement d’accès.

Reprise et prévention du verrouillage

Traitez la configuration des identités comme une dépendance de production. Avant de modifier la seule méthode de connexion qui fonctionne, créez et testez un second chemin d’administration dans un profil de navigateur distinct. Conservez les codes de récupération hors d’Opfield, vérifiez que l’e-mail de récupération du mot de passe local atteint la boîte aux lettres prévue, et consignez quelle équipe détient l’application OIDC et son secret client. Ne désactivez pas la méthode précédente tant qu’une nouvelle session ne peut pas se connecter, valider la MFA et atteindre une page réservée aux administrateurs via le chemin de remplacement.

Si les administrateurs sont verrouillés, rétablissez la dépendance externe défaillante ou utilisez la méthode indépendante testée au préalable. Évitez de modifier directement les lignes des utilisateurs, des sessions ou des groupes dans PostgreSQL : contourner l’application peut laisser incohérents les états de mot de passe, de MFA, de session et d’audit. Une fois l’accès rétabli, examinez les événements d’authentification récents, les sessions actives, l’appartenance aux groupes et l’état des codes de récupération avant de considérer l’incident comme clos.

Liste de vérification

• Connectez-vous via chaque méthode activée avec un compte hors production.
• Confirmez que l’enrôlement MFA est imposé avant l’émission d’une session privilégiée normale.
• Vérifiez qu’un utilisateur bloqué ne peut ni créer de nouvelle session ni utiliser un jeton existant.
• Vérifiez qu’un utilisateur restauré reste bloqué jusqu’à son activation explicite.
• Testez une action autorisée et une action refusée sur une ressource pour chaque groupe opérationnel.
• Confirmez que l’usurpation d’identité est visiblement marquée et que l’acteur dans l’audit reste attribuable.
• Réconciliez régulièrement les utilisateurs inactifs, les groupes inutilisés, les sessions périmées et les invitations en attente.

L’authentification prouve qui est l’appelant ; les groupes et les scopes décident de ce que cet appelant peut faire. Une connexion OIDC réussie ne doit jamais servir de preuve que l’utilisateur doit recevoir une autorité étendue dans Opfield.