Configurer les fournisseurs d’identité

  • 10 minutes

Vous pouvez configurer la fédération directe avec n’importe quelle organisation dont le fournisseur d’identité (IdP) prend en charge le protocole SAML 2.0 (Security Assertion Markup Language) ou WS-Fed (WS-Federation). Quand vous configurez la Fédération directe avec le fournisseur d'identité d’un partenaire, les nouveaux utilisateurs invités de ce domaine peuvent utiliser leur propre compte professionnel géré par le fournisseur d'identité pour se connecter à votre locataire Azure Active Directory (Azure AD) et commencer à collaborer avec vous. Il n’est pas nécessaire pour l’utilisateur invité de créer un compte Azure AD séparé.

Notes

Vos utilisateurs invités de fédération directe doivent se connecter à l’aide d’un lien incluant le contexte du locataire (par exemple, https://myapps.microsoft.com/?tenantid= tenant id ou https://portal.azure.com/ tenant id, ou dans le cas d’un domaine vérifié, https://myapps.microsoft.com/ verified domain .onmicrosoft.com). Liens directs aux applications et ressources fonctionnent également tant qu’ils incluent le contexte client. Les utilisateurs de la fédération directe ne peuvent actuellement pas se connecter à l’aide de points de terminaison communs qui n’ont aucun contexte locataire. Par exemple, l’utilisation de https://myapps.microsoft.com, https://portal.azure.com, ou https://teams.microsoft.com entraîne une erreur.

Quand un utilisateur invité est-il authentifié avec la fédération directe ?

Après avoir configuré la fédération directe avec une organisation, tous les utilisateurs invités que vous invitez seront authentifiés à l’aide de la fédération directe. La configuration de la fédération directe ne change pas la méthode d’authentification pour les utilisateurs invités qui ont déjà utilisé une invitation de votre part. Voici quelques exemples :

  • Si, lorsque vous configurez la fédération directe avec leur organisation, des utilisateurs invités ont déjà accepté des invitations provenant de vous, ils continuent à utiliser la même méthode d’authentification qu’avant la configuration de la fédération directe.
  • Si vous invitez des utilisateurs après avoir configuré la fédération directe avec une organisation partenaire, et que celle-ci passe ensuite à Azure AD, les utilisateurs invités qui ont déjà accepté leurs invitations continuent d’utiliser la fédération directe, tant que la stratégie de fédération directe existe dans votre locataire.
  • Si vous supprimez la fédération directe avec une organisation partenaire, les utilisateurs invités qui utilisaient la fédération directe ne peuvent plus se connecter.

Dans un de ces scénarios, vous pouvez mettre à jour la méthode d’authentification d’un utilisateur invité en supprimant le compte d’utilisateur invité de votre répertoire et en le réinvitant.

La fédération directe est liée aux espaces de noms domaine, par exemple contoso.com et fabrikam.com. Si vous établissez une configuration de type fédération directe avec AD FS ou un fournisseur d’identité tiers, les organisations associent un ou plusieurs espaces de noms de domaine à ce fournisseur d’identité.

Expérience de l’utilisateur final

Avec la fédération directe, les utilisateurs invités se connectent à votre client Azure AD à l’aide de leur propre compte professionnel. Lorsqu’ils accèdent à des ressources partagées et qu’ils sont invités à se connecter, les utilisateurs de la fédération directe sont redirigés vers leur fournisseur d’identité. Après s’être connectés, ils sont renvoyés vers Azure AD pour accéder aux ressources. Les jetons d’actualisation des utilisateurs de la fédération directe sont valides pendant 12 heures (la durée par défaut de transfert d’un jeton d’actualisation dans Azure AD). Si le fournisseur d’identité fédéré dispose de l’authentification unique, l’utilisateur en bénéficie. Il ne voit aucune invite de connexion après son authentification initiale.

Limitations

Les limitations de la fédération directe sont les suivantes :

Limite Description
Domaines vérifiés par DNS dans Azure AD Le domaine avec lequel vous voulez vous fédérer ne doit pas être vérifié par le système DNS dans Azure AD. Vous êtes autorisé à configurer la fédération directe avec des locataires Azure AD non managés (vérifiés par e-mail ou viraux), car ces derniers ne sont pas vérifiés par le système DNS.
URL d’authentification La fédération directe est uniquement autorisée pour les stratégies où le domaine de l’URL d’authentification correspond au domaine cible, ou lorsque l’URL d’authentification correspond à l’un des fournisseurs d’identité autorisés. Les fournisseurs actuels sont les suivants :
accounts.google.com
pingidentity.com
okta.com
federation.exostar.com
(Cette liste est susceptible d’être modifiée.)
Par exemple, lorsque vous configurez la fédération directe pour fabrikam.com, l’URL d’authentification https://fabrikam.com/adfs transmet la validation. Un ordinateur hôte dans le même domaine passe également, par exemple https://sts.fabrikam.com/adfs. Toutefois, l’URL d’authentification https://fabrikamconglomerate.com/adfs ou https://fabrikam.com.uk/adfs pour le même domaine ne passera pas.
Renouvellement du certificat de signature Si vous spécifiez l’URL de métadonnées dans les paramètres du fournisseur d’identité, Azure AD renouvelle automatiquement le certificat de signature à son expiration. Toutefois, si le certificat pivote avant le délai d’expiration pour une raison quelconque, ou si vous ne fournissez pas une URL de métadonnées, Azure AD ne pourra pas le renouveler. Dans ce cas, vous devez mettre à jour le certificat de signature manuellement.
Limite des relations de fédération Pour le moment, le nombre de relations de fédération maximum pris en charge est limité à 1 000. Cette limite concerne à la fois les fédérations internes et les fédérations directes.
Limite des domaines multiples Microsoft ne prend actuellement pas en charge la fédération directe avec plusieurs domaines du même locataire.

Configuration de Security Assertion Markup Language 2.0

Azure AD B2B peut être configuré pour la fédération avec les fournisseurs d’identité qui utilisent le protocole SAML avec certaines exigences spécifiques indiquées ci-dessous.

Notes

Le domaine cible pour la fédération directe ne doit pas être vérifié par DNS sur Azure AD.

Attributs et revendications requis Security Assertion Markup Language 2.0

Les tableaux suivants présentent la configuration requise pour les attributs spécifiques et les revendications qui doivent être configurés au niveau du fournisseur d’identité tiers. Pour configurer la fédération directe, les attributs suivants doivent être reçus dans la réponse SAML 2.0 à partir du fournisseur d’identité. Ces attributs peuvent être configurés en liant le fichier XML du service d’émission de jeton de sécurité en ligne ou en les entrant manuellement.

Attributs requis pour la réponse SAML 2.0 du fournisseur d’identité :

Attribut Valeur
AssertionConsumerService https://login.microsoftonline.com/login.srf
Public visé urn:federation:MicrosoftOnline
Émetteur L’URI de l’émetteur du fournisseur d’identité partenaire, par exemple http://www.example.com/exk10l6w90DHM0yi...

Revendications requises pour le jeton SAML 2.0 émis par le fournisseur d’identité :

Attribut Valeur
Format NameID urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
emailaddress http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress

Configuration de WS-Federation

Azure AD B2B peut être configuré pour la fédération avec les fournisseurs d’identité qui utilisent le protocole WS-Fed avec certaines exigences spécifiques indiquées ci-dessous. Actuellement, les deux fournisseurs WS-Fed testés pour assurer la compatibilité avec Azure AD incluent AD FS et Shibboleth.

Le domaine cible pour la fédération directe ne doit pas être vérifié par DNS sur Azure AD. Le domaine de l’URL d’authentification doit correspondre au domaine cible ou au domaine d’un fournisseur d’identité autorisé.

Attributs et revendications requis pour WS-Federation

Les tableaux suivants présentent la configuration requise pour les attributs spécifiques et les revendications qui doivent être configurés au niveau du fournisseur d’identité WS-Fed tiers. Pour configurer la fédération directe, les attributs suivants doivent être reçus dans le message WS-Fed à partir du fournisseur d’identité. Ces attributs peuvent être configurés en liant le fichier XML du service d’émission de jeton de sécurité en ligne ou en les entrant manuellement.

Attributs requis dans le message WS-Fed du fournisseur d’identité :

Attribut Valeur
PassiveRequestorEndpoint https://login.microsoftonline.com/login.srf
Public visé urn:federation:MicrosoftOnline
Émetteur L’URI de l’émetteur du fournisseur d’identité partenaire, par exemple http://www.example.com/exk10l6w90DHM0yi...

Revendications requises pour le jeton WS-Fed émis par le fournisseur d’identité :

Attribut Valeur
ImmutableID http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID
emailaddress http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress

Ajouter Google comme fournisseur d’identité pour les utilisateurs invités B2B

En configurant la fédération avec Google, vous pouvez autoriser les utilisateurs invités à se connecter à vos applications et ressources partagées avec leur propre compte Gmail, sans avoir besoin de créer un compte Microsoft.

Notes

La fédération Google est conçue spécialement pour les utilisateurs Gmail. Pour fédérer avec les domaines G Suite, utilisez la fédération directe.

Quelle est l’expérience de l’utilisateur Google ?

Lorsque vous envoyez une invitation à des utilisateurs de Google Gmail, les utilisateurs invités doivent accéder à vos applications ou ressources partagées à l’aide d’un lien qui inclut le contexte locataire. Son expérience varie selon qu’il est ou non déjà connecté à Google :

  • Les utilisateurs invités qui ne sont pas connectés à Google seront invités à le faire.
  • Les utilisateurs invités déjà connectés à Google seront invités à choisir le compte qu’ils souhaitent utiliser. Il doit choisir le compte que vous avez utilisé pour l’inviter.

Les utilisateurs invités qui voient une erreur header too long (en-tête trop long) peuvent effacer leurs cookies ou ouvrir une fenêtre privée ou incognito, puis essayer de se reconnecter.

Capture d’écran montrant la page de connexion Google. Les utilisateurs doivent se connecter pour obtenir l’accès.

Prise en charge de la connexion WebView déconseillée

À compter du 4 janvier 2021, Google déconseille la prise en charge de la connexion WebView incorporée. Si vous utilisez la fédération Google ou l’inscription en libre-service avec Gmail, testez la compatibilité de vos applications métier natives. Si vos applications incluent du contenu WebView pour lequel une authentification est nécessaire, les utilisateurs de Google Gmail ne pourront pas s’authentifier. Voici quelques scénarios connus ayant une incidence sur les utilisateurs de Gmail :

  • Applications Windows qui utilisent la connexion WebView incorporée ou WebAccountManager (WAM) sur des versions antérieures de Windows
  • Autres applications natives développées par vos soins, qui utilisent une infrastructure de navigateur incorporée pour l’authentification

Ce changement n’affecte pas les types d’utilisateurs suivants :

  • Applications Windows qui utilisent la connexion WebView incorporée ou WebAccountManager (WAM) sur les dernières versions de Windows
  • Applications Microsoft iOS
  • Identités G Suite, par exemple la fédération directe basée sur SAML utilisée avec G Suite

Nous continuons à tester différentes plateformes et différents scénarios afin de mettre à jour les informations publiées en conséquence.

Test de la compatibilité des applications

  1. Suivez les conseils de Google pour déterminer si vos applications sont affectées.

  2. À l’aide de Fiddler ou d’un autre outil de test, injectez un en-tête lors de la connexion et utilisez une identité Google externe pour tester la connexion :

    1. Ajoutez Google-Accounts-Check-OAuth-Login:true à vos en-têtes de requête HTTP lorsque les demandes sont envoyées à accounts.google.com.
    2. Essayez de vous connecter à l’application en entrant une adresse Gmail sur la page de connexion accounts.google.com.
    3. Si la connexion échoue et qu’une erreur du type « Ce navigateur ou cette application n’est peut-être pas sécurisé » apparaît, la connexion des identités Google externes sera bloquée.

  3. Résolvez le problème en effectuant l’une des tâches suivantes :

    • Si votre application Windows utilise la connexion WebView incorporée ou WebAccountManager (WAM) sur une version antérieure de Windows, passez à la dernière version de Windows.
    • Modifiez vos applications de façon à utiliser le navigateur système pour la connexion. Pour plus d’informations, consultez Interface utilisateur incorporée ou Web System dans la documentation de MSAL.NET.

Points de terminaison de connexion

Teams prend entièrement en charge les utilisateurs invités Google sur tous les appareils. Les utilisateurs de Google peuvent se connecter à Teams à partir d’un point de terminaison commun, comme https://teams.microsoft.com.

Les points de terminaison communs d’autres applications ne prennent pas forcément en charge les utilisateurs Google. Les utilisateurs invités Google doivent se connecter à l’aide d’un lien comportant les informations de votre locataire. Voici quelques exemples :

  • https://myapps.microsoft.com/?tenantid= your tenant ID
  • https://portal.azure.com/ your tenant ID
  • https://myapps.microsoft.com/ your verified domain .onmicrosoft.com

S’ils essaient d’utiliser un lien comme https://myapps.microsoft.com ou https://portal.azure.com, les utilisateurs invités Google obtiendront une erreur.

Vous pouvez également fournir aux utilisateurs invités Google un lien direct vers une application ou une ressource, à condition qu’il comprenne les informations de votre locataire. Par exemple : https://myapps.microsoft.com/signin/Twitter/ application ID?tenantId= your tenant ID

Étape 1 : Configurer un projet de développeur Google

Commencez par créer un projet dans la console des développeurs Google pour obtenir un ID client et une clé secrète client que vous pourrez ajouter plus tard à Azure Active Directory (Azure AD).

  1. Accédez aux API Google à l’adresse https://console.developers.google.com et connectez-vous avec votre compte Google. Nous vous recommandons d’utiliser un compte Google d’équipe partagé.

  2. Acceptez les conditions d’utilisation du service si vous y êtes invité.

  3. Créer un projet : Dans le tableau de bord, sélectionnez Créer un projet, donnez un nom au projet (par exemple Azure AD B2B), puis sélectionnez Créer :

    Capture d’écran de la page Nouveau projet dans la page développeurs Google.

  4. Dans la page API et services, sélectionnez Afficher sous votre nouveau projet.

  5. Sélectionnez Accéder à l’aperçu des API sur la carte des API. Sélectionnez Écran d’autorisation OAuth.

  6. Sélectionnez Externe, puis sélectionnez Créer.

  7. Dans l’écran de consentement OAuth, entrez un nom d’application :

    Capture d’écran de l’écran de consentement Google OAuth. Les utilisateurs doivent confirmer leur utilisation.

  8. Accédez à la section Domaines autorisés et entrez microsoftonline.com :

    Capture d’écran de la section Domaines autorisés, avec les domaines Google valides.

  9. Sélectionnez Enregistrer.

  10. Sélectionnez Credentials (Informations d’identification). Dans le menu Créer les informations d’identification, sélectionnez ID client OAuth :

    Capture d’écran du menu Créer des informations d’identification des API Google. Configurez vos informations d’identification ici.

  11. Sous Type d’application, sélectionnez Application web. Donnez à l’application un nom approprié, par exemple Azure AD B2B. Sous URI de redirection autorisés, entrez les URI suivants :

    • https://login.microsoftonline.com
    • https://login.microsoftonline.com/te/ tenant ID /oauth2/authresp (où https://login.microsoftonline.com/te/ tenant ID /oauth2/authresp est votre ID de locataire dans Azure)

    Capture d’écran de la section URI de redirection autorisée. Où les utilisateurs accèdent pour valider l’autorisation.

  12. Sélectionnez Create (Créer). Copiez l’ID client et la clé secrète client. Vous les utiliserez lorsque vous ajouterez le fournisseur d’identité dans le portail Azure.

    Capture d’écran de l’ID client OAuth et de la clé secrète client. Définissez votre secret d’accès.

Étape 2 : Configurer la fédération de Google dans Azure AD

Maintenant vous définirez l’ID client Google et la clé secrète client. Pour cela, vous pouvez utiliser le portail Azure ou PowerShell. Pensez à tester votre configuration de fédération de Google en invitant vous-même. Utilisez une adresse Gmail et essayez de donner suite à l’invitation avec votre compte Google invité.

Pour configurer la fédération de Google dans le portail Azure

  1. Accédez au portail Azure. Sélectionnez Azure Active Directory dans le volet de gauche.

  2. Sélectionnez Identités externes.

  3. Sélectionnez Tous les fournisseurs d’identité, puis cliquez sur le bouton Google.

  4. Entrez l’ID client et la clé secrète client obtenus précédemment. Sélectionnez Enregistrer :

    Capture d’écran de la page Ajouter un fournisseur d’identité Google. Choisissez votre fournisseur d’identité.

Comment supprimer la fédération de Google ?

Vous pouvez supprimer votre configuration de fédération de Google. Si vous le faites, les utilisateurs invités Google qui ont déjà utilisé leur invitation ne pourront plus se connecter. Mais vous pouvez leur donner accès à vos ressources à nouveau en les supprimant du répertoire et en les réinvitant.

Pour supprimer la fédération de Google dans le portail Azure AD

  1. Accédez au portail Azure. Sélectionnez Azure Active Directory dans le volet de gauche.

  2. Sélectionnez Identités externes.

  3. Sélectionnez Tous les fournisseurs d’identité.

  4. Dans la ligne Google, sélectionnez le bouton représentant des points de suspension ( ... ), puis choisissez Supprimer.

    Capture d’écran du bouton de suppression du fournisseur d’identité sociale.

  5. Sélectionnez Oui pour confirmer la suppression.

Ajouter Facebook en tant que fournisseur d’identité pour les identités externes

Vous pouvez ajouter Facebook à vos flux utilisateurs d’inscription en libre-service (préversion) afin que les utilisateurs puissent se connecter à vos applications en utilisant leurs propres comptes Facebook. Pour permettre à vos utilisateurs de se connecter à l’aide de Facebook, vous devez activer l’inscription en libre-service sur votre locataire. Après avoir ajouté Facebook en tant que fournisseur d’identité, configurez un flux utilisateur pour l’application, puis sélectionnez Facebook comme l’une des options de connexion.

Notes

Les utilisateurs ne peuvent utiliser leur compte Facebook que pour s’inscrire sur des applications à l’aide de l’inscription libre-service et des flux utilisateurs. Les utilisateurs ne peuvent pas être invités à accepter leur invitation à l’aide d’un compte Facebook.

Créer une application dans la console des développeurs Facebook

Pour utiliser un compte Facebook en tant que fournisseur d’identité, vous devez créer une application dans la console des développeurs Facebook. Si vous n’avez pas encore de compte Facebook, vous pouvez en créer un sur https://www.facebook.com/.

Notes

Utilisez les URL suivantes aux étapes 9 et 16 ci-dessous.

  • Dans URL du site, entrez l’adresse de votre application, par exemple .
  • Pour URI de redirection OAuth valides, entrez . Vous trouverez votre tenant-ID sur l’écran Vue d’ensemble d’Azure Active Directory.
  1. Connectez-vous à Facebook pour les développeurs avec les informations d’identification de votre compte Facebook.
  2. Si ce n’est déjà fait, vous devez vous inscrire en tant que développeur Facebook. Sélectionnez Prise en main en haut à droite de la page, acceptez les politiques de Facebook et suivez la procédure d’inscription.
  3. Sélectionnez Mes applications, puis Créer une application.
  4. Entrez un nom d’affichage et une adresse e-mail de contact valide.
  5. Sélectionnez Créer un ID d'application. Il peut vous être demandé d’accepter les politiques de la plateforme Facebook et d’effectuer une vérification de sécurité en ligne.
  6. Sélectionnez Paramètres, puis De base.
  7. Choisissez une catégorie, par exemple, Entreprise et pages. Cette valeur est requise par Facebook, mais n’est pas utilisée pour Azure AD.
  8. Au bas de la page, sélectionnez Ajouter une plateforme, puis sélectionnez Site web.
  9. Dans URL du site, entrez l’URL appropriée (indiquée ci-dessus).
  10. Dans URL de la politique de confidentialité, entrez l’URL de la page dans laquelle vous gérez les informations de confidentialité de votre application, par exemple .
  11. Sélectionnez Enregistrer les modifications.
  12. En haut de la page, copiez la valeur de l’ID de l’application.
  13. Sélectionnez Afficher, puis copiez la valeur Clé secrète de l’application. Vous avez besoin de ces deux valeurs pour configurer Facebook en tant que fournisseur d’identité dans votre client. App Secret est une information d’identification de sécurité essentielle.
  14. Cliquez sur le signe plus en regard de la zone PRODUITS, puis sélectionnez Configurer sous Connexion Facebook.
  15. Sous Connexion Facebook, sélectionnez Paramètres.
  16. Dans URI de redirection OAuth valides, entrez l’URL appropriée (indiquée ci-dessus).
  17. Sélectionnez Enregistrer les modifications en bas de la page.
  18. Pour rendre votre application Facebook disponible sur Azure AD, sélectionnez le sélecteur État dans la partie supérieure droite de la page et activez-le pour rendre l’application publique, puis sélectionnez Changer de mode. À ce stade, l’état doit passer de Développement à Production.

Configuration d’un compte Facebook en tant que fournisseur d’identité

Désormais, vous définirez l’ID et la clé secrète client Facebook, soit en les entrant dans le portail Azure AD, soit en utilisant PowerShell. Vous pouvez tester votre configuration Facebook en vous inscrivant via un flux d’utilisateurs sur une application prenant en charge l’inscription en libre-service.

Pour configurer la Fédération Facebook dans le portail Azure AD

  1. Connectez-vous au portail Azure en tant qu’administrateur général de votre locataire Azure AD.

  2. Sous Services Azure, sélectionnez Azure Active Directory.

  3. Dans le menu de gauche, sélectionnez Identités externes.

  4. Sélectionnez Tous les fournisseurs d’identité, puis Facebook.

  5. Dans ID client, entrez l’ID de l’application Facebook que vous avez créée précédemment.

  6. Dans Clé secrète client, entrez la Clé secrète d’application que vous avez consignée.

    Capture d’écran de la page Ajouter un fournisseur d’identité sociale. Choisissez votre fournisseur de réseaux sociaux.

  7. Sélectionnez Enregistrer.

Comment supprimer la Fédération Facebook ?

Vous pouvez supprimer votre configuration de Fédération de Google. Dans ce cas, les utilisateurs qui se sont inscrits par le biais de flux utilisateurs avec leur compte Facebook ne peuvent plus se connecter.

Pour supprimer la Fédération Facebook dans le portail Azure AD :

  1. Accédez au portail Azure. Sélectionnez Azure Active Directory dans le volet de gauche.
  2. Sélectionnez Identités externes.
  3. Sélectionnez Tous les fournisseurs d’identité.
  4. Dans la ligne Google, sélectionnez le menu contextuel ( ... ), puis Supprimer.
  5. Sélectionnez Oui pour confirmer la suppression.