OIDC avec Workspace

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.

Ce guide explique la configuration d’OIDC dans Relution à l’aide de l’exemple de Google Workspace.

Configuration du projet et du client (Google Cloud Console) #

Tout d’abord, une application doit être enregistrée dans la Google Cloud Console afin d’obtenir les identifiants nécessaires.

1. Se connecter sur console.cloud.google.com →.

2. Créer un nouveau projet ou en sélectionner un existant.

   

   

3. Dans le menu, accéder à APIs & Services → OAuth consent screen et configurer cet écran si nécessaire.

   

4. Passer à Credentials, cliquer sur Create Credentials et sélectionner OAuth client ID.

   

5. Sélectionner Web application comme Application type.

   

6. Renseigner l’URL du serveur sous Authorized JavaScript origins (par ex. https://support.relution.io). Remarque : laisser pour l’instant le champ Authorized redirect URIs vide ou y renseigner provisoirement l’URL ; il sera mis à jour plus tard avec les URI de redirection provenant de Relution.

   

7. Après l’enregistrement, le Client ID est affiché. Le copier.

   

8. Modifier à nouveau le client nouvellement créé pour consulter les détails.

   

9. Copier le Client Secret. Conserver l’ID et le secret en sécurité pour une utilisation ultérieure dans Relution.

   

Configuration du SSO (Google Admin Console) #

Parallèlement, le profil Single Sign-On (SSO) doit être enregistré dans la console d’administration Google.

1. Accéder à la Google Admin Console →.

2. Créer un nouveau profil OIDC sous Security → Authentication → SSO with third-party IdP.

   

3. Saisir le Client ID et le Client Secret obtenus au chapitre précédent.

   • Utiliser l’URL du serveur Relution (par ex. https://support.relution.io) pour l’Issuer URL ainsi que pour la Change password URL.

     

Configuration d’OIDC dans Relution #

Les données rassemblées sont maintenant saisies dans Relution afin d’établir le lien avec Google.

1. Ouvrir dans Relution les paramètres OIDC sous Paramètres → Gestion des utilisateurs → OpenID Connect.

   

2. Sous Nom du prestataire, saisir un nom unique (p. ex. « Google Workspace »). Le nom apparaît sur le bouton de connexion et ne peut plus être modifié après l’enregistrement.

3. Si nécessaire, activer Créer des utilisateurs inconnus dans Relution afin que les nouveaux utilisateurs soient créés automatiquement lors de leur première connexion.

4. Saisir le Client ID et le Client Secret de la Google Cloud Console dans les champs Identifiant du client et Secret du client.

5. Dans la section URI du serveur, sélectionner l’option d’utilisation du point de terminaison de découverte (discovery endpoint), puis saisir https://accounts.google.com dans le champ URI de l’émetteur.

6. Enregistrer brièvement la configuration puis la rouvrir pour voir les champs générés.

7. Dans la section URLs OIDC scopées, copier toutes les entrées URL de redirection affichées (une pour management et une pour device, plus teacher avec une licence Education).

   

8. Retourner sur la Google Cloud Console →.

9. Modifier le client OAuth et ajouter sous Authorized redirect URIs toutes les URL qui viennent d’être copiées depuis Relution. Ajouter également les URI de redirection que le portail n’affiche pas, au minimum celle pour l’enrôlement des appareils (/api/enrollment/), voir URI de redirection scopées.

   

La section Configuration étendue définit comment Relution associe l’utilisateur connecté : l’Attribut du nom d’utilisateur du fournisseur OIDC (par défaut : email) est comparé à la propriété utilisateur sélectionnée sous Attribut du nom d’utilisateur de Relution (Nom d’utilisateur, Adresse e-mail, UUID ou Clé étrangère (UID) ; par défaut : Adresse e-mail). Avec UUID, aucun utilisateur inconnu n’est créé. La Portée est par défaut openid, email, profile. Vérifier la configuration permet de valider la configuration avant l’enregistrement.

URI de redirection scopées #

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 au client OAuth Google existant. 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, avec un message signalant une URI de redirection invalide (invalid_redirect_uri, chez Google Error 400: redirect_uri_mismatch). Si cette erreur apparaît lors d’un enrôlement avec une configuration utilisant les chemins scopés, l’URI /api/enrollment/ manque dans le client OAuth Google.

Backchannel Logout #

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

Scénario : Un utilisateur est connecté simultanément à plusieurs applications via SSO. Dès que la déconnexion du service SSO central a lieu, le Backchannel Logout garantit que les sessions dans Relution et les autres applications connectées en arrière-plan sont également terminées de manière sécurisée.

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 révoque la session dans Relution. Si le commutateur de déconnexion OIDC lors de la déconnexion de Relution est activé sous Options avancées (par défaut : désactivé) et qu’un point de terminaison de fin de session est connu (saisi manuellement dans le champ correspondant ou communiqué par l’IdP via la découverte), le navigateur est en outre redirigé vers le point de terminaison de déconnexion de l’IdP.
• 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.