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.

Fonctionnalités #

• Flux de connexion OIDC standard via le flux Authorization Code avec PKCE.
• 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).
• Déconnexion unique (Single Sign-Out) : la déconnexion initiée par le fournisseur de service (RP-initiated logout) ainsi que le Back-Channel Logout OIDC 1.0 sont pris en charge.
• 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 – aucune action n’est nécessaire.

Révocation des clés de signature #

La rotation automatique couvre entièrement le fonctionnement normal. Pour les cas exceptionnels (par exemple en cas d’incident de sécurité), une clé de signature peut également être révoquée manuellement. 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 #

En haut de la page de paramètres Identity Provider, l’URL de l’émetteur (Issuer URL) ainsi que le document de découverte (.well-known/openid-configuration) sont fournis et peuvent être copiés directement. Le document de découverte permet également de retrouver au besoin tous les autres points de terminaison techniques (par exemple l’URI JWKS), sans qu’il soit nécessaire de les reconstituer manuellement.

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 :

• Nom : Choisi librement, affiché aux utilisateurs sur l’écran de consentement, et utilisé par les administrateurs pour distinguer plusieurs clients.
• Client ID et Client Secret : Générés automatiquement et requis par l’application connectée (relying party).
• URI(s) de redirection : Fournies par l’application connectée et doivent être renseignées en conséquence.
• Scopes : Les scopes configurés comme obligatoires ou optionnels doivent être explicitement demandés par l’application connectée lors du flux de connexion.
• Consentement administrateur (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.

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.

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é.