Configuration SSO Azure AD365

Table des matières
  1. Onglet « Applications d’entreprise »
  2. Onglet « Inscription des applications »
  3. Ecran « Outils > Paramètres > Paramètres » dans GEEF/Virtualia V5
    1. Paramètres « AAD »
    2. Chiffrement
    3. Fichier de context.xml
  4. Acronymes
    1. SSO
    2. OIDC
    3. MSAL
    4. MFA

Ce protocole SSO s’appuie sur les librairies MSAL](#msal) proposée par Microsoft pour les applications Java et le protocole [OIDC, préconisé par Microsoft. (*Voir section « Acronymes ») Cette documentation masque de nombreux éléments pouvant permettre une identification technique des paramétrages propres à une organisation pour des raisons évidentes de sécurité.

Onglet « Applications d’entreprise »

Ces captures proviennent du site Entra de Microsoft : https://entra.microsoft.com/ L’application GEEF/Virtualia V5 doit être déclarée dans cet écran avec un certain nombre de paramètres repris sur ces captures. La plupart de ces paramètres dépendent des règles internes de l’organisation. Ce paramétrage doit être réalisé par un administrateur du domaine.

Le nombre de propriétaires dépend des usages de l’organisation. Un seul propriétaire (créateur) est nécessaire.

Consulter la documentation Microsoft Entra pour la signification du marqueur « Privilégié » : https://learn.microsoft.com/fr-fr/entra/identity/role-based-access-control/privileged-roles-permissions?tabs=admin-center

L’accès à « Microsoft Graph » en « User.Read » est primordial.

Onglet « Inscription des applications »

Ces captures proviennent du site Entra de Microsoft : https://entra.microsoft.com/

Sur cet écran :

Les différentes URI de redirection ci-dessus doivent être autorisées. Le préfixe est celui du serveur, par exemple « https://geef.sdisXX.fr » serait à décliner en :

  • https://geef.sdisXX.fr/
  • https://geef.sdisXX.fr/aadSignOut
  • https://geef.sdisXX.fr/callback
  • https://geef.sdisXX.fr/aadRedirect
  • https://geef.sdisXX.fr/aadSignIn

Lors de la création du « secret client », Entra affiche une unique fois le « secret » devant être mis dans le paramètre « SSO-AAD : SECRET » de l’Ecran « Outils > Paramètres > Paramètres » dans GEEF/Virtualia V5. En cas de perte, le « secret » peut être créé à nouveau sur Entra. Le Chiffrement de cette valeur est recommandé. Ce paramètre peut également être inclus dans le Fichier de context.xml sous sa forme « chiffrée » (commence par « $1$ ») ou « non chiffrée » (tel que présentés par Entra).

L’accès à l’adresse « email » est nécessaire pour obtenir l’identification de l’utilisateur. L’accès « openid » est nécessaire pour l’utilisation du protocole. L’accès à « profile » semble nécessaire pour la lecture du matricule RH de l’agent si présent dans l’annuaire. Ces éléments semblent être implicites par rapport au « User.Read ».

Consulter la documentation Microsoft Entra pour la signification du marqueur « Privilégié » : https://learn.microsoft.com/fr-fr/entra/identity/role-based-access-control/privileged-roles-permissions?tabs=admin-center

Ecran « Outils > Paramètres > Paramètres » dans GEEF/Virtualia V5

Paramètres « AAD »

  • CLIENT_ID : Identifiant du client (application) auprès de l’annuaire Azure Active Directory, trouvé dans la description de l’applicatif dans Entra. Chiffrement et Fichier de context.xml recommandés.
  • MFA_CONTEXT_ID : Identifiant du critère MFA (Multi-factor authentification, authentification à facteurs multiples). Celui-ci est, par défaut « c1 », il peut être personnalisé dans Entra. Il est obligatoire pour l’activation du paramètre « MFA_ONLY ». Valeur par défaut recommandée : « c1 ».
  • MFA_ONLY : Permet d’indiquer que tout utilisateur se connectant à l’application doit avoir passé le critère d’authentification à facteurs multiples lors de la connexion à Azure Active Directory. Ce paramètre peut également être géré côté Entra. Recommandé : « NON ».
  • REMOVE DOMAIN : Permet d’indiquer si l’application doit ôter le domaine (ex : « @sdisXX.fr » dans l’identifiant de l’utilisateur « xxx » qui aurait été transmis en « xxx@sdisXX.fr »). Ce paramètre doit être activé si les comptes utilisateurs dans l’application sont créés sans le domaine (ex : « prenom.nom »). Ce paramètre peut avoir un impact sur la création automatique des comptes utilisateurs et sur la récupération de leurs droits applicatifs. Recommandé : « OUI ».
  • SCOPES : Converser la valeur « openid » sauf cas particulier (paramétrage complémentaire à réaliser dans Entra, le cas échéant). Valeur par défaut recommandée : « openid ».
  • SECRET : Mot de passe fourni par Entra pour l’application lors de la création du « secret ». Cette clé ne devrait être partagée avec aucun autre service applicatif. Chiffrement et Fichier de context.xml fortement recommandés.
  • SESSION_PARAM : Permet de modifier le paramètre d’authentification échangé entre l’application et Azure Active Directory. La valeur par défaut « msalAuth » peut être modifiée sans impact dans Entra. La modification de ce paramètre peut invalider les jetons de connexion actifs (déconnexion des utilisateurs). Valeur par défaut recommandée : « msalAuth ».
  • SSO_ONLY : Permet de désactiver la mire de connexion applicative pour obliger tous les utilisateurs à s’authentifier uniquement grâce au bouton « Connexion SSO » sur la mire d’accueil de l’application. Recommandé : « NON ».
  • STATE_TTL : Permet de définir le temps de vie en secondes des jetons de connexion. Ce paramètre n’admet qu’un entier positif. Valeur par défaut recommandée : 600 (secondes).
  • TENANT_ID : Identifiant du locataire (tenant) auprès de l’annuaire Azure Active Directory, trouvé dans la description de l’applicatif dans Entra ou plus globalement dans les URL de connexion aux services Microsoft. Chiffrement et Fichier de context.xml recommandés.

Toute valeur incorrecte d’un de ces paramètres peut entrainer le dysfonctionnement de l’authentification SSO via Azure Active Directory.

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 pas « $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 claire 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 », « TENANT_ID » et « SECRET » via cette méthode.

Fichier de context.xml

Les paramètres peuvent être mis dans leur version « chiffrée » (voir Chiffrement) ou « non chiffrée » (tels que présentés par Entra) 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.

Attention : la sauvegarde du fichier de contexte XML entraine 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 », « TENANT_ID » et « SECRET ».

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

MSAL

Microsoft Authentication Library, Bibliothèque d’authentification Microsoft. La Bibliothèque d’authentification Microsoft (MSAL) permet aux développeurs d’acquérir des jetons de sécurité auprès de la plateforme d’identités Microsoft afin d’authentifier les utilisateurs et d’accéder aux API web sécurisées. Il peut être utilisé pour fournir un accès sécurisé à Microsoft Graph, d’autres API Microsoft, des API web de tiers ou vos propres API web. MSAL prend en charge de nombreuses architectures et plateformes d’application différentes, notamment .NET, JavaScript, Java, Python, Android et iOS.

Source : https://learn.microsoft.com/fr-fr/entra/identity-platform/msal-overview

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