OIDC avec Entra

OpenID Connect OIDC est un protocole d’identité basé sur OAuth 2.0 qui permet une authentification et une autorisation sécurisées pour les applications web et mobiles. Il permet aux utilisateurs de se connecter en toute sécurité à divers services, tandis que les fournisseurs de services peuvent simultanément accéder à des informations d’identité vérifiées. Cet article explique, étape par étape, comment configurer OIDC dans Relution à l’aide de Microsoft Azure.

Paramètres dans Relution #

OpenID Connect OIDC peut être configuré dans le portail Relution sous Paramètres → Gestion des utilisateurs → OpenID Connect. Les captures d’écran suivantes montrent une configuration fonctionnelle avec Microsoft Azure.

Détails de la configuration #

Nom du prestataire : Champ obligatoire. Sera affiché sur le bouton de connexion dans le portail Relution et ne peut plus être modifié après l’enregistrement. Créer des utilisateurs inconnus dans Relution : Active la création automatique de nouveaux utilisateurs inconnus lors de leur première connexion à Relution. Le commutateur est désactivé par défaut. Dans ce cas, seuls les utilisateurs déjà présents dans Relution peuvent se connecter. Vérifier la configuration : Vérifie avant l’enregistrement si la configuration est valide.

Si une connexion est effectuée avec un utilisateur inconnu sur l’organisation du magasin avec la configuration OIDC activée, celui-ci est automatiquement créé dans l’organisation du magasin. En cas de plusieurs mandants avec configuration OIDC, la connexion doit se faire via l’URL de l’organisation afin que l’utilisateur inconnu soit créé dans l’organisation correspondante. Cette URL est affichée dans le portail au niveau des connexions OIDC.

Détails du client #

Identifiant du client : Correspond dans Azure à l’ID de l’application. Secret du client : Correspond dans Azure à la clé secrète client de l’ID de l’application. Lors de la modification d’une configuration enregistrée, le champ reste vide. Si aucune nouvelle valeur n’est saisie, le secret existant reste inchangé.

URI du serveur #

Utiliser le point de terminaison de découverte : Si le fournisseur le prend en charge, une configuration automatique des URI nécessaires est effectuée Configurer manuellement les points d’extrémité : Nécessaire dès que la découverte automatique ne fonctionne pas.

Avec Microsoft Azure, les points de terminaison doivent être saisis manuellement.

• URI d’autorisation
  https://login.microsoftonline.com/$-votre-ID-de-mandant/oauth2/v2.0/authorize

• JWK Set URI
  https://login.microsoftonline.com/common/discovery/keys

• Token URI
  https://login.microsoftonline.com/$-votre-ID-de-mandant/oauth2/v2.0/token

• Point de terminaison de fin de session (champ Point de terminaison de la session, facultatif, pour la déconnexion auprès de l’IdP, voir Vérification de la déconnexion)
  https://login.microsoftonline.com/$-votre-ID-de-mandant/oauth2/v2.0/logout

Configuration étendue #

Attribut du nom d’utilisateur du fournisseur OIDC : Attribut du fournisseur OIDC qui contient le nom d’utilisateur unique de l’utilisateur authentifié (par défaut : email).

Attribut du nom d’utilisateur de Relution : Définit la propriété utilisateur Relution (Nom d’utilisateur, Adresse e-mail, UUID ou Clé étrangère (UID) ; par défaut : Adresse e-mail) avec laquelle la valeur de l’attribut du fournisseur OIDC est comparée. Avec UUID, les utilisateurs inconnus ne sont pas créés, même si Créer des utilisateurs inconnus dans Relution est activé.

Authorization Grant Type : Définit par quel mécanisme OAuth l’application obtient l’accès (par défaut : authorization_code).

Portée : Détermine en tant que scope OAuth quelles informations ou ressources peuvent être demandées par Relution via OIDC (par défaut : openid, email, profile).

Options avancées #

Déconnexion de l’utilisateur de l’OIDC lors de la déconnexion de Relution : Lors de la déconnexion de Relution, le navigateur est également redirigé vers le point de terminaison de déconnexion de l’IdP (par défaut : désactivé). Les détails figurent sous Vérification de la déconnexion.

Créer une nouvelle inscription d’application #

1. Connexion au portail Azure, puis accès à Microsoft Entra ID

   

2. Créer une nouvelle Inscription d'application → Nouvelle inscription pour OIDC

   

3. Nommer l’application, sélectionner le type de compte Comptes dans cet annuaire d’organisation uniquement et l’enregistrer

   

La seule connexion via OIDC ne nécessite aucune autorisation API supplémentaire ni consentement d’administrateur. Les autorisations d’application pour Microsoft Graph (p. ex. User.Read.All) ne sont nécessaires que pour la liaison avec Microsoft Entra ID → et y sont configurées.

Ajouter une clé secrète client (Client Secret) sous Certificats et secrets #

1. La clé secrète client requise est créée sous Ajouter un certificat ou un secret

   

2. Via Nouvelle clé secrète client, la Description et la durée de validité Valide jusqu’au peuvent être définies

   

3. La clé client peut être copiée directement

   

Ajouter l’URI de redirection #

L’URI de redirection sera affiché dans le portail Relution une fois la connexion configurée et enregistrée.

Où les trouver : les URI de redirection de l’instance concernée sont affichées dans le portail Relution sous Paramètres → Gestion des utilisateurs → OpenID Connect, dans la section URLs OIDC scopées de la configuration, dès que la connexion a été enregistrée, et peuvent y être copiées. Le portail n’affiche toutefois que les entrées URL de redirection (management), URL de redirection (device) et, avec une licence Education, URL de redirection (teacher). Il n’affiche actuellement pas les URI pour l’enrôlement des appareils (/api/enrollment/), le Relution Agent (/api/agent/), Relution Assets (/api/assets/), le portail libre-service (/api/selfService/) et Relution en tant que fournisseur d’identité → (/api/idp/). Elles sont ajoutées manuellement selon le schéma ci-dessous, dans la mesure où la fonction concernée est utilisée avec OIDC.

Chemins précédents (configurations créées avant 26.4, une seule URI de redirection) :

https://<host>/login/oauth2/code/<registrationId>

Chemins scopés (configurations créées à partir de 26.4 ou converties, enregistrer toutes celles qui s’appliquent) :

https://<host>/api/management/login/oauth2/code/<registrationId>       # portail Relution
https://<host>/api/enrollment/login/oauth2/code/<registrationId>       # enrôlement des appareils (ADE, User Enrollment, Android Enterprise), à partir de 26.5
https://<host>/api/teacher/login/oauth2/code/<registrationId>          # licence Education uniquement
https://<host>/api/agent/login/oauth2/code/<registrationId>            # Relution Agent, à partir de 26.5
https://<host>/api/assets/login/oauth2/code/<registrationId>           # Relution Assets, à partir de 26.5
https://<host>/api/selfService/login/oauth2/code/<registrationId>      # portail libre-service, à partir de 26.5
https://<host>/api/idp/login/oauth2/code/<registrationId>              # Relution en tant que fournisseur d'identité (bêta), à partir de 26.5
https://<host>/api/device/login/oauth2/code/<registrationId>           # 26.4.x uniquement, plus utilisée par aucune connexion à partir de 26.5

<registrationId> est l’UUID de configuration OIDC affiché dans Relution.

URL de déconnexion : le portail affiche en outre deux URL de déconnexion dans la même section. Il ne s’agit pas d’URI de redirection :

• URL de déconnexion du canal frontal (front-channel) : https://<host>/api/management/v1/logout/connect/front-channel/<registrationId>
• URL de déconnexion du canal arrière (back-channel) : https://<host>/api/management/logout/connect/back-channel/<registrationId>

Convertir les configurations existantes #

Les configurations créées avant 26.4 continuent d’utiliser l’URI de redirection précédente après la mise à jour. Une telle configuration affiche en outre la section URLs OIDC héritées avec l’URL de redirection actuellement active et l’URL de déconnexion back-channel précédente. La conversion s’effectue en deux étapes :

1. Toutes les URI scopées applicables sont ajoutées à l’inscription d’application Entra existante. L’URI précédente reste enregistrée pour le moment.
2. Dans Relution, la configuration est ouverte sous Paramètres → Gestion des utilisateurs → OpenID Connect, puis Activer les chemins OIDC scopés est cliqué dans la section URLs OIDC héritées et la boîte de dialogue suivante est confirmée.

Les configurations nouvellement créées n’affichent pas cette section, car elles utilisent les URI scopées dès le départ. L’URI précédente est obsolète et pourrait être supprimée dans une future version.

URI de redirection pour l’enrôlement des appareils #

À partir de Relution 26.5.0, toutes les connexions effectuées pendant un enrôlement passent par une portée dédiée enrollment. Cela concerne l’Inscription automatisée des appareils (ADE, DEP dans le portail) d’Apple, Apple Account-Driven User Enrollment, l’enrôlement Android Enterprise ainsi que la connexion dans le DPC Android Enterprise. Pour les configurations avec chemins scopés, ces connexions ne fonctionnent que si l’URI /api/enrollment/ indiquée ci-dessus est enregistrée auprès du fournisseur d’identité. Les configurations avec les chemins précédents continuent d’utiliser l’URI précédente, y compris pour les enrôlements.

Symptôme en cas d’URI manquante : la connexion au portail Relution continue de fonctionner, car elle utilise l’URI /api/management/. Seul l’enrôlement de l’appareil échoue, par exemple l’enrôlement ADE d’un Mac avec le message AADSTS50011: The redirect URI ... does not match. Si cette erreur apparaît lors d’un enrôlement avec une configuration utilisant les chemins scopés, l’URI /api/enrollment/ manque dans l’inscription d’application Entra.

Backchannel Logout #

Relution prend en charge le Backchannel Logout à partir de la version serveur 5.32.0

Scénario d’exemple : Un utilisateur est connecté simultanément à un service SSO central et à plusieurs applications. Lors de la déconnexion du service SSO, le Backchannel Logout garantit que les sessions dans toutes les autres applications sont également terminées, même si elles fonctionnent en arrière-plan.

Prérequis pour les utilisateurs Entra pour OIDC #

Vérification de la déconnexion #

Avant la mise en service, les voies de déconnexion sont vérifiées :

• Déconnexion auprès de l’IdP lors de la déconnexion de Relution : un clic sur Déconnexion dans Relution révoque la session. Le navigateur n’est redirigé en plus vers le point de terminaison de déconnexion de l’IdP que si le commutateur Déconnexion de l’utilisateur de l’OIDC lors de la déconnexion de Relution est activé sous Options avancées et qu’un point de terminaison de fin de session est connu. Comme les points de terminaison sont configurés manuellement pour Entra, le champ Point de terminaison de la session doit être renseigné à cet effet.
• Déconnexion front-channel : lorsque l’utilisateur se déconnecte auprès de l’IdP, l’IdP appelle l’URL de déconnexion du canal frontal affichée dans le portail et Relution révoque la session. Cette URL doit pour cela être enregistrée auprès de l’IdP.
• Déconnexion back-channel : l’IdP envoie une notification de déconnexion à l’URL de déconnexion du canal arrière — la session est révoquée sans intervention de l’utilisateur.

Le test de ces voies permet de s’assurer qu’une fin de session initiée par l’IdP (par ex. via la console d’administration de l’IdP) est correctement transmise à Relution.