Configuration OIDC via Azure® AD

1. Objet

Ce document a pour objectif de lister les différentes étapes de configuration de OIDC via Microsoft Azure^® Active Directory (AD).

2. Création de l’Azure^® "App Registration"

Les actions suivantes doivent être réalisées sur le portail Microsoft Azure^® :

Se connecter sur le portail Azure^® avec un compte possédant les droits d’accès au menu "Microsoft Entra ID".
Rechercher "entra id" (1) et cliquer sur le menu correspondant (2) :

Dans le menu de gauche "Manage" (1), ouvrir le menu "App Registrations" (2) puis cliquer sur "New registration" (3) :

Remplir la fenêtre suivante (cf. ci-dessous) pour indiquer :
- Le nom de l’application - exemple : SSO-OIDC-CARL_SAAS (1)
- L’URL de "redirect uri" correspondant à l’application CARL SaaS (2), de type "Web" (3) au format suivant : https://xxxxx.carl.berger-levrault.com/login/oauth2/code/azureprovider (en remplaçant "xxxxx" par le tenant concerné)
Cliquer sur "Register" (4).

Une fois l’application créée, une fenêtre s’ouvre sur sa configuration.
- Cliquer sur le menu "Authentication" (1).
- Cocher les cases "Access tokens (used for implicit flows)" et "ID tokens (used for implicit and hybrid flows)" (2).
- Puis cliquer sur "Save" (3).

Cliquer sur le menu "Token Configuration" (1) puis "Add optional claim" (2).
- Cocher "ID" (3) puis sélectionner chacun des Claims (4) que l’on souhaite exploiter dans les mappings d’identités côté CARL SaaS.
- Une fois la sélection terminée : cliquer sur "Add" (5).

La capture d’écran ci-dessous est un exemple : la sélection des Claims doit être adaptée en fonction des besoins réels.

Lors de la validation, la fenêtre suivante apparaît - cocher la case proposée (1) puis cliquer sur "Add" (2) :

On obtient alors une configuration similaire à celle présentée ci-dessous (ce menu peut être adapté et modifié par la suite) :

Passer au chapitre suivant : Génération du secret lié à l’application.

3. Génération du secret lié à l’application

A la suite des opérations détaillées ci-dessus, il est nécessaire de générer le secret lié à l’application.
Pour cela, deux solutions sont envisageables :

Solution n°1 : Générer un secret avec une date d’expiration longue (solution privilégiée).
Solution n°2 : Générer un secret avec une date d’expiration de 2 ans maximum (le SSO cessera de fonctionner une fois le secret expiré).
- Dans ce cas, il sera de la responsabilité de l’administrateur de fournir un nouveau secret valide avant la date d’expiration.

3.1. Solution n°1 : Générer un secret avec une date d’expiration longue

Pour générer un secret valide plus de 24 mois, il est obligatoirement nécessaire de passer par une commande AZ CLI.
Pour cela, la solution la plus simple consiste à utiliser l’interface de commandes disponible sur l’interface web qui permet de se connecter et d’utiliser les commandes AZ CLI.

Avant toute chose, il est nécessaire de récupérer la valeur de "Application (client) ID" à l’emplacement suivant :

Consigner cette valeur.
Ouvrir l’interface de commandes via le bouton (1) (voir illustration ci-dessous).
Entrer la commande suivante (2) en remplaçant l’ID 'XXXXX' par le "Application (client) ID" récupéré plus haut : az ad app credential reset --append --id XXXXX --display-name "CARL-GMAO" --end-date "2050-01-01"
Copier le secret affiché au niveau du (3) sur l’image d’illustration : il sera nécessaire par la suite.

Poursuivre au chapitre Finalisation de la configuration.

3.2. Solution n°2 : Générer un secret avec une date d’expiration de 2 ans maximum

Se rendre dans le menu "Certificates & secrets" (1).
Cliquer sur "New client secret" (2).
Choisir une description pour le secret (3) - exemple : CARLSaaS.
Choisir la durée de validité du token (4).
Puis cliquer sur "Add" (5).

Attention : à chaque expiration du token, un nouveau devra être généré et transmis à l’équipe en charge du SaaS.

On obtient alors un secret qu’il est nécessaire de consigner (seule la partie "Value" nous intéresse) :

Attention : ce secret n’est pas récupérable par la suite.

Poursuivre au chapitre Finalisation de la configuration.

4. Finalisation de la configuration

4.1. Affectation des droits d’utilisation

Revenir dans le menu "Overview" (1) puis cliquer sur le lien correspondant à la "Managed application" (2) :

Afin de limiter l’accès en SSO à CARL SaaS uniquement aux personnes approuvées, il est nécessaire d’activer l’option "Assignment required?" de la manière suivante (cf. illustration ci-dessous) :

Se rendre dans le menu "Properties" (1).
Pour l’option "Assignment required?" : cocher "Yes" (2).
Cliquer sur "Save" (3).

Ajouter ensuite les groupes ou utilisateurs autorisés à se connecter - pour cela :
- Cliquer sur le menu "Users and groups" (1).
- Puis "Add user/group" (2).

Une fois les utilisateurs ou groupes ajoutés, on obtient une liste similaire à celle-ci :

4.2. Transmission des informations à CARL Berger-Levrault

La configuration sur Azure^® est terminée.

Avant de quitter le portail, il est nécessaire de récupérer les informations qui seront utiles pour le reste de la configuration.

Vous pouvez utiliser l’outil Securely Send a Password | CARL - Berger Levrault pour transmettre les informations à CARL Berger-Levrault de façon sécurisée.
ClientSecret - à récupérer en fonction de la solution choisie dans l’un des chapitres suivants :
- Solution n°1 : Générer un secret avec une date d’expiration longue
- Solution n°2 : Générer un secret avec une date d’expiration de 2 ans maximum
ClientID : à récupérer depuis la fenêtre Overview → Application (Client) ID.
ClientName : à récupérer depuis la fenêtre Overview → Display name.
TenantID : à récupérer depuis la fenêtre Overview → Directory (tenant) ID.

Avis de marques déposées

Nous avons apporté tous nos efforts pour garantir l’exactitude des informations au moment de la publication de ce document.
CARL Source étant en constante évolution, CARL Berger-Levrault ne peut être tenu responsable des éventuels manques ou erreurs de ce document.
Si vous relevez une incohérence ou une erreur, merci de contacter le service support de CARL Berger-Levrault.

Toute reproduction, en tout ou en partie, sous quelque forme que ce soit, est formellement interdite sans l’autorisation préalable de CARL Berger-Levrault.

Toutes les marques et noms de produits mentionnés dans ce document sont les propriétés de leurs détenteurs respectifs telles que répertoriées ci-dessous :

Android™ et Google Chrome^® sont des marques déposées de Google LLC
ArcGIS^® est une marque déposée d’Environmental Systems Research Institute.
Elasticsearch^® est une marque déposée d’Elasticsearch B.V. aux États-Unis et dans d’autres pays.
Firefox^® est une marque déposée de Mozilla Foundation.
Java™ et Oracle^® sont des marques déposées d’Oracle Corporation.
PostgreSQL^® est une marque déposée de The PostgreSQL Community Association of Canada.
Safari^® est une marque d’Apple Inc., déposée aux États-Unis et dans d’autres pays.
Azure^®, SQL Server^®, Microsoft Edge^® et Windows^® sont des marques déposées de Microsoft Corporation.
Tomcat^® est une marque déposée de l’Apache Software Foundation aux États-Unis et dans d’autres pays.