Informations de référence sur le fournisseur de méthode externe d’authentification multifacteur Microsoft Entra (préversion)
Cette rubrique décrit comment un fournisseur d’authentification externe se connecte à l’authentification multifacteur (Multifactor Authentication/MFA) Microsoft Entra . Un fournisseur d’authentification externe peut s’intégrer aux tenants Microsoft Entra ID comme méthode d’authentification externe (EAM). Une EAM peut satisfaire le deuxième facteur d’une exigence MFA pour l’accès à une ressource ou une application. Les EAM nécessitent au minimum une licence Microsoft Entra ID P1.
Lorsqu’un utilisateur se connecte, ces stratégies de tenant sont évaluées. Les exigences d’authentification sont déterminées en fonction de la ressource à laquelle l’utilisateur tente d’accéder.
Plusieurs stratégies peuvent s’appliquer à la connexion, en fonction de leurs paramètres. Ces paramètres incluent les utilisateurs et les groupes, les applications, la plateforme et le niveau de risque de connexion, entre autres.
En fonction des exigences d’authentification, l’utilisateur peut avoir besoin de se connecter avec un autre facteur pour répondre aux exigences MFA. Le deuxième facteur doit compléter le type de premier facteur.
Les EAM sont ajoutés à Microsoft Entra ID par l’administrateur du tenant. Si un tenant nécessite une EAM pour la MFA, la connexion est considérée comme conforme à l’exigence MFA après que Microsoft Entra ID valide à la fois :
- Le premier facteur rempli par Microsoft Entra ID
- Le deuxième facteur rempli par l’EAM
Cette validation répond à l’exigence MFA pour deux types de méthodes ou plus parmi :
- Quelque chose que vous connaissez (connaissance)
- Quelque chose que vous avez (possession)
- Quelque chose que vous êtes (inhérence)
Les EAM sont implémentées par-dessus Open ID Connect (OIDC). Cette implémentation nécessite au moins trois points de terminaison accessibles publiquement :
- Un point de terminaison de découverte OIDC, comme décrit dans Découverte des métadonnées du fournisseur
- Un point de terminaison d’authentification OIDC valide
- Une URL dans laquelle les certificats publics du fournisseur sont publiés
Examinons de plus près le fonctionnement de la connexion avec une EAM :
- Un utilisateur tente de se connecter avec un premier facteur, comme un mot de passe, à une application protégée par Microsoft Entra ID.
- Microsoft Entra ID détermine qu’un autre facteur doit être satisfait. Par exemple, une stratégie d’accès conditionnel nécessite une MFA.
- L’utilisateur choisit une EAM comme deuxième facteur.
- Microsoft Entra ID redirige la session de navigateur de l’utilisateur vers l’URL EAM :
- Cette URL est découverte depuis l’URL de découverte configurée par un administrateur lors de la création de l’EAM.
- L’application fournit un jeton expiré ou presque expiré, qui contient des informations permettant d’identifier l’utilisateur et le tenant.
- Le fournisseur d’authentification externe valide le fait que le jeton provient de Microsoft Entra ID et vérifie le contenu du jeton.
- Le fournisseur d’authentification externe peut éventuellement faire un appel à Microsoft Graph pour récupérer des informations supplémentaires sur l’utilisateur.
- Le fournisseur d’authentification externe effectue toutes les actions qu’il juge nécessaires, comme authentifier l’utilisateur avec certaines informations d’identification.
- Le fournisseur d’authentification externe redirige l’utilisateur vers Microsoft Entra ID avec un jeton valide, incluant toutes les revendications requises.
- Microsoft Entra ID valide le fait que la signature du jeton provient du fournisseur d’authentification externe configuré, puis vérifie le contenu du jeton.
- Microsoft Entra ID valide le jeton par rapport aux exigences.
- L’utilisateur a satisfait à l’exigence MFA si la validation réussit. L’utilisateur peut également avoir à répondre à d’autres exigences de stratégie.
Configurer un nouveau fournisseur d’authentification externe avec Microsoft Entra ID
Une application représentant l’intégration est requise pour que les EAM émettent le id_token_hint. L’application peut être créée de deux façons :
- Créée dans chaque tenant qui utilise le fournisseur externe.
- Créée en tant qu’application multitenant. Les administrateurs avec rôle privilégié doivent octroyer leur consentement pour activer l’intégration pour leur tenant.
Une application multitenant réduit le risque de mauvaise configuration dans chaque tenant. Elle permet également aux fournisseurs d’apporter des modifications aux métadonnées, comme les URL de réponse, dans un seul endroit, plutôt que de demander à chaque tenant de faire les modifications.
Pour configurer une application multitenant, l’administrateur du fournisseur doit d’abord :
Créer un tenant Microsoft Entra ID s’ils n’en ont pas encore.
Inscrire une application dans leur tenant.
Définir les types de comptes pris en charge de l’application sur : Comptes dans tout répertoire organisationnel (Tout tenant Microsoft Entra ID - Multitenant).
Ajouter la permission déléguée
openidetprofilede Microsoft Graph à l’application.Ne publier aucune étendue dans cette application.
Ajoutez les URL du authorization_endpoint valides du fournisseur d’identité externe à cette application en tant qu’URL de réponse.
Remarque
Le authorization_endpoint fourni dans le document de découverte du fournisseur doit être ajouté en tant qu’URL de redirection dans l’inscription de l’application. Sinon, vous obtenez l’erreur suivante : ENTRA IDSTS50161 : échec de la validation de l’URL d’autorisation du fournisseur de revendications externes !
Le processus d’inscription d’application crée une application avec plusieurs propriétés. Ces propriétés sont requises pour notre scénario.
| Propriété | Description |
|---|---|
| ID de l'objet | Le fournisseur peut utiliser l’ID d’objet avec Microsoft Graph pour interroger les informations de l’application. Le fournisseur peut utiliser l’ID d’objet pour récupérer et modifier de manière programmatique les informations de l’application. |
| ID de l’application | Le fournisseur peut utiliser l’ID d’application comme ClientId de son application. |
| URL de la page d’accueil | L’URL de la page d’accueil du fournisseur n’est utilisée pour rien, mais elle est requise dans le cadre de l’inscription d’application. |
| URL de réponse | URL de redirection valides pour le fournisseur. L’une doit correspondre à l’URL de l’hôte du fournisseur qui a été définie pour le tenant du fournisseur. L’une des URL de réponse inscrites doit correspondre au préfixe du authorization_endpoint que Microsoft Entra ID récupère via la découverte OIDC de l’URL de l’hôte. |
Une application pour chaque tenant est également un modèle valide pour prendre en charge l’intégration. Si vous utilisez une inscription à tenant unique, l’administrateur du tenant doit créer une inscription d’application avec les propriétés du tableau précédent pour une application à tenant unique.
Remarque
Le consentement administrateur pour l’application est requis dans le tenant qui utilise l’EAM. Si le consentement n’est pas octroyé, l’erreur suivante s’affiche lorsqu’un administrateur tente d’utiliser l’EAM : AADSTS900491 : principal de service <Votre ID d’application> introuvable.
Configurer des revendications facultatives
Un fournisseur peut configurer davantage de revendications en utilisant des revendications facultatives pour id_token.
Remarque
Quelle que soit la façon dont l’application est créée, le fournisseur doit configurer des revendications facultatives pour chaque environnement cloud. Si une application multitenant est utilisée pour Azure global et Azure pour le gouvernement des États-Unis, chaque environnement cloud nécessite une application et un ID d’application différents.
Ajouter une EAM à Microsoft Entra ID
Les informations du fournisseur d’identité externe sont stockées dans la stratégie de méthodes d’authentification de chaque tenant. Les informations du fournisseur sont stockées en tant que méthode d’authentification de type externalAuthenticationMethodConfiguration.
Chaque fournisseur a une entrée dans l’objet de liste de la stratégie. Chaque entrée doit déclarer :
- Si la méthode est activée
- Les groupes inclus qui peuvent utiliser la méthode
- Les groupes exclus qui ne peuvent pas utiliser la méthode
Les administrateurs d’accès conditionnel peuvent créer une stratégie avec Exiger l’octroi d’une MFA pour définir l’exigence MFA de la connexion utilisateur. Les méthodes d’authentification externes ne sont actuellement pas prises en charge par les forces d’authentification.
Pour plus d’informations sur l’ajout d’une méthode d’authentification externe dans le Centre d’administration Microsoft Entra, consultez Gérer une méthode d’authentification externe dans Microsoft Entra ID (préversion).
Interaction entre Microsoft Entra ID et le fournisseur
Les sections suivantes expliquent les exigences du fournisseur et incluent des exemples de l’interaction entre Microsoft Entra ID et un fournisseur.
Découverte des métadonnées du fournisseur
Un fournisseur d’identité externe doit fournir un point de terminaison de découverte OIDC. Ce point de terminaison est utilisé pour obtenir plus de données de configuration. L’URL complète, incluant .well-known/oidc-configurationdoit être incluse dans l’URL de découverte configurée lors de la création de l’EAM.
Le point de terminaison retourne un document JSON des métadonnées du fournisseur hébergé à cet endroit. Le point de terminaison doit également retourner l’en-tête content-length valide.
Le tableau suivant liste les données qui doivent être présentes dans les métadonnées du fournisseur. Ces valeurs sont requises pour ce scénario d’extensibilité. Le document de métadonnées JSON peut contenir plus d’informations.
Pour le document OIDC avec les valeurs des métadonnées du fournisseur, consultez Métadonnées du fournisseur.
| Valeur des métadonnées | Valeur | Commentaires |
|---|---|---|
| Émetteur | Cette URL doit correspondre à la fois à l’URL de l’hôte utilisée pour la découverte et à la revendication iss dans les jetons émis par le service du fournisseur. | |
| authorization_endpoint | Point de terminaison avec lequel Microsoft Entra ID communique pour l’autorisation. Ce point de terminaison doit être présent en tant qu’URL de réponse pour les applications autorisées. | |
| jwks_uri | Là où Microsoft Entra ID peut trouver les clés publiques nécessaires pour vérifier les signatures émises par le fournisseur. [!NOTE] Le paramètre JWK (JSON Web Key) x5c doit être présent pour fournir les représentations X.509 de clés fournies. |
|
| scopes_supported | openid | D’autres valeurs peuvent également être incluses, mais ne sont pas requises. |
| response_types_supported | id_token | D’autres valeurs peuvent également être incluses, mais ne sont pas requises. |
| subject_types_supported | ||
| id_token_signing_alg_values_supported | Microsoft prend en charge RS256 | |
| claim_types_supported | normal | Cette propriété est facultative, mais si elle est présente, elle doit inclure la valeur normale ; d’autres valeurs peuvent également être incluses. |
http://customcaserver.azurewebsites.net/v2.0/.well-known/openid-configuration
{
"authorization_endpoint": "https://customcaserver.azurewebsites.net/api/Authorize",
"claims_supported": [
"email"
],
"grant_types_supported": [
"implicit"
],
"id_token_signing_alg_values_supported": [
"RS256"
],
"issuer": "https://customcaserver.azurewebsites.net",
"jwks_uri": "http://customcaserver.azurewebsites.net/.well-known/jwks",
"response_modes_supported": [
"form_post"
],
"response_types_supported": [
"id_token"
],
"scopes_supported": [
"openid"
],
"SigningKeys": [],
"subject_types_supported": [
"public"
]
}
http://customcaserver.azurewebsites.net/.well-known/jwks
{
"keys": [
{
"kty": "RSA",
"use": "sig",
"kid": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
"x5t": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
"n": "jq277LRoE6WKM0awT3b...vt8J6MZvmgboVB9S5CMQ",
"e": "AQAB",
"x5c": [
"cZa3jz...Wo0rzA="
]
}
]
}
Remarque
Le paramètre JWK x5c doit être présent pour fournir les représentations X.509 des clés fournies.
Mise en cache des métadonnées du fournisseur
Pour améliorer le niveau de performance, Microsoft Entra ID met en cache les métadonnées retournées par le fournisseur, y compris les clés. La mise en cache des métadonnées du fournisseur empêche qu’un appel de découverte soit fait à chaque fois que Microsoft Entra ID communique avec un fournisseur d’identité externe.
Ce cache est actualisé toutes les 24 heures (un jour). Voici comment nous suggérons un effet de substitution de ses clés par un fournisseur :
- Publiez le certificat existant et lenouveau certificat dans le « jwks_uri ».
- Continuez à signer avec le certificat existant jusqu’à ce que le cache de Microsoft Entra ID soit actualisé, expiré ou mis à jour (tous les 2 jours).
- Basculez vers la signature avec le nouveau certificat.
Nous ne publions pas de planifications pour les effets de substitution de clés. Le service dépendant doit être prêt à gérer les effets de substitution immédiats et périodiques. Nous vous suggérons d’utiliser une bibliothèque dédiée, créée à cet effet, comme azure-activedirectory-identitymodel-extensions-for-dotnet. Pour plus d’informations, consultez Effet de substitution de clé de signature dans Microsoft Entra ID.
Découverte des métadonnées Microsoft Entra ID
Les fournisseurs doivent également récupérer les clés publiques de Microsoft Entra ID pour valider les jetons émis par Microsoft Entra ID.
Points de terminaison de découverte des métadonnées Microsoft Entra ID :
- Azure global :
https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration - Azure pour le gouvernement des États-Unis :
https://login.microsoftonline.us/common/v2.0/.well-known/openid-configuration - Microsoft Azure géré par 21Vianet :
https://login.partner.microsoftonline.cn/common/v2.0/.well-known/openid-configuration
À l’aide de l’identificateur de clé publique du jeton (le « kid » de la signature web JSON (JWS)), vous pouvez déterminer lesquelles des clés récupérées depuis la propriété jwks_uri doivent être utilisées pour valider la signature du jeton Microsoft Entra ID.
Validation des jetons émis par Microsoft Entra ID
Pour plus d’informations sur la validation des jetons émis par Microsoft Entra ID, consultez Validation et jeton d’ID. Il n’existe aucune étape spéciale pour les consommateurs de nos métadonnées de découverte.
La bibliothèque de validation de jeton de Microsoft contient tous les détails sur les spécificités de la validation des jetons documentées, ou elles peuvent être vérifiées en naviguant dans le code source. Pour un exemple, consultez Exemples Azure.
Une fois la validation réussie, vous pouvez utiliser la charge utile des revendications pour obtenir des détails sur l’utilisateur et son tenant.
Remarque
Il est important de valider la id_token_hint pour vous assurer que le id_token_hint provient d’un locataire Microsoft et représente votre intégration. La id_token_hint doit être entièrement validée, en particulier la signature, l’émetteur, l’audience ainsi que les autres valeurs de revendication.
Appel de Microsoft Entra ID au fournisseur d’identité externe
Microsoft Entra ID utilise le flux implicite OIDC pour communiquer avec le fournisseur d’identité externe. En utilisant ce flux, la communication avec le fournisseur est effectuée en utilisant exclusivement le point de terminaison d’autorisation du fournisseur. Pour que le fournisseur sache pour quel utilisateur Microsoft Entra ID effectue la requête, Microsoft Entra ID transmet un jeton via le paramètre id_token_hint.
Cet appel est effectué via une requête POST, car la liste des paramètres passés au fournisseur est volumineuse. Une liste volumineuse empêche l’utilisation des navigateurs, qui limitent la longueur d’une requête GET.
Les paramètres de la requête d’authentification sont listés dans le tableau suivant.
Remarque
Sauf s’ils sont listés dans le tableau suivant, les autres paramètres de la requête doivent être ignorés par le fournisseur.
| Paramètre de requête d’authentification | Valeur | Description |
|---|---|---|
| scope | openid | |
| response_type | Id_token | Valeur utilisée pour le flux implicite. |
| response_mode | form_post | Nous utilisons un formulaire POST pour éviter les problèmes liés aux URL volumineuses. Nous nous attendons à ce que tous les paramètres soient envoyés dans le corps de la requête. |
| client_id | ID client donné à Microsoft Entra ID par le fournisseur d’identité externe, comme ABCD. Pour plus d’informations, consultez Description de la méthode d’authentification externe. | |
| redirect_url | URI (Uniform Resource Identifier) de redirection vers lequel le fournisseur d’identité externe envoie la réponse (id_token_hint). | |
| Consultez un exemple après ce tableau. | ||
| nonce | Chaîne aléatoire générée par Microsoft Entra ID. Il peut s’agir de l’ID de session. Si elle est fournie, elle doit être retournée dans la réponse à Microsoft Entra ID. | |
| state | Si elle est passée, le fournisseur doit retourner l’état dans sa réponse. Microsoft Entra ID utilise l’état pour conserver le contexte de l’appel. | |
| id_token_hint | Jeton émis par Microsoft Entra ID pour l’utilisateur final et transmis pour le bénéfice du fournisseur. | |
| réclamations | Objet blob JSON qui contient les revendications requises. Pour plus d’informations sur le format de ce paramètre, consultez paramètre de requête de revendications de la documentation OIDC et l’exemple après ce tableau. | |
| client-request-id | Valeur GUID | Un fournisseur peut consigner cette valeur pour aider à résoudre les problèmes. |
Exemple d’URI de redirection
Les URI (Uniform Resource Identifiers) de redirection doivent être inscrits auprès du fournisseur hors bande. Les URI de redirection qui peuvent être envoyés sont :
- Azure global :
https://login.microsoftonline.com/common/federation/externalauthprovider - Azure pour le gouvernement des États-Unis :
https://login.microsoftonline.us/common/federation/externalauthprovider - Microsoft Azure géré par 21Vianet :
https://login.partner.microsoftonline.cn/common/federation/externalauthprovider
Exemple d’une EAM répondant à la MFA
Voici un exemple d’authentification où une EAM satisfait à la MFA. Cet exemple aide un fournisseur à connaître les revendications attendues par Microsoft Entra ID.
La combinaison des valeurs acr et amr est utilisée par Microsoft Entra ID pour valider :
- La méthode d’authentification utilisée pour le deuxième facteur satisfait à l’exigence MFA
- La méthode d’authentification diffère en « type » de la méthode utilisée pour compléter le premier facteur de connexion à Microsoft Entra ID
{
"id_token": {
"acr": {
"essential": true,
"values":["possessionorinherence"]
},
"amr": {
"essential": true,
"values": ["face", "fido", "fpt", "hwk", "iris", "otp", "pop", "retina", "sc", "sms", "swk", "tel", "vbm"]
}
}
}
Revendications Id_token_hint par défaut
Cette section décrit le contenu requis du jeton passé en tant que id_token_hint dans la requête adressée au fournisseur. Le jeton peut contenir plus de revendications que dans le tableau suivant.
| Revendication | Valeur | Description |
|---|---|---|
| iss | Identifie le service d’émission de jeton de sécurité (Security Token Service/STS) qui construit et retourne le jeton, ainsi que le tenant Microsoft Entra ID dans lequel l’utilisateur s’est authentifié. Votre application doit utiliser la partie GUID de la revendication pour restreindre l’ensemble des clients qui peuvent se connecter à l’application, le cas échéant. L’émetteur doit correspondre à l’URL de l’émetteur des métadonnées JSON de découverte OIDC pour le tenant dans lequel l’utilisateur s’est connecté. | |
| aud | L’audience doit être définie sur l’ID client du fournisseur d’identité externe pour Microsoft Entra ID. | |
| exp | L’heure d’expiration est définie pour expirer peu de temps après l’heure d’émission, suffisamment pour éviter les problèmes d’asymétrie du temps. Ce jeton n’étant pas destiné à l’authentification, il n’y a aucune raison pour que sa validité survive longtemps après la requête. | |
| iat | Définir l’heure d’émission comme d’habitude. | |
| tid | L’ID de tenant est destiné à la publicité du tenant auprès du fournisseur. Il représente le tenant Microsoft Entra ID duquel l’utilisateur provient. | |
| oid | Identificateur immuable d’un objet dans la plateforme d’identités Microsoft. Dans ce cas, il s’agit d’un compte d’utilisateur. Il peut également être utilisé pour effectuer des vérifications d’autorisation en toute sécurité et en tant que clé dans les tables de base de données. Cet ID n’identifie que l’utilisateur sur plusieurs applications. Deux applications différentes qui connectent le même utilisateur reçoivent la même valeur dans la revendication oid. Ainsi, l’oid peut être utilisé dans les requêtes aux services en ligne Microsoft, comme Microsoft Graph. | |
| preferred_username | Fournit une valeur contrôlable de visu qui identifie le sujet du jeton. Il n’est pas certain que cette valeur soit unique au sein d’un tenant. Elle ne doit être utilisée qu’à des fins d’affichage. | |
| sub | Identificateur de sujet de l’utilisateur final à l’émetteur. Principal sur lequel portent les assertions d’informations du jeton, comme l’utilisateur d’une application. Cette valeur est immuable et ne peut pas être réattribuée ou réutilisée. Vous pouvez l’utiliser pour effectuer des vérifications d’autorisation en toute sécurité, comme lorsque le jeton est utilisé pour accéder à une ressource et qu’il peut servir de clé dans les tables de base de données. Le sujet étant toujours présent dans les jetons émis par Microsoft Entra ID, nous vous recommandons d’utiliser cette valeur dans un système d’autorisation à usage général. Toutefois, le sujet est un identificateur par paire ; il est unique à un ID d’application spécifique. Par conséquent, si un utilisateur se connecte à deux applications différentes en utilisant deux ID client différents, ces applications reçoivent deux valeurs différentes pour la revendication du sujet. Ceci peut être souhaitable, ou non, en fonction de votre architecture et de vos besoins de confidentialité. Consultez également la revendication oid, qui reste la même sur les applications d’un même tenant. |
Pour empêcher son utilisation pour toute autre chose qu’un conseil, le jeton est émis comme étant expiré. Le jeton est signé et peut être vérifié à l’aide des métadonnées de découverte Microsoft Entra ID publiées.
Revendications facultatives de Microsoft Entra ID
Si un fournisseur a besoin de revendications facultatives de Microsoft Entra ID, vous pouvez configurer ces revendications facultatives pour id_token. Pour plus d’informations, consultez Revendications facultatives.
Utilisation recommandée des revendications
Microsoft recommande d’associer les comptes côté fournisseur au compte dans Azure AD en utilisant les revendications oid et tid. Ces deux revendications sont garanties pour être uniques pour le compte dans le tenant.
Exemple d’un id_token_hint
Voici un exemple d’un id_token_hint pour un membre du répertoire :
{
"typ": "JWT",
"alg": "RS256",
"kid": "C2dE3fH4iJ5kL6mN7oP8qR9sT0uV1w"
}.{
"ver": "2.0",
"iss": "https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0",
"sub": "mBfcvuhSHkDWVgV72x2ruIYdSsPSvcj2R0qfc6mGEAA",
"aud": "00001111-aaaa-2222-bbbb-3333cccc4444",
"exp": 1536093790,
"iat": 1536093791,
"nbf": 1536093791,
"name": "Test User 2",
"preferred_username": "testuser2@contoso.com"
"oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
"tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee"
}.
Voici un exemple du conseil id_token pour un utilisateur invité dans le tenant :
{
"typ": "JWT",
"alg": "RS256",
"kid": "C2dE3fH4iJ5kL6mN7oP8qR9sT0uV1w"
}.{
"ver": "2.0",
"iss": "https://login.microsoftonline.com/9122040d-6c67-4c5b-b112-36a304b66dad/v2.0",
"sub": "mBfcvuhSHkDWVgV72x2ruIYdSsPSvcj2R0qfc6mGEAA",
"aud": "00001111-aaaa-2222-bbbb-3333cccc4444",
"exp": 1536093790,
"iat": 1536093791,
"nbf": 1536093791,
"name": "External Test User (Hotmail)",
"preferred_username": "externaltestuser@hotmail.com",
"oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
"tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee"
}.
Actions suggérées pour les fournisseurs d’identité externes
Nous suggérons que les fournisseurs d’identité externes effectuent ces étapes. La liste n’est pas exhaustive et les fournisseurs doivent effectuer d’autres étapes de validation comme ils le pensent approprié.
- Depuis la requête :
- Vérifiez que le redirect_uri est publié dans l’Appel Microsoft Entra ID au fournisseur d’identité externe.
- Vérifiez que le client_id a une valeur affectée à Microsoft Entra ID, comme ABCD.
- Le fournisseur doit d’abord valider le id_token_hint qui lui est présenté par Microsoft Entra ID.
- Depuis les revendications de id_token_hint :
- Ils peuvent éventuellement effectuer un appel à Microsoft Graph pour récupérer d’autres détails sur cet utilisateur. Les revendications oid et tid dans le id_token_hint sont utiles à cet égard. Pour plus d’informations sur les revendications fournies dans le id_token_hint, consultez Revendications id_token_hint par défaut.
- Effectuez ensuite toute autre activité d’authentification que le produit du fournisseur est conçu pour effectuer.
- En fonction du résultat des actions de l’utilisateur et d’autres facteurs, le fournisseur générera et renverra ensuite une réponse à Microsoft Entra ID, comme expliqué dans la section suivante.
Traitement par Microsoft Entra ID de la réponse du fournisseur
Le fournisseur doit renvoyer une réponse au redirect_uri. Les paramètres suivants doivent être fournis dans une réponse réussie :
| Paramètre | active | Description |
|---|---|---|
| id_token | Jeton émis par le fournisseur d’identité externe. | |
| state | Le même état qui a été transmis dans la requête, le cas échéant. Sinon, cette valeur ne doit pas être présente. |
En cas de réussite, le fournisseur émet alors un id_token pour l’utilisateur. Microsoft Entra ID utilise les métadonnées OIDC publiées pour vérifier que le jeton contient les revendications attendues et effectue toute autre validation du jeton requise par OIDC.
| Revendication | Valeur | Description |
|---|---|---|
| iss | Émetteur : doit correspondre à l’émetteur dans les métadonnées de découverte du fournisseur. | |
| aud | Audience : ID client Microsoft Entra ID. Consultez client_id dans Appel de Microsoft Entra ID au fournisseur d’identité externe. | |
| exp | Délai d’expiration : définir comme d’habitude. | |
| iat | Heure d’émission : définir comme d’habitude. | |
| sub | Sujet : doit correspondre au sujet du id_token_hint envoyé pour lancer cette requête. | |
| nonce | Même nonce que celle passée dans la requête. | |
| acr | Revendications acr pour la requête d’authentification. Cette valeur doit correspondre à l’une des valeurs de la requête envoyée pour lancer cette requête. Une seule revendication acr doit être retournée. Pour obtenir la liste des revendications, consultez Revendications acr prises en charge. | |
| amr | Revendications amr pour la méthode d’authentification utilisée dans l’authentification. Cette valeur doit être retournée sous la forme d’un tableau, et une seule revendication de méthode doit être retournée. Pour obtenir la liste des revendications, consultez Revendications amr prises en charge. |
Revendications acr prises en charge
| Revendication | Notes |
|---|---|
| possessionorinherence | L’authentification doit se produire avec un facteur basé sur la possession ou l’inhérence. |
| knowledgeorpossession | L’authentification doit se produire avec un facteur basé sur la connaissance ou la possession. |
| knowledgeorinherence | L’authentification doit se produire avec un facteur basé sur la connaissance ou l’inhérence. |
| knowledgeorpossessionorinherence | L’authentification doit se produire avec un facteur basé sur la connaissance ou la possession ou l’inhérence. |
| knowledge | L’authentification doit se produire avec un facteur basé sur la connaissance. |
| possession | L’authentification doit se produire avec un facteur basé sur la possession. |
| inherence | L’authentification doit se produire avec un facteur basé sur l’inhérence. |
Revendications amr prises en charge
| Revendication | Notes |
|---|---|
| face | Biométrie avec reconnaissance faciale |
| fido | FIDO2 a été utilisé |
| fpt | Biométrie avec empreinte digitale |
| hwk | Preuve de possession de la clé sécurisée par le matériel |
| iris | Biométrie avec analyse de l’iris |
| otp | Mot de passe à usage unique |
| pop | Preuve de possession |
| retina | Biométrie de l’analyse rétinienne |
| sc | Carte à puce |
| sms | Confirmation par message texte au numéro inscrit |
| swk | Confirmation de la présence d’une clé sécurisée par logiciel |
| tel | Confirmation par téléphone |
| vbm | Biométrie avec empreinte vocale |
Microsoft Entra ID exige que la MFA soit satisfaite pour émettre un jeton avec des revendications MFA. Par conséquent, seules les méthodes avec un type différent peuvent satisfaire la deuxième exigence de facteur. Comme mentionné précédemment, les différents types de méthodes qui peuvent être utilisés pour satisfaire le deuxième facteur sont la connaissance, la possession et l’inhérence.
Microsoft Entra ID valide le mappage de type en fonction du tableau suivant.
| Méthode Claim | Type | Notes |
|---|---|---|
| face | Inhérence | Biométrie avec reconnaissance faciale |
| fido | Possession | FIDO2 a été utilisé. Certaines implémentations peuvent également nécessiter la biométrie, mais le type de méthode de possession est mappé, car il s’agit de l’attribut de sécurité principal. |
| fpt | Inhérence | Biométrie avec empreinte digitale |
| hwk | Possession | Preuve de possession de la clé sécurisée par le matériel |
| iris | Inhérence | Biométrie avec analyse de l’iris |
| otp | Possession | Mot de passe à usage unique |
| pop | Possession | Preuve de possession |
| retina | Inhérence | Biométrie de l’analyse rétinienne |
| sc | Possession | Carte à puce |
| sms | Possession | Confirmation par message texte au numéro inscrit |
| swk | Possession | Preuve de présence d’une clé sécurisée par logiciel |
| tel | Possession | Confirmation par téléphone |
| vbm | Inhérence | Biométrie avec empreinte vocale |
Si aucun problème n’est trouvé avec le jeton, Microsoft Entra ID considère que la MFA est satisfaite et émet un jeton à l’utilisateur final. Sinon, la requête de l’utilisateur final échoue.
L’échec est indiqué par l’émission de paramètres de réponse d’erreur.
| Paramètre | active | Description |
|---|---|---|
| Error | Code d’erreur ASCII, comme access_denied ou temporarily_unavailable. |
Microsoft Entra ID considère que la requête réussit si le paramètre id_token est présent dans la réponse et si le jeton est valide. Sinon, la requête est considérée comme ayant échoué. Microsoft Entra ID échoue à la tentative d’authentification originale en raison de l’exigence de la stratégie d’accès conditionnel.
Microsoft Entra ID abandonne l’état de la tentative d’authentification de son côté environ 10 minutes après la redirection vers le fournisseur.
Gestion des réponses aux erreurs Microsoft Entra ID
Les services Microsoft Azure utilisent un correlationId pour mettre en corrélation les appels entre différents systèmes internes et externes. Il sert d’identificateur commun de l’ensemble de l’opération ou du flux qui implique potentiellement plusieurs appels HTTP. Lorsqu’une erreur se produit pendant l’une des opérations, la réponse contient un champ nommé ID de corrélation.
Lorsque vous contactez le support Microsoft ou un service similaire, fournissez la valeur de cet ID de corrélation, car il permet d’accéder plus rapidement aux données de télémétrie et aux journaux.
Par exemple :
ENTRA IDSTS70002 : erreur de validation des informations d’identification. ENTRA IDSTS50012 : le jeton d’ID externe de l’émetteur https://sts.XXXXXXXXX.com/auth/realms/XXXXXXXXXmfa a échoué à la vérification de la signature. KeyID du jeton est « A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u » ID de trace : 0000aaaa-11bb-cccc-dd22-eeeeee333333 ID de corrélation : aaaa0000-bb11-2222-33cc-444444dddddd Timestamp : 2023-07-24 16:51:34Z
Contrôles personnalisés et EAM
Dans Microsoft Entra ID, les EAM et les contrôles personnalisés d’accès conditionnel peuvent fonctionner en parallèle pendant que les clients se préparent et migrent vers les EAM.
Les clients qui utilisent actuellement une intégration à un fournisseur externe à l’aide de contrôles personnalisés peuvent continuer à les utiliser, de même que toutes les stratégies d’accès conditionnel qu’ils ont configurées pour gérer l’accès. Il est recommandé que les administrateurs créent un ensemble parallèle de stratégies d’accès conditionnel pendant la période de migration :
Les stratégies doivent utiliser le contrôle d’octroi Exiger l’authentification multifacteur au lieu de l’octroi de contrôle personnalisé.
Remarque
Les contrôles d’octroi basés sur les forces d’authentification, y compris la force MFA intégrée, ne sont pas satisfaits par l’EAM. Les stratégies ne doivent être configurées qu’avec Exiger l’authentification multifacteur. Nous travaillons activement à prendre en charge les EAM avec les forces d’authentification.
La nouvelle stratégie peut d’abord être testée avec un sous-ensemble d’utilisateurs. Le groupe de test est exclu de la stratégie qui requiert les contrôles personnalisés, et inclus dans la stratégie qui requiert la MFA. Une fois que l’administrateur a la certitude que la stratégie qui requiert la MFA est satisfaite par l’EAM, il peut inclure tous les utilisateurs requis dans la stratégie avec l’octroi MFA, et la stratégie configurée pour les contrôles personnalisés peut être passée sur Off (Désactivée).
Prise en charge de l’intégration
Si vous rencontrez des problèmes lors de la génération de l’intégration EAM à Microsoft Entra ID, l’éditeur de solutions indépendantes (Independent Solution Vendor/ISV) Microsoft Customer Experience Engineering (CxE) peut être en mesure d’aider. Pour contacter l’équipe ISV CxE, envoyez une demande d’assistance.
Références
Glossaire
| Terme | Description |
|---|---|
| MFA | Authentification multifacteur. |
| EAM | Une méthode d’authentification externe est une méthode d’authentification d’un fournisseur autre que Microsoft Entra ID utilisée dans le cadre de l’authentification d’un utilisateur. |
| OIDC | Open ID Connect est un protocole d’authentification basé sur OAuth 2.0. |
| 00001111-aaaa-2222-bbbb-3333cccc4444 | Exemple d’appid intégré pour une méthode d’authentification externe. |
Étapes suivantes
Pour plus d’informations sur la configuration d’une EAM dans le Centre d’administration Microsoft Entra, consultez Gérer une méthode d’authentification externe dans Microsoft (préversion).