Configuration SSO OIDC
Table des matières
Ce document décrit la procédure de configuration du module Single Sign-On (SSO) basé sur le protocole OpenID Connect (OIDC) pour l’application GEEF / VIRTUALIA. (*Voir section « Acronymes »).
Il est destiné aux administrateurs systèmes et équipes DSI souhaitant intégrer GEEF / VIRTUALIA avec un fournisseur d’identité (IdP — Identity Provider (Fournisseur d’identité)) OIDC autre qu’Azure Active Directory.
Le SSO permet à vos utilisateurs de se connecter à GEEF / VIRTUALIA en utilisant leurs identifiants d’entreprise existants, sans créer de compte supplémentaire. L’authentification est déléguée à votre serveur d’identité compatible OIDC : Keycloak, LemonLDAP::NG, FranceConnect, Gluu, Shibboleth, ou tout autre fournisseur conforme au standard OpenID Connect Core 1.0.
Compatibilité
Le module SSO-OIDC de GEEF / VIRTUALIA est compatible avec tout fournisseur d’identité implémentant le standard OpenID Connect Core 1.0 et exposant un endpoint de découverte .well-known. Les solutions suivantes ont notamment été testées ou sont connues comme compatibles :
| Fournisseur d’identité (IdP) | Exemple de DISCOVERY URI | Notes |
|---|---|---|
| Keycloak | https://idp.example.fr/realms/{realm}/.well-known/openid-configuration | Très répandu, open source |
| LemonLDAP::NG | https://auth.example.fr/oauth2/.well-known/openid-configuration | Utilisé par les collectivités FR |
| Gluu / Janssen | https://idp.example.fr/.well-known/openid-configuration | Open source, certifié FIDO |
| Shibboleth + OIDC | https://idp.example.fr/idp/profile/oidc/.well-known | Via plugin OIDC Shibboleth |
| FranceConnect | https://app.franceconnect.gouv.fr/api/v1/.well-known/openid-configuration | Identité numérique état FR |
| Autres IdP OIDC | URL fournie par votre prestataire / DSI | Tout serveur conforme OIDC Core 1.0 |
ℹ️ Prérequis côté IdP → Le flux Authorization Code Flow doit être supporté et activé. → Un « client » (ou application) doit être déclaré dans l’IdP pour GEEF / VIRTUALIA. → L’URI de retour (redirect URI) https://monapplication.cegape.fr doit être déclarée dans l’IdP. → Le endpoint .well-known doit être accessible depuis le serveur GEEF / VIRTUALIA.
Principes de fonctionnement
Schéma général du flux SSO
Lorsqu’un utilisateur tente d’accéder à GEEF / VIRTUALIA, le flux d’authentification SSO se déroule comme suit :
Flux détaillé (OpenID Connect)
Le protocole OpenID Connect (OIDC), basé sur OAuth 2.0, est utilisé pour l’échange sécurisé des informations d’identité. Voici les étapes du processus :
Rôle du .well-known
Le endpoint .well-known/openid-configuration est un document JSON publié par le serveur OIDC. Il contient automatiquement :
- L’adresse du endpoint d’autorisation
- L’adresse du endpoint de token
- L’adresse du endpoint de déconnexion (remplace SIGNOUT ENDPOINT)
- Les algorithmes de signature supportés
- L’adresse JWKS pour la validation des tokens
ℹ️ Information importante Grâce au .well-known, les paramètres PROVIDER URL et SIGNOUT ENDPOINT sont automatiquement déterminés et n’ont pas besoin d’être configurés manuellement. Seul le DISCOVERY URI (l’adresse du .well-known lui-même) est obligatoire.
Référence des paramètres
Le tableau ci-dessous récapitule l’ensemble des paramètres du module SSO-OIDC, leur valeur à configurer, leur caractère obligatoire et les remarques associées.
| Paramètre | Valeur / Description | Obligatoire | Remarque |
|---|---|---|---|
| CLIENT_ID | Fourni par le serveur OIDC lors de la création du service | ✔ Oui | Identifiant unique de l’application |
| DISCOVERY URI | URL complète du endpoint .well-known (ex: https://idp.example.fr/realms/monrealm/.well-known/openid-configuration) | ✔ Oui | Permet la découverte automatique des endpoints OIDC |
| GEEF URI | https://monapplication.cegape.fr | ✔ Oui | Doit correspondre exactement à l’URI déclarée auprès du serveur SSO |
| PROVIDER URL | Adresse de base du serveur OIDC | ✔ Oui | Souvent remplacé automatiquement par les infos du .well-known |
| SECRET | Fourni par le serveur OIDC (à chiffrer) | ✔ Oui | Secret partagé entre GEEF / VIRTUALIA et le serveur OIDC — à protéger |
| TENANT_ID | Mettre un point : . | ✔ Oui | Valeur par défaut à ne pas modifier sauf cas particulier |
| REMOVE DOMAIN | OUI (par défaut) | ✔ Oui | Mettre à NON si les utilisateurs sont identifiés dans GEEF / VIRTUALIA avec leur @xxxx.fr |
| MFA_CONTEXT_ID | Valeur par défaut | Non | Modifier uniquement sur cas particulier |
| MFA_ONLY | NON | Non | Modifier uniquement sur cas particulier |
| POST LOGOUT PARAM | Valeur par défaut | Non | Modifier uniquement sur cas particulier |
| SCOPES | Valeur par défaut | Non | Modifier uniquement sur cas particulier |
| SESSION_PARAM | Valeur par défaut | Non | Modifier uniquement sur cas particulier |
| SIGNOUT ENDPOINT | Extension sur le serveur OIDC | Non | Souvent remplacé automatiquement par les infos du .well-known |
| SSO_ONLY | NON | Non | Modifier uniquement sur cas particulier |
| STATE_TTL | Valeur par défaut | Non | Modifier uniquement sur cas particulier |
Paramètres obligatoires — Détail
CLIENT_ID
Identifiant unique de l’application GEEF / VIRTUALIA auprès du serveur d’identité. Il est généré par votre fournisseur d’identité (IdP) lors de l’enregistrement du client OIDC.
ℹ️ Comment l’obtenir ? → Keycloak : Clients > [Votre client] > Paramètres > Client ID → LemonLDAP::NG : Manager > Applications OpenID > [Votre application] > Identifiant client → Autre IdP : se référer à la documentation de votre fournisseur d’identité
SECRET
Secret partagé (client secret) permettant à GEEF / VIRTUALIA de s’authentifier auprès du serveur OIDC. Cette valeur est sensible et doit être traitée comme un mot de passe.
⚠ Sécurité → Le SECRET doit être chiffré autant que possible dans la configuration (voir Chiffrement). → Ne jamais transmettre cette valeur en clair par email ou messagerie non sécurisée. → Keycloak : Clients > [Votre client] > Credentials > Secret → LemonLDAP::NG : Manager > Applications OpenID > [Votre application] > Secret client
DISCOVERY URI
Adresse complète du endpoint .well-known de votre fournisseur d’identité. Ce paramètre est le plus important car il permet à GEEF / VIRTUALIA de découvrir automatiquement toute la configuration OIDC.
Exemples par fournisseur Keycloak : https://idp.example.fr/realms/{realm}/.well-known/openid-configuration
LemonLDAP::NG : https://auth.example.fr/oauth2/.well-known/openid-configuration
FranceConnect : https://app.franceconnect.gouv.fr/api/v1/.well-known/openid-configuration
Autre IdP : se référer à la documentation de votre fournisseur d’identité. L’URL doit retourner un document JSON valide quand ouverte dans un navigateur.
GEEF URI
L’URI de retour (redirect URI) vers laquelle le serveur OIDC renvoie le token après une authentification réussie. Cette valeur doit être déclarée exactement telle quelle dans la configuration de votre client OIDC.
Valeur à configurer (exemple) GEEF URI = https://geef.cegape.fr ou https://virtualia.cegape.fr
Déclarez cette URI dans votre IdP : Keycloak : Clients > [Votre client] > Valid Redirect URIs LemonLDAP::NG : Manager > Applications OpenID > [Votre application] > URL de redirection
⚠ Point d’attention Si l’URI déclarée dans l’IdP et celle configurée dans GEEF / VIRTUALIA ne correspondent pas exactement (majuscules, slash final, protocole http vs https), l’authentification échouera avec une erreur de type « redirect_uri_mismatch ».
PROVIDER URL
Adresse de base du serveur OIDC. Dans la plupart des cas, ce paramètre est automatiquement déduit du DISCOVERY URI et n’a pas besoin d’être renseigné manuellement. Il est néanmoins recommandé de le configurer par sécurité.
Exemples Keycloak : https://idp.example.fr/realms/{realm} LemonLDAP::NG : https://auth.example.fr FranceConnect : https://app.franceconnect.gouv.fr
REMOVE DOMAIN
Ce paramètre contrôle la manière dont le nom d’utilisateur est extrait du token OIDC pour rechercher le compte dans GEEF / VIRTUALIA.
| Valeur | Comportement | Cas d’usage |
|---|---|---|
| OUI | Le domaine est supprimé : « jean.dupont@cegape.fr » devient « jean.dupont » | Lorsque les utilisateurs sont identifiés dans GEEF / VIRTUALIA par leur login court (sans @domaine) |
| NON | L’identifiant complet est conservé : « jean.dupont@cegape.fr » | Lorsque les utilisateurs sont identifiés dans GEEF / VIRTUALIA avec leur adresse email complète |
TENANT_ID
Dans la configuration GEEF / VIRTUALIA, ce paramètre doit être défini à un point (.) qui est la valeur par défaut. Cela indique que l’identification du tenant est gérée via le DISCOVERY URI et non directement via ce champ. Ce paramètre est historiquement lié à Azure AD mais reste présent dans le module OIDC générique.
Valeur à saisir TENANT_ID = . (Un point, sans guillemets)
Checklist de déploiement
Utilisez cette liste pour vérifier que toutes les étapes ont été réalisées avant la mise en service du SSO.
| ✓ | Action |
|---|---|
| ☐ | Déclarer un client OIDC dans votre fournisseur d’identité (IdP) et noter le CLIENT_ID |
| ☐ | Générer un client secret dans l’IdP et noter le SECRET |
| ☐ | Déclarer l’URI de redirection https://geef.cegape.fr ou https://virtualia.cegape.fr dans le client OIDC de l’IdP |
| ☐ | Récupérer le DISCOVERY URI (.well-known) de votre IdP et le tester dans un navigateur |
| ☐ | Configurer CLIENT_ID dans les paramètres GEEF / VIRTUALIA |
| ☐ | Configurer SECRET dans les paramètres GEEF / VIRTUALIA (chiffré si possible — voir section 7) |
| ☐ | Configurer DISCOVERY URI dans les paramètres GEEF / VIRTUALIA |
| ☐ | Configurer GEEF URI = https://geef.cegape.fr ou https://virtualia.cegape.fr |
| ☐ | Configurer PROVIDER URL avec l’adresse de base du serveur OIDC |
| ☐ | Configurer TENANT_ID = . (Point) |
| ☐ | Configurer REMOVE DOMAIN selon le format d’identifiant utilisé dans GEEF / VIRTUALIA |
| ☐ | Tester la connexion SSO avec un compte de test |
| ☐ | Vérifier la déconnexion (logout) et le retour à la page d’accueil |
Chiffrement
En bas de l’écran, la zone « LDAP+ - SECURITY_CREDENTIALS » avec le bouton 
permet de chiffrer une chaîne de caractères :
Cliquer sur le bouton .
Une fois la chaîne chiffrée obtenue dans cette case (bouton ), elle peut être mise dans les champs concernés.
Ce chiffrement est réversible par l’applicatif. La valeur chiffrée commence toujours par « $1$ ». Pour des raisons de sécurité (protection de la méthode de chiffrement), la chaîne chiffrée sur la capture ne correspond pas à la chaîne en clair de la capture précédente sur cette documentation, autrement dit le chiffrement par cette méthode de la chaîne « 1234 » ne donne pas la chaîne « $1$nP1/zLsGro1… ». Cette opération permet de ne pas afficher « en clair » les paramètres sensibles.
Nous recommandons de chiffrer les paramètres « CLIENT_ID » et « SECRET » via cette méthode.
Résolution des problèmes courants
| Symptôme | Cause probable | Solution |
|---|---|---|
| redirect_uri_mismatch | L’URI déclarée dans l’IdP ne correspond pas à GEEF / VIRTUALIA URI | Vérifier que https://GEEF / Virtualia.cegape.fr est bien déclaré dans le client OIDC de l’IdP |
| invalid_client | CLIENT_ID ou SECRET incorrect | Régénérer le secret dans l’IdP et reconfigurer GEEF / VIRTUALIA |
| Utilisateur non trouvé dans GEEF / VIRTUALIA | REMOVE DOMAIN mal configuré | Vérifier le format des identifiants dans GEEF / VIRTUALIA et ajuster REMOVE DOMAIN |
| Erreur de découverte OIDC | DISCOVERY URI incorrect ou inaccessible depuis le serveur GEEF / VIRTUALIA | Tester l’URL dans un navigateur depuis le serveur GEEF / VIRTUALIA, elle doit retourner du JSON |
| Boucle de redirection infinie | SESSION_PARAM ou STATE_TTL incohérent | Réinitialiser ces paramètres à leur valeur par défaut |
| Token invalide / signature échouée | Algorithme de signature non supporté ou JWKS inaccessible | Vérifier la configuration de l’algorithme (RS256 recommandé) et l’accessibilité du JWKS URI |
Fichier de context.xml
Les paramètres peuvent être mis dans leur version « chiffrée » (voir Chiffrement) ou « non chiffrée » (tels que fournis par l’IdP) dans le fichier de contexte XML présent dans « [Chemin Tomcat]\conf\Catalina\localhost » : 
La valeur chiffrée sur cette capture est fictive et intentionnellement incomplète, elle doit être complète dans le paramétrage réel.
Il n’est pas nécessaire de mettre les paramètres à la fois « en clair » et « chiffré », nous recommandons de ne mettre que la version chiffrée.
Code :
Les chaînes « [Nom du paramètre] » et « [Valeur du paramètre] » sont à remplacer par les chaînes attendues.
Les chaînes « [Nom du paramètre] » et « [Valeur du paramètre] » sont à remplacer par les chaînes attendues.
Attention : la sauvegarde du fichier de contexte XML entraîne le redémarrage du contexte et la potentielle déconnexion des utilisateurs.
Lorsqu’un paramètre est mis dans le fichier de contexte, il n’est plus modifiable à l’écran. Pour autant, son ancienne valeur est conservée en base de données. Il est donc recommandé de vider le paramètre à l’écran avant de le transférer dans le fichier de contexte.
Exemple de paramètre géré dans le fichier XML :
Nous recommandons de protéger par ce biais les paramètres « CLIENT_ID » et « SECRET ».
Contact et support
Pour toute question relative à la configuration du SSO-OIDC sur GEEF / VIRTUALIA Merci de créer un ticket Mantis en précisant dans votre demande :
- Le message d’erreur exact affiché
- Les paramètres configurés (hors SECRET)
- La version de GEEF / VIRTUALIA utilisée
- Le fournisseur d’identité utilisé (Keycloak, LemonLDAP, etc.)
Acronymes
SSO
L’authentification unique, souvent désignée par le sigle anglais SSO (de single sign-on) est une méthode permettant à un utilisateur d’accéder à plusieurs applications informatiques (ou sites web sécurisés) en ne procédant qu’à une seule authentification.
Source : https://fr.wikipedia.org/wiki/Authentification_unique
OIDC
OpenID Connect (OIDC) est une simple couche d’identification basée sur OAuth 2.0, un dispositif d’autorisation. Ce standard est géré par la fondation OpenID. OpenID Connect est une simple couche d’identification basée sur le protocole OAuth 2.0, qui autorise les clients à vérifier l’identité d’un utilisateur final en se basant sur l’authentification fournie par un serveur d’autorisation, en suivant le processus d’obtention d’une simple information du profil de l’utilisateur final. Ce processus est basé sur un dispositif interopérable de type REST. En termes techniques, OpenID Connect spécifie une interface HTTP RESTful, en utilisant JSON comme format de données. OpenID Connect permet à un éventail de clients, y compris web, mobiles et JavaScript, de demander et recevoir des informations sur la session authentifiée et l’utilisateur final. Cet ensemble de spécifications est extensible, supporte des fonctionnalités optionnelles tel le chiffrement des données d’identité, la découverte dynamique de fournisseurs OpenID et la gestion de sessions2. Plusieurs entreprises utilisent OpenID Connect tel Google, Microsoft, Ping Identity, Deutsche Telekom, salesforce.com3, Trustelem4… L’Etat français l’utilise aussi dans son dispositif d’authentification et d’identification universel FranceConnect.
Source : https://fr.wikipedia.org/wiki/OpenID_Connect
IdP — Identity Provider (Fournisseur d’identité)
Un fournisseur d’identité (IdP) est un système qui crée, maintient et gère les informations d’identité des utilisateurs, et fournit des services d’authentification aux applications tierces (appelées fournisseurs de services, ou SP). Dans le contexte OIDC, l’IdP est le serveur qui émet les tokens JWT après authentification de l’utilisateur.
Exemples d’IdP compatibles OIDC : Keycloak, LemonLDAP::NG, Gluu, Shibboleth, FranceConnect, Okta, Auth0, etc.
MFA
La double authentification, authentification à deux facteurs (A2F)1, authentification à double facteur ou vérification en deux étapes ou à deux étapes2 (two-factor authentication en anglais, ou 2FA) est une méthode d’authentification forte par laquelle un utilisateur peut accéder à une ressource informatique (un ordinateur, un téléphone intelligent ou encore un site web) après avoir présenté deux preuves d’identité distinctes à un mécanisme d’authentification. Un exemple de ce processus est l’accès à un compte bancaire grâce à un guichet automatique bancaire : seule la combinaison de la carte bancaire (que l’usager détient) et du numéro d’identification personnel (que l’usager connaît) permet de consulter le solde du compte et de retirer de l’argent. La multiple authentification, plus communément appelée authentification à facteurs multiples, authentification multi-facteurs ou authentification à étapes2 (multi-factor authentication en anglais, MFA) exige, quant à elle, plus de deux preuves d’identité.
Source : https://fr.wikipedia.org/wiki/Double_authentification