Relution en tant que fournisseur d'identité

À partir de la version 26.5.0, Relution peut agir comme son propre fournisseur d’identité OpenID Connect / OAuth2 : les applications clientes sont enregistrées directement dans Relution, ce qui permet aux utilisateurs de se connecter avec leur compte Relution existant à toutes les applications connectées.

La configuration se trouve sous Paramètres → Fournisseur d'identité. La page n’est visible qu’avec l’autorisation de lecture des clients IdP ; l’enregistrement, la modification et la suppression de clients nécessitent les autorisations correspondantes.

Fonctionnalités #

• Flux de connexion OIDC standard via le flux Authorization Code avec PKCE ; les jetons de rafraîchissement (refresh tokens) sont pris en charge.
• Authentification multifactorielle : À partir de Relution 26.5.5, la connexion aux applications connectées passe également par l’authentification multifactorielle →. Les utilisateurs pour lesquels la MFA est configurée ou imposée confirment le second facteur, ou le configurent, pendant la connexion, puis sont redirigés vers l’application.
• Scopes configurables par client (profile, email, phone, relution), avec un écran de consentement affiché aux utilisateurs. Le scope relution fournit des données spécifiques à Relution (par exemple l’appartenance à une organisation). Le scope phone peut être activé, mais ne fournit actuellement aucun claim supplémentaire (par exemple aucun numéro de téléphone).
• Déconnexion unique (Single Sign-Out) : la déconnexion initiée par l’application connectée (RP-initiated logout) ainsi que le Back-Channel Logout OIDC 1.0 sont pris en charge. Une déconnexion initiée par l’application met également fin à la session Relution dans le navigateur.
• Révocation lors de modifications du compte : À partir de Relution 26.5.5, Relution révoque tous les codes d’autorisation, jetons d’accès et jetons de rafraîchissement d’un utilisateur dès que son mot de passe est modifié ou que son compte est verrouillé ou désactivé. Les applications connectées doivent alors reconnecter l’utilisateur ; les consentements accordés sont conservés. Lors de la suppression de l’utilisateur, ses consentements sont également supprimés. En outre, chaque émission de jeton, y compris le renouvellement par jeton de rafraîchissement, vérifie que l’utilisateur appartient toujours à l’organisation. Après la mise à jour vers Relution 26.5.5 ou une version ultérieure, une nouvelle connexion est nécessaire une seule fois dans les applications connectées.
• Clés de signature (JWK) : Les clés utilisées pour signer les jetons sont gérées automatiquement par Relution et renouvelées régulièrement (une clé active est remplacée par une nouvelle au bout de quatre mois) – aucune action n’est nécessaire.

Rotation et révocation des clés de signature #

Les clés de signature sont gérées dans la section Clés de signature de la page Paramètres → Fournisseur d'identité. Cette section n’est disponible que dans l’organisation globale ; elle n’est pas affichée dans les méta-organisations et les sous-organisations.

La rotation automatique couvre entièrement le fonctionnement normal. Pour les cas exceptionnels (par exemple en cas d’incident de sécurité), deux interventions manuelles sont disponibles :

• Rotation des clés : Une nouvelle clé active est créée et la clé précédente est retirée (statut En retrait). Les jetons déjà émis restent valides jusqu’à leur expiration. Une nouvelle rotation n’est possible qu’au plus tôt cinq minutes après la dernière.
• Révoquer : La clé sélectionnée est immédiatement supprimée du jeu de clés publié. Il convient de noter que les applications connectées (relying parties) peuvent conserver la clé précédente en cache pendant un certain temps, de sorte que les jetons signés avec celle-ci peuvent ne pas être reconnus comme invalides avant l’expiration de ce cache.

Points de terminaison pour l’intégration #

Dans la section Fournisseur en haut de la page Paramètres → Fournisseur d'identité, l’URL de l’émetteur (Issuer URL), le Document de découverte (.well-known/openid-configuration) et l’URI JWKS sont affichés et peuvent être copiés directement. Les autres points de terminaison techniques (par exemple le point de terminaison de jeton) peuvent être consultés au besoin dans le document de découverte.

Chaînage de fournisseurs d’identité (IdP chaining) #

Relution peut également être chaîné derrière un fournisseur d’identité en amont (par exemple Microsoft Entra ID → Relution → application connectée).

Enregistrement d’un client #

Un client dédié est créé pour chaque application connectée via Enregistrer un client :

• Nom du client : Choisi librement, affiché aux utilisateurs sur l’écran de consentement, et utilisé par les administrateurs pour distinguer plusieurs clients.
• Identifiant du client et Secret du client : Générés automatiquement et requis par l’application connectée (relying party). L’application s’authentifie avec ceux-ci via client_secret_basic ou client_secret_post. Le secret du client n’est affiché qu’une seule fois, directement après la création du client, et doit être copié à ce moment-là ; il ne peut plus être consulté ensuite. En cas de perte, un nouveau secret peut être généré dans la liste Clients enregistrés via Régénérer le secret (également affiché une seule fois). L’ancien secret devient alors invalide et tous les jetons existants du client sont révoqués.
• Activé : Un client désactivé refuse les nouvelles connexions ainsi que le renouvellement des jetons par jeton de rafraîchissement.
• Exiger PKCE : Activé par défaut. Si l’application connectée ne prend pas en charge PKCE, l’option peut être désactivée pour le client concerné.
• URI de redirection : Fournies par l’application connectée et doivent être renseignées en conséquence.
• URI de redirection après déconnexion : Adresses vers lesquelles l’application peut rediriger le navigateur après une déconnexion initiée par l’application (RP-initiated logout).
• URL de déconnexion back-channel : Si elle est renseignée, Relution notifie l’application en arrière-plan dès que la session du client se termine. Elle reste vide si l’application ne prend pas en charge la déconnexion back-channel.
• TTL du jeton d’accès et TTL du jeton de rafraîchissement : Durée de validité des jetons émis. Pour les nouveaux clients, le formulaire est prérempli avec 5 minutes et 1 jour respectivement ; les valeurs autorisées vont de 1 à 60 minutes pour les jetons d’accès et de 1 à 90 jours pour les jetons de rafraîchissement. En cas de modification du mot de passe, de verrouillage, de désactivation ou de suppression de l’utilisateur, les jetons sont révoqués de manière anticipée, indépendamment du TTL (voir Révocation lors de modifications du compte sous Fonctionnalités).
• Autorisations (scopes) : Chaque scope est réglé sur Désactivé, Facultatif ou Obligatoire. Par défaut, profile et email sont obligatoires, phone et relution désactivés. openid est toujours actif (Toujours accordé). L’activation d’un scope le rend seulement disponible ; l’application connectée doit également le demander lors du flux de connexion. Si la demande ne contient pas openid ou un scope obligatoire, la connexion est refusée avec l’erreur invalid_scope. Les scopes facultatifs ne sont accordés que si l’application les demande et qu’ils ne sont pas refusés sur l’écran de consentement.
• Donner le consentement administrateur pour tous les utilisateurs (Admin Consent) : Le consentement pour l’ensemble des scopes d’un client peut être approuvé au préalable par les administrateurs (en bloc, et non scope par scope) – les utilisateurs ne sont alors plus invités à les accepter sur l’écran de consentement lors de leur première connexion à l’application. Lorsque cette option est activée, les scopes ne peuvent plus être configurés que comme Désactivé ou Obligatoire. Les scopes réglés auparavant sur Facultatif sont automatiquement réinitialisés à leur valeur par défaut (profile et email : Obligatoire ; phone et relution : Désactivé).

Les clients qui ne sont plus nécessaires sont supprimés dans la liste Clients enregistrés.

Visibilité selon le niveau d’organisation #

Le niveau d’organisation auquel un client est enregistré détermine quels utilisateurs peuvent s’y connecter :

• Global : Tous les utilisateurs du système peuvent se connecter.
• Méta-organisation : Tous les utilisateurs de la méta-organisation ainsi que de ses sous-organisations peuvent se connecter.
• Sous-organisation : Seuls les utilisateurs de cette sous-organisation peuvent se connecter.

Aperçu du jeton #

Un aperçu des claims du jeton résultant peut être consulté pour la configuration de scopes actuelle d’un client – ce qui permet de vérifier au préalable quelles informations une application connectée recevrait dans le jeton.

Les scopes fournissent les claims suivants :

Consentements accordés #

Dans leur profil, les utilisateurs voient dans l’onglet Applications autorisées à quelles applications ils ont accordé quelles autorisations, et peuvent y révoquer l’accès. Les administrateurs disposant de l’autorisation correspondante trouvent la même section dans les détails d’un utilisateur. La révocation supprime également les autorisations existantes de l’application pour cet utilisateur, de sorte que l’application ne peut plus obtenir de nouveaux jetons via le jeton de rafraîchissement ; le consentement est de nouveau demandé lors de la prochaine connexion.

Journalisation #

Les connexions via le fournisseur d’identité sont enregistrées à la fois dans le journal d’audit (audit log) et dans l’historique de connexion de l’utilisateur concerné. Dans l’historique de connexion, la colonne Client IdP indique par quel client la connexion a été effectuée.