Authentification OIDC
Medulla permet d'utiliser un fournisseur d'identité compatible OpenID Connect (OIDC) afin d'authentifier les utilisateurs de la plateforme.
OpenID Connect est un protocole d'authentification reposant sur OAuth 2.0. Il permet à Medulla de déléguer l'authentification à un fournisseur d'identité externe, également appelé Identity Provider ou IdP, tout en conservant la gestion des profils, des entités, des ACL et des autorisations dans Medulla.
Cette architecture permet de centraliser la gestion des identités de votre organisation et de proposer une expérience de connexion unifiée, ou Single Sign-On (SSO), avec les autres applications de votre système d'information.
Medulla est compatible avec les fournisseurs d'identité prenant en charge le standard OpenID Connect, notamment :
• Microsoft Entra ID ;
• Keycloak ;
• Authentik ;
• Okta ;
• Google Workspace ;
• Auth0 ;
• Ping Identity ;
• FusionAuth ;
• tout autre fournisseur d'identité compatible OpenID Connect.
L'utilisation d'OIDC permet notamment :
• de centraliser l'authentification des utilisateurs ;
• de bénéficier du Single Sign-On ;
• d'appliquer l'authentification multifacteur si elle est activée chez le fournisseur d'identité ;
• d'appliquer les politiques de sécurité et d'accès conditionnel de l'organisation ;
• de simplifier la gestion du cycle de vie des comptes utilisateurs.
Important :
L'authentification et les autorisations sont deux mécanismes distincts. Le fournisseur OIDC vérifie l'identité de l'utilisateur, tandis que Medulla reste responsable de la gestion de ses profils, de ses ACL, de ses entités et de ses permissions. Un utilisateur peut donc être authentifié avec succès sans disposer immédiatement des autorisations nécessaires pour accéder à la plateforme.
Fonctionnement de l'authentification OIDC
Lorsqu'un utilisateur accède à Medulla avec l'authentification OIDC, le processus suivant est exécuté :
1. L'utilisateur accède à l'interface Medulla
2. Medulla redirige l'utilisateur vers le fournisseur d'identité OIDC
3. L'utilisateur s'authentifie auprès du fournisseur d'identité
4. Le fournisseur d'identité applique ses propres politiques de sécurité, notamment l'authentification multifacteur ou l'accès conditionnel
5. Après validation de l'identité, le fournisseur retourne un jeton d'identité à Medulla
6. Medulla vérifie la validité du jeton et les informations d'identité qu'il contient
7. Si l'utilisateur n'existe pas encore dans Medulla, son compte est créé automatiquement
8. Medulla applique les profils, les entités et les autorisations attribués à cet utilisateur
Information :
Lors de la première authentification, aucun droit n'est automatiquement attribué au nouvel utilisateur. Un administrateur Medulla doit ensuite lui affecter un profil et une entité.
Prérequis
Avant de configurer l'authentification OIDC, vérifiez les éléments suivants :
• le fournisseur d'identité OpenID Connect est opérationnel ;
• une application ou un client dédié à Medulla a été créé chez le fournisseur d'identité ;
• le Client ID est disponible ;
• le Client Secret est disponible lorsqu'il est requis ;
• l'URL de découverte ou les différentes URL OIDC sont disponibles ;
• les URL de redirection autorisées sont correctement déclarées ;
• le serveur Medulla peut joindre le fournisseur d'identité en HTTPS ;
• les certificats TLS du fournisseur d'identité sont valides et reconnus par le serveur Medulla ;
• l'heure du serveur Medulla est synchronisée avec une source NTP ;
• les scopes et les claims nécessaires sont configurés chez le fournisseur d'identité.
Important :
Une différence d'heure importante entre le serveur Medulla et le fournisseur d'identité peut entraîner le rejet des jetons OIDC, même si le reste de la configuration est correct.
Informations nécessaires à la configuration
La configuration OIDC de Medulla nécessite généralement les informations suivantes :
|
Paramètre |
Description |
|
Client ID |
Identifiant public du client ou de l'application Medulla enregistré chez le fournisseur d'identité |
|
Client Secret |
Secret utilisé pour authentifier Medulla auprès du fournisseur OIDC, lorsqu'il est requis |
|
Discovery URL |
Adresse du document de découverte OpenID Connect contenant les différentes URL du fournisseur |
|
Authorization Endpoint |
Adresse vers laquelle l'utilisateur est redirigé pour s'authentifier |
|
Token Endpoint |
Adresse utilisée par Medulla pour obtenir ou valider les jetons |
|
UserInfo Endpoint |
Adresse permettant de récupérer les informations de l'utilisateur, lorsqu'elle est utilisée |
|
Redirect URI |
Adresse de retour vers Medulla après l'authentification de l'utilisateur |
|
Scopes |
Informations que Medulla est autorisé à demander au fournisseur d'identité |
|
Claims |
Attributs retournés dans le jeton, par exemple l'identifiant, l'adresse e-mail, le nom ou le prénom |
Scopes recommandés
Les scopes suivants sont généralement nécessaires :
openid
profile
emailLe scope openid est obligatoire pour utiliser OpenID Connect. Les scopes profile et email permettent de récupérer les principales informations nécessaires à la création du compte utilisateur.
Configurer le fournisseur d'identité
Depuis la console d'administration de votre fournisseur d'identité :
1. Créez une nouvelle application ou un nouveau client OIDC dédié à Medulla
2. Sélectionnez un flux d'authentification compatible avec une application Web
3. Déclarez l'URL de redirection fournie pour votre environnement Medulla
4. Autorisez les scopes nécessaires, notamment openid, profile et email
5. Vérifiez que les claims attendus sont présents dans le jeton d'identité
6. Récupérez le Client ID
7. Générez ou récupérez le Client Secret si nécessaire
8. Relevez l'URL de découverte OpenID Connect
9. Enregistrez les modifications
Attention :
Le Client Secret est une information sensible. Il ne doit jamais être publié dans une documentation, transmis par un canal non sécurisé ou enregistré dans un outil accessible à des utilisateurs non autorisés.
URL de découverte
La plupart des fournisseurs d'identité exposent un document de découverte à une adresse similaire à :
https://fournisseur.example.com/.well-known/openid-configurationPour certains fournisseurs, le domaine, le tenant ou le realm doit apparaître dans l'adresse.
Exemple générique avec un realm :
https://fournisseur.example.com/realms/mon-realm/.well-known/openid-configurationCe document permet notamment de récupérer automatiquement :
• le Token Endpoint ;
• le UserInfo Endpoint ;
• l'adresse des clés publiques utilisées pour vérifier les jetons ;
• les scopes et les mécanismes d'authentification supportés.
Configurer OIDC dans Medulla
Renseignez dans la configuration Medulla les informations obtenues auprès du fournisseur d'identité :
• le Client ID ;
• le Client Secret, lorsqu'il est requis ;
• l'URL de découverte ou les différents endpoints OIDC ;
• les scopes demandés ;
• les claims utilisés pour identifier et créer les utilisateurs ;
• l'URL publique de Medulla et l'URL de redirection correspondante.
Après avoir enregistré la configuration, utilisez une fenêtre de navigation privée afin de tester le processus d'authentification sans réutiliser une session existante chez le fournisseur d'identité.
Bonne pratique :
Conservez un compte administrateur natif Medulla fonctionnel pendant la configuration et les premiers tests OIDC. Ce compte permettra de corriger la configuration ou d'attribuer les droits aux premiers utilisateurs OIDC.
Claims utilisés pour créer l'utilisateur
Le fournisseur OIDC retourne les informations de l'utilisateur sous la forme de claims.
Les claims couramment utilisés sont :
|
Claim |
Utilisation |
|
sub |
Identifiant unique de l'utilisateur chez le fournisseur d'identité |
|
preferred_username |
Identifiant utilisateur privilégié |
|
|
Adresse e-mail de l'utilisateur |
|
given_name |
Prénom de l'utilisateur |
|
family_name |
Nom de famille de l'utilisateur |
|
name |
Nom complet de l'utilisateur |
Important :
Le claim utilisé comme identifiant doit être stable et unique. Évitez d'utiliser un attribut susceptible de changer fréquemment si ce changement peut entraîner la création d'un second compte dans Medulla.
Première connexion d'un utilisateur
Après la configuration de l'authentification OIDC, demandez à l'utilisateur de se connecter une première fois à Medulla.
Cette première connexion permet à Medulla de :
• rediriger l'utilisateur vers le fournisseur d'identité ;
• valider son authentification ;
• récupérer les claims retournés par le fournisseur ;
• créer automatiquement son compte dans la base locale ;
• rendre l'utilisateur disponible dans l'interface d'administration de Medulla.
Lors de cette première connexion, il est normal que l'utilisateur obtienne le message suivant :
You do not have required rightsInformation :
Ce message indique que l'authentification OIDC fonctionne et que le compte utilisateur a été créé. Il ne s'agit pas d'une erreur d'authentification : aucun profil ni aucune entité n'ont simplement encore été attribués à l'utilisateur.
Attribuer des droits à un utilisateur OIDC
Étape 1 – Se connecter avec un administrateur
Connectez-vous à Medulla avec un compte disposant déjà des droits nécessaires pour gérer les utilisateurs et les entités.
Pour la première configuration, il est recommandé d'utiliser le compte administrateur natif root.
Étape 2 – Ouvrir la gestion des utilisateurs
Accédez au module :
Administration
└── Entities ManagementSélectionnez l'entité racine ou l'entité concernée, puis cliquez sur :
Manage Users
Étape 3 – Rechercher l'utilisateur
Recherchez l'utilisateur créé automatiquement lors de sa première connexion OIDC.
Sur la ligne correspondant à cet utilisateur, cliquez sur :
Edit
Étape 4 – Attribuer les autorisations
Définissez les paramètres suivants :
• le profil utilisateur ;
• l'entité autorisée ;
• le mode récursif si le profil doit s'appliquer à toutes les sous-entités de l'entité choisie.
Les profils disponibles sont notamment :
• Super-Admin ;
• Admin ;
• Technician.
Enregistrez ensuite les modifications.
Principe du moindre privilège :
N'attribuez que les droits nécessaires aux missions de l'utilisateur. Le profil Super-Admin doit être réservé aux personnes chargées de l'administration complète de Medulla.
Valider l'accès de l'utilisateur
Une fois les droits attribués :
1. Demandez à l'utilisateur de fermer sa session Medulla
2. Si nécessaire, demandez-lui également de fermer sa session auprès du fournisseur d'identité
3. Demandez-lui de se reconnecter à Medulla via OIDC
4. Vérifiez qu'il accède aux entités et aux fonctionnalités correspondant à son profil
Les nouveaux droits seront pris en compte lors de la reconnexion.
Résolution des problèmes
L'utilisateur reçoit « You do not have required rights »
Ce message signifie que :
• l'authentification OIDC fonctionne ;
• le compte de l'utilisateur a été créé dans Medulla ;
• aucun profil ou aucune entité ne lui ont encore été attribués.
Connectez-vous avec un administrateur, affectez un profil et une entité à l'utilisateur, puis demandez-lui de se reconnecter.
L'utilisateur n'apparaît pas dans Medulla
Vérifiez que :
• l'utilisateur a effectué une première tentative de connexion ;
• l'authentification chez le fournisseur d'identité s'est terminée avec succès ;
• l'utilisateur existe et est actif chez le fournisseur d'identité ;
• l'utilisateur est autorisé à accéder à l'application Medulla ;
• le Client ID et le Client Secret sont corrects ;
• l'URL de redirection correspond exactement à celle déclarée chez le fournisseur ;
• les scopes nécessaires sont autorisés ;
• les claims nécessaires sont présents dans le jeton ;
• le serveur Medulla peut joindre les endpoints OIDC en HTTPS ;
• aucune erreur n'est présente dans les journaux Medulla ou dans ceux du fournisseur d'identité.
La connexion revient immédiatement sur la page d'authentification
Une boucle de redirection peut notamment provenir :
• d'une Redirect URI incorrecte ;
• d'une différence entre l'URL interne et l'URL publique de Medulla ;
• d'une mauvaise gestion des en-têtes par un proxy inverse ;
• d'un problème de cookie ou de session ;
• d'un Client Secret incorrect ;
• d'une erreur de validation du jeton.
Vérifiez que l'URL publique utilisée par l'utilisateur correspond à celle déclarée chez le fournisseur d'identité.
Le fournisseur refuse l'URL de redirection
Vérifiez que la Redirect URI :
• est déclarée dans la configuration du client OIDC ;
• utilise le bon protocole HTTP ou HTTPS ;
• utilise le bon nom DNS ;
• utilise le bon chemin ;
• ne contient pas de barre oblique ou de caractère supplémentaire non attendu.
Information :
Certains fournisseurs effectuent une comparaison stricte de l'URL de redirection. Une différence minime peut entraîner le rejet de la demande.
Le jeton est refusé par Medulla
Vérifiez :
• la synchronisation NTP du serveur ;
• l'émetteur du jeton ;
• l'audience du jeton ;
• la date d'expiration du jeton ;
• l'adresse des clés publiques du fournisseur ;
• les certificats TLS ;
• la correspondance entre le Client ID et l'audience attendue.
L'utilisateur est créé avec des informations incorrectes
Vérifiez les claims utilisés pour :
• l'identifiant de l'utilisateur ;
• son adresse e-mail ;
• son prénom ;
• son nom de famille ;
• son nom complet.
Une mauvaise correspondance entre les claims retournés et les attributs attendus par Medulla peut entraîner la création d'un utilisateur incomplet ou difficile à identifier.
Un second compte est créé pour le même utilisateur
Ce comportement peut se produire si le claim utilisé comme identifiant a changé ou si plusieurs fournisseurs retournent des identifiants différents pour la même personne.
Vérifiez que le claim choisi comme identifiant :
• est unique ;
• reste stable dans le temps ;
• est retourné de manière identique à chaque connexion.
Bonnes pratiques de sécurité
Pour garantir un fonctionnement fiable et sécurisé de l'authentification OIDC, il est recommandé :
• d'utiliser exclusivement HTTPS ;
• de protéger le Client Secret dans un gestionnaire de secrets adapté ;
• de renouveler périodiquement le Client Secret ;
• de limiter les Redirect URI aux seules adresses nécessaires ;
• de limiter les scopes aux seules informations requises par Medulla ;
• d'activer l'authentification multifacteur chez le fournisseur d'identité ;
• de synchroniser le serveur Medulla avec une source NTP fiable ;
• de conserver un compte administrateur natif Medulla pour les opérations de secours ;
• de demander aux nouveaux utilisateurs d'effectuer une première connexion avant de leur attribuer leurs droits ;
• de limiter le nombre de comptes Super-Admin ;
• de réévaluer régulièrement les profils, les entités et les ACL attribués ;
• de désactiver l'accès chez le fournisseur d'identité lorsqu'un utilisateur quitte l'organisation.
Important :
La désactivation d'un compte chez le fournisseur OIDC empêche normalement sa prochaine authentification, mais ne supprime pas automatiquement son compte ni ses droits enregistrés dans Medulla. Il est recommandé de vérifier régulièrement les comptes et les habilitations conservés dans la plateforme.
Informations à transmettre au support
Si le problème persiste, transmettez au support Medulla :
• le nom du fournisseur d'identité utilisé ;
• l'URL de découverte OIDC ;
• le Client ID, si sa communication est autorisée par votre politique de sécurité ;
• l'URL publique de la plateforme Medulla ;
• l'URL de redirection déclarée chez le fournisseur ;
• les scopes configurés ;
• les noms des claims utilisés, sans transmettre de jeton contenant des données personnelles ;
• le message d'erreur exact ;
• la date et l'heure de la tentative ;
• les journaux correspondants ;
• la version de Medulla utilisée.
Attention :
Ne transmettez jamais le Client Secret, un mot de passe, un jeton d'accès, un ID Token complet, une clé privée ou une information permettant d'usurper l'identité d'un utilisateur.
Résumé
|
Élément |
Description |
|
Protocole |
OpenID Connect |
|
Authentification |
Déléguée au fournisseur d'identité |
|
Autorisation |
Gérée dans Medulla |
|
Création automatique du compte |
Oui, lors de la première connexion |
|
Attribution automatique des droits |
Non |
|
Action après la première connexion |
Attribuer un profil, une entité et le mode récursif si nécessaire |
|
Message « You do not have required rights » |
Authentification réussie, mais aucun droit attribué |
|
Scopes recommandés |
openid, profile et email |
|
Communications |
HTTPS |
|
Synchronisation horaire |
NTP recommandé |
|
Reconnexion après attribution des droits |
Oui |
|
Compte de secours |
Compte administrateur natif Medulla recommandé |
Bonne pratique :
Lorsqu'un nouvel utilisateur doit accéder à Medulla via OIDC, demandez-lui systématiquement d'effectuer une première connexion avant de lui attribuer ses droits. Cette première authentification permet à Medulla de créer automatiquement son compte. Une fois le profil et l'entité attribués, une nouvelle connexion lui donnera accès aux fonctionnalités autorisées.