Intégrer une application utilisant le protocole SAML 2.0 à Azure AD

Posted On 18 août 2018

Dans cet article nous allons voir quels sont les différentes applications et type d’applications présentes sous Azure AD et plus précisément l’ajout d’une application fonctionnant sur le protocole SAML 2.0.

Globalement, le portail Azure propose plusieurs type d’applications, pour plusieurs scénarios. Les applications sont ajoutées à Azure AD pour exploiter un ou plusieurs des services fournis, notamment:

• Authentification et autorisation d’application
• Authentification et autorisation de l’utilisateur
• SSO en utilisant la fédération ADFS ou le mot de passe présent dans l’annuaire AZURE AD
• Mise en service et synchronisation des utilisateurs
• Contrôle d’accès basé sur les rôles – Utilisez l’annuaire pour définir des rôles d’application afin d’effectuer des contrôles d’autorisation basés sur les rôles dans une application.
• Services d’autorisation OAuth – Utilisé par Office 365 et d’autres applications Microsoft pour autoriser l’accès aux API / ressources
• Publication d’application et proxy – Publie une application d’un réseau privé sur Internet

Dans notre scénario, nous allons exploiter une fonctionnalité PREMIUM d’Azure basée sur l’ajout d’une application SAML 2.0 qui fournira une expérience d’authentification unique aux utilisateurs. L’application qui sera utilisée en exemple sera Shibboleth SP sous II 8. Une autre application compatible SAML 2.0 pourrait aussi être utilisée, comme SimpleSAMLphp-sp par exemple.

Prérequis à cette maquette

Fournisseur d’identité (Idp) : Azure AD
Point de terminaison de l’Idp: https://login.microsoftonline.com/93535e3e-9602-4158-afe0-d87fdeeeec9d/federationmetadata/2007-06/federationmetadata.xml?appid=2b1cf0b0-f5e9-4c58-ab5d-1c6c7b7656ce
Fournisseur de services (Sp): https://monsite.test.local/Shibboleth.sso/Login
Url de redirection du SP: https://monsite.test.local/Shibboleth.sso/SAML2/POST
Compte utilisateur standard Azure AD: utilisateur1@remivernierhotmail.onmicrosoft.com

Toute application qui externalise l’authentification pour la confier à Azure AD doit être inscrite dans un annuaire. Cette étape consiste à donner des informations sur l’application à Azure AD (échange métadonnées), y compris son URL, l’URL à laquelle les réponses doivent être envoyées après l’authentification, l’URI permettant d’identifier votre application, etc… Une opération quasi équivalente doit être effectuée sur l’application elle même pour lui indiquer que fournisseur d’identités est Azure AD.

SAML ?

Petite présentation rapide (on reviendra plus en profondeur sur ce protocole dans un futur article):
Le langage SAML (Security Assertion Markup Language) est une norme XML permettant l’échange de données d’authentification et d’autorisation entre des domaines de sécurité. SAML est un standard supporté par un grand nombre de solutions.
Ce protocole répond entre autre à la problématique d’authentification unique. Il est utilisé dans notre cas pour fédérer des identités et fournir des mécanismes de SSO (SingleSign-On) aux applications qui permettent éventuellement de prolonger les solutions de SSO au-delà de l’intranet (Application Cloud).
Cela suppose que l’utilisateur soit représenté par un compte présent chez un fournisseur d’identités (Azure AD dans notre cas, mais il pourrait très bien être présent dans un AD local, et nous utiliserions alors des technologies ADFS/ AADsync).

Comme vous pouvez le constater sur le schéma ci dessous, le « pivot » est le poste client de l’utilisateur. C’est son navigateur, qui au travers d’HTTP redirect va le diriger dans un premier temps vers le Service Provider (notre site), puis vers l’Identity Provider (Azure AD) et à nouveau vers le Service Provider. C’est vers ce dernier qu’il présentera ce fameux « jeton » SAML fourni par notre Identity provider. Au delà de la fédération et donc l’échange d’information (métadonnées)  initié une fois (et rafraîchit périodiquement) entre le SP et l’IDP (représentée par RPT ci dessous), ces deux parties ne communiquent jamais entres elles directement lors d’une phase d’authentification.

Schéma représentant le flux (passif) et les différentes redirections du navigateur:

Configuration dans le portail AZURE

L’ensemble de la configuration dans Azure s’effectue via le portail portal.azure.com \ Azure Active Directory \ Entreprise applications.

Microsoft a prévu plusieurs cas d’usage:

• L’ajout de « nos propres » applications
• L’ajout d’application à partir de la galerie

Aujourd’hui la partie qui va nous intéresser est celle qui nous permet d’ajouter nos « propres » applications. Pas forcement celles que nous avons développé mais plutôt celles qui ne sont pas dans la galerie (Add your own app):

 

Un choix cornélien s’offre alors à nous:

• Application you’re developping: Permet d’inscrire une application native ou Web API via les protocoles OpenID-Connect/O-Auth ou une application qui souhaite accéder aux API Azure (Graph API par exemple).
• On-premises application: Permet d’inscrire un composant applicatif on-premise: Application Proxy Connector qui permet une authentification unique (SSO) et un accès distant sécurisé pour les applications Web hébergées localement.
• Non-gallery application: Permet d’ajouter des applications dans le lanceur d’applications Office 365 (Authentification liée) et la connexion par mot de passe au travers une extension de navigateur dédiée. Cette dernière section permet aussi de choisir l’ajout d’une application qui utilise le protocole SAML 2.0.

Création de l’application

Comme indiqué précédemment, la configuration d’une « non-gallery application » impose d’avoir une licence premium:

Une fois la licence premium activée, l’assistant de configuration nous demande un nom d’application (il sera possible de le changer par la suite)

URL et Entity ID

Après qu’Azure ait créé l’application et affecté un ID d’application et d’objet, la configuration s’effectue dans l’onglet Signle sign-on en sélectionnant SAML-based Sing-on.

Nous pouvons alors entrer manuellement les valeurs ou charger un fichier de métadonnées issu de notre application (metadata.xml dans Upload metadata file) pour pré-remplir la valeur des champs. Je préfère pour améliorer la compréhension de ce sujet, saisir « à la main » les informations.

2 informations principales sont requises et 2 optionnelles. Cocher « Show advanced URL settings » pour ces dernières, nous allons renseigner les 3 premiers champs:

• Identifier (Entity ID): Doit identifier de manière unique l’application dans notre tenant AZURE AD. Cette valeur correspond à l’élément ISSUER dans la demande SAML AuthRequest envoyée par l’application. Cette valeur apparaît également comme l’ID d’entité dans les métadonnées SAML fournies par l’application (SP).
  -> https://monsite.test.local/
• Reply URL (Assertion Consumer Service URL): L’URL de réponse est utilisée  l’IDP pour rediriger l’utilisateur après authentification. C’est l’URL de où l’application attend le jeton SAML.
  -> https://monsite.test.local/Shibboleth.sso/SAML2/POST
• Sign on URL: Si ce champ est renseigné, Azure AD utilise cette URL pour lancer l’application à partir du panneau d’accès Azure AD: https://myapps.microsoft.com/
  -> https://monsite.test.local/Shibboleth.sso/Login
  Lanceur d’application:
  

Jeton SAML

Les URL de redirection et identifiant étant maintenant renseignés, il va falloir se focaliser sur ce qui sera présent dans notre jeton. A minima, nous devons fournir un identificateur de l’utilisateur.  Il s’agit d’un identifiant unique appelé NameID, forgé dans le jeton en tant qu’attribut à destination de l’application. Nous utilisons ici par défaut l’userprincipalname de l’utilisateur mais le portail propose d’utiliser un autre attribut. Cela pourrait être par exemple un matricule identifiant l’utilisateur dans une entreprise.

Le NameID sera identifiable sous cette forme dans le jeton http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier (Namespace ou Claim type) et contiendra donc utilisateur1@remivernierhotmail.onmicrosoft.com.

Azure propose d’ajouter d’autres attributs dans le jeton. En cochant la case « View and edit all other attributes » nous pouvons en ajouter ou consulter ceux par défaut. Ces informations proviennent d’Azure AD mais elle pourraient provenir d’un AD local qui serait synchronisé via AADSync.

 

Metadata

Pour une interopérabilité sécurisée, les partenaires (SP et IDP) doivent partager leur propre métadonnées afin que chaque partie connaisse l’autre à l’avance. Ceci pour établir une base de confiance (Trust ou RPT). L’idéal est d’automatiser le processus de partage des métadonnées à travers un fichier XML public. Chaque entité rafraîchi périodiquement le metadata de l’autre.

Ce fichier metadata doit contenir à minima:

• Son Entity ID
• Les clé cryptographiques (voir plus bas)
• Les points de terminaisons (endpoint ou Assertion Consumer Service URL)

Le medatata.xml de notre Idp est présent dans le champs « App Federation Metadata Url ». Il sera à importer coté SP. Il est dans Azure sous le format ci dessous ou téléchargeable:

URL des metadadonnées de l’application:
https://login.microsoftonline.com/93535e3e-9602-4158-afe0-d87fdeeeec9d/federationmetadata/2007-06/federationmetadata.xml?appid=2b1cf0b0-f5e9-4c58-ab5d-1c6c7b7656ce

Ou:
appid=2b1cf0b0-f5e9-4c58-ab5d-1c6c7b7656ce (correspond à notre ID d’application)

Et
93535e3e-9602-4158-afe0-d87fdeeeec9d (correspond à notre ID de répertoire / Tenant ID)

Certificats

Nous l’avons vu plus haut, le client est le « pivot ». Pour éviter qu’il puisse y avoir une compromission du jeton par ce dernier, le message présent dans le jeton SAML doit être signé numériquement par l’émetteur (IDP). Pour vérifier la signature du message, le destinataire du message (SP) utilise une clé publique connue et appartenant à l’émetteur (IDP). De même, il est aussi possible de chiffrer un message. Dans les deux situations, les clé cryptographiques publiques doivent être partagées à l’avance (via le metadata précédemment évoqué).

Le message peut être de la forme:

• SAML REQUEST: émis par le SP. Il peut être signé par le SP et cette signature doit être vérifiée par l’IDP.
• SAML RESPONSE: émis par l’IDP. Il doit être signé par l’IDP  et cette signature doit être vérifiée par le SP.

Dans notre cas, et par défaut, l’IDP (Azure AD) signera en SHA-256 les jetons SAML (Sign SAML assertion). Cette signature devra donc être vérifiée par notre application (SP).

Les certificats ont une durée de vie, et doivent donc être périodiquement renouvelés. Le certificat automatiquement généré a une durée de vie de 3 ans, mais il est plutôt conseillé de la porter à un an. Nous voyons ici l’importance d’automatiser la consultation des metadonnées. Si ça n’est pas le cas les certificats publics devrons être déployés « à la main » et cela provoquera une interruption de service pour l’application.

Une fois l’ensemble de la configuration sauvegardée, nous sommes prêt à configurer l’application (SP).

Création de l’utilisateur de test

Nous l’avons vu plus haut que pour qu’un utilisateur s’authentifie, il doit être représenté par un compte présent chez un fournisseur d’identité: Azure AD. Il nous faut donc créer un compte sans droits particulier: utilisateur1@remivernierhotmail.onmicrosoft.com.

Et l’ajouter comme utilisateur habilité à utiliser l’application dans « Users and Groups ».

Cette dernière étape est nécessaire car l’option  « User assigment required » est activée.

Configuration de l’application: Shibboleth SP

Nous allons utiliser comme Service Provider l’application Shibboleth SP. Elle se présente comme une extension ISAPI. Elle est mise en œuvre sous forme de DLL et chargée sous contrôle d’IIS. Je vous propose de consulter cet article pour suivre son installation. Dans la suite nous allons considérer que Shibboleth SP est déjà installé et prêt à fonctionner. Nous verrons donc uniquement la partie paramétrage du produit dans notre contexte.

Le répertoire d’installation de Shibboleth SP est C:\opt\shibboleth-sp. Les répertoires et fichiers ci dessous vont particulièrement nous intéresser:

•  C:\opt\shibboleth-sp\etc\shibboleth
  – shibboleth2.xml qui contient la configuration générale de Shibboleth
  – attribute-map.xml qui contient la translation des noms d’attributs contenus dans les assertions SAML envoyées par l’IdP vers des en-têtes HTTP exploitables par l’application finale.
  – keygen.bat qu’il faudra exécuter pour générer une nouvelle paire de clés (Signature et Encryption sur SP). Non utilisé dans ce scénario puisque seul la SAML RESPONSE est signée par l’IDP.
  – partner-metadata.xml est le metadata de l’IDP téléchargé dans notre application Azure AD et renommé.
• C:\opt\shibboleth-sp\var\log\shibboleth qui contient les fichiers de logs et notamment shibd.log

 

Fichier shibboleth2.xml

Original:

A remplacer par:

l’id doit correspondre à l’ID du site IIS:

 

Original:

A remplacer par:

 

Original:

A remplacer par:

L’ApplicationDefaults EntityID (Identifier) doit correspondre à celui qui est renseigné dans Azure AD. Nous ajoutons ici une référence à la possibilité de signer les SAML REQUEST ou chiffrer la chaîne avec les certificats présents et inscrits dans le metadata coté SP. Nous n’utiliserons pas ici cette fonctionnalité.

Le SSO EntityID  correspond à l’entityID présent dans le metadata de l’IDP téléchargeable dans l’application Azure AD:

Nous en profitons pour renforcer les contrôles de sécurité en passant checkAddress et handlerSSL à true et cookieProps à https. Nous pouvons supprimer la partie discoveryProtocol et discoveryURL, Azure AD ne possédant pas cette fonctionnalité de découverte.

Enfin, nous supprimons l’acl présente sur la page /Status et passons le showAttributeValues de /Session à true.

 

Fichier attribute-map.xml

Ce fichier va permettre d’indiquer à Shibboleth de mapper les attributs présents dans notre jeton SAML avec des id que nous pourrions récupérer sous forme de variable si nous développions une application complète.

Nous pouvons supprimer l’ensemble des exemples présents par défaut dans ce fichier xml et le remplacer par ce qui est présents dans notre jeton SAML:

Exécution du keygen.bat

Dans ce scénario, nous n’utilisons pas la possibilité de signer les SAML REQUEST ou chiffrer la chaîne avec les certificats présents et inscrits dans le metadata coté SP. Malgré tout si le besoin s’en faisait sentir ou tout simplement pour avoir un metadata coté SP propre, il nous faut exécuter en tant qu’admin les commandes ci dessous dans un « cmd »:

C:\opt\shibboleth-sp\etc\shibboleth> keygen.bat -h monsite.test.local -e https://monsite.test.local -f -n sp-encrypt
C:\opt\shibboleth-sp\etc\shibboleth> keygen.bat -h monsite.test.local -e https://monsite.test.local -f -n sp-signing

Les nouvelles paires de clés sont alors créés sous C:\opt\shibboleth-sp\etc\shibboleth

• sp-encrypt-cert.pem – correspond à la clé publique du certificat d’encryption coté SP
• sp-encrypt-key.pem – correspond à la clé privée du certificat d’encryption coté SP
• sp-signing-cert.pem – correspond à la clé publique du certificat de signature coté SP
• sp-signing-key.pem – correspond à la clé privée du certificat de signature coté SP

Le fichier shibboleth2.xml en fait référence ci dessous :

Fichier partner-metadata.xml

Il s’agit ni plus ni moins des métadonnées de notre IDP coté Azure AD, téléchargeable en cliquant sur le lien Metadata XML. Ce fichier est à copier dans C:\opt\shibboleth-sp\etc\shibboleth et à renommer partner-metadata.xml

L’ensemble de la configuration de Shibboleth SP est à présent terminée. Pour appliquer celle ci, il suffit de redémarrer le service Shibboleth Daemon (Default).
Le fichier C:\opt\shibboleth-sp\var\log\shibboleth\shibd.log doit nous indiquer aucune erreur au démarrage.

 

Test du scénario

Lancer avec Internet explorer par exemple l’URL: https://monsite.test.local/Shibboleth.sso/Login

Le Service Provider doit nous transmettre un SAML REQUEST et nous rediriger vers l’URL indiquée dans AssertionConsumerServiceURL (URL de l’IDP).

(Pour obtenir le contenu du jeton, je vous invite à aller consulter l’article: Outils d’analyse réseau).

Une fois redirigé vers l’IDP (Azure AD), ce dernier doit nous demander un login et un mot de passe correspondant à notre utilisateur utilisateur1@remivernierhotmail.onmicrosoft.com, il doit nous authentifier et nous remettre une SAML RESPONSE (Le fichier étant un peu gros, vous le trouverez en suivant le lien).

Le SAML RESPONSE est alors transmis par le client au SP qui vient le lire et récupérer les assertions.
La page, https://monsite.test.local/Shibboleth.sso/Session nous affiche les attribut mappés (configurés précédemment dans le fichier attribute-map.xml)

En parallèle C:\opt\shibboleth-sp\var\log\shibboleth\shibd.log doit nous indiquer une trace de cette authentification:

INFO Shibboleth.SessionCache [1] [default]: new session created: ID (_60e90f08a8b5b050e1ee0e64671e2451) IdP (https://sts.windows.net/93535e3e-9602-4158-afe0-d87fdeeeec9d/) Protocol(urn:oasis:names:tc:SAML:2.0:protocol) Address (10.203.250.138)

 

J’ai enregistré le scénario complet dans l’animation ci après. Il faut cliquer sur l’image pour la lancer: