Partager via

Vue d’ensemble des extensions d'authentification personnalisées

Le pipeline d’authentification Microsoft Entra ID se compose de plusieurs événements d’authentification intégrés, comme la validation des informations d’identification de l’utilisateur, les stratégies d’accès conditionnel, l’authentification multifacteur, la réinitialisation de mot de passe en libre-service, etc.

Les extensions d’authentification personnalisées Microsoft Entra vous permettent d’étendre les flux d’authentification avec votre propre logique métier à des points spécifiques au sein du flux d’authentification. Une extension d’authentification personnalisée est essentiellement un détecteur d’événements qui, une fois activé, effectue un appel HTTP à un point de terminaison d’API REST, où vous définissez une action de workflow.

Par exemple, vous pouvez utiliser un fournisseur de revendications personnalisé pour ajouter des données utilisateur externes au jeton de sécurité avant l’émission du jeton. Vous pouvez ajouter un workflow de collecte d’attributs pour valider les attributs qu’un utilisateur entre lors de l’inscription. Cet article fournit une vue d’ensemble technique générale des extensions d’authentification personnalisées Microsoft Entra ID.

La vidéo Vue d’ensemble de l’extension d’authentification personnalisée Microsoft Entra fournit un aperçu complet des principales fonctionnalités et fonctionnalités des extensions d’authentification personnalisées.

Vue d’ensemble des composants

Vous devez configurer deux composants : une extension d’authentification personnalisée dans Microsoft Entra et une API REST. L’extension d’authentification personnalisée spécifie votre point de terminaison d’API REST, le moment auquel l’API REST doit être appelée et les informations d’identification utilisées pour appeler l’API REST.

Cette vidéo fournit des instructions détaillées sur la configuration des extensions d’authentification personnalisées Microsoft Entra et propose des bonnes pratiques et des conseils précieux pour une implémentation optimale.

Flux de connexion

Le diagramme suivant illustre le flux de connexion intégré à une extension d'authentification personnalisée.

Diagramme montrant un jeton en cours d’augmentation avec des revendications provenant d’une source externe.

  1. Un utilisateur tente de se connecter à une application et est redirigé vers la page de connexion Microsoft Entra.
  2. Une fois qu’un utilisateur a effectué une certaine étape de l’authentification, un écouteur d’événement est déclenché.
  3. Votre extension d'authentification personnalisée envoie une requête HTTP à votre point de terminaison d'API REST. La demande contient des informations sur l’événement, le profil utilisateur, les données de session et d’autres informations de contexte.
  4. L’API REST effectue un workflow personnalisé.
  5. L’API REST renvoie une réponse HTTP à Microsoft Entra ID.
  6. L’extension d’authentification personnalisée Microsoft Entra traite la réponse et personnalise l’authentification en fonction du type d’événement et de la charge utile de réponse HTTP.
  7. Un jeton est retourné à l’application.

Points de terminaison d’API REST

Lorsqu’un événement est déclenché, l’ID Microsoft Entra appelle un point de terminaison d’API REST que vous possédez. L’API REST doit être accessible publiquement. Il peut être hébergé à l’aide d’Azure Functions, d’Azure App Service, d’Azure Logic Apps ou d’un autre point de terminaison d’API disponible publiquement.

Vous avez la possibilité d’utiliser n’importe quel langage de programmation, infrastructure ou solution sans code faible, comme Azure Logic Apps pour développer et déployer votre API REST. Pour un moyen rapide de commencer, envisagez d’utiliser Azure Function. Il vous permet d’exécuter votre code dans un environnement serverless sans avoir à créer d’abord une machine virtuelle ou à publier une application web.

Votre API REST doit gérer :

Regardez cette vidéo pour découvrir comment créer un point de terminaison d’API REST d’extensions d’authentification avec Azure Logic Apps, sans écrire de code. Azure Logic App permet aux utilisateurs de créer des flux de travail à l’aide d’un concepteur visuel. La vidéo couvre la personnalisation des e-mails de vérification et s’applique à tous les types d’extensions d’authentification personnalisées, y compris les fournisseurs de revendications personnalisées.

Charge utile de demande

La requête adressée à l’API REST inclut une charge utile JSON contenant des détails sur l’événement, le profil utilisateur, les données de demande d’authentification et d’autres informations de contexte. Les attributs de la charge utile JSON peuvent être utilisés pour effectuer une logique par votre API.

Par exemple, dans l’événement de démarrage de l’émission de jeton , la charge utile de la demande peut inclure l’identificateur unique de l’utilisateur, ce qui vous permet de récupérer le profil utilisateur à partir de votre propre base de données. Les données de charge utile de la demande doivent suivre le schéma tel que spécifié dans le document d’événements.

Retourner des données et un type d’action

Une fois que votre API web a effectué le flux de travail avec votre logique métier, il doit retourner un type d’action qui dirige Microsoft Entra sur la façon de procéder au processus d’authentification.

Par exemple, dans le cas des événements de début de la collecte d’attributs et de soumission de la collecte d’attributs, le type d’action retourné par votre API web indique si le compte peut être créé dans l'annuaire, s'il doit afficher une erreur de validation, ou s'il faut bloquer complètement le flux d’inscription.

La réponse de l’API REST peut inclure des données. Par exemple, l’événement de démarrage d’émission de jeton peut fournir un ensemble d’attributs qui peuvent être mappés au jeton de sécurité.

Protéger votre API REST

Pour garantir que les communications entre l’extension d'authentification personnalisée et votre API REST sont correctement sécurisées, plusieurs contrôles de sécurité doivent être appliqués.

  1. Lorsque l’extension d'authentification personnalisée appelle votre API REST, elle envoie un en-tête HTTP Authorization avec un jeton du porteur émis par Microsoft Entra ID.
  2. Le jeton du porteur contient une revendication appid ou azp. Vérifiez que la revendication respective contient la valeur 99045fe1-7639-4a75-9d4a-577b6ca3810f. Cette valeur garantit que l'ID Microsoft Entra appelle l'API REST.
    1. Pour les applications V1, validez la revendication appid.
    2. Pour les applications V2, validez la revendication azp.
  3. La revendication d’audience du jeton du porteur aud contient l’ID de l’inscription de l’application associée. Votre point de terminaison d’API REST doit vérifier que le jeton du porteur est émis pour ce public spécifique.
  4. La revendication de l’émetteur iss du jeton du porteur contient l’URL de l’émetteur Microsoft Entra. Selon la configuration de votre locataire, l’URL de l’émetteur est l’une des suivantes :
    • Main-d’œuvre : https://login.microsoftonline.com/{tenantId}/v2.0.
    • Client : https://{domainName}.ciamlogin.com/{tenantId}/v2.0.

Types d’événements d’authentification personnalisés

Cette section répertorie les événements d'extensions personnalisées d'authentification disponibles dans les environnements de travail de Microsoft Entra ID et les locataires externes. Pour plus d’informations sur les événements, reportez-vous à la documentation correspondante.

Événement Locataire de main-d’œuvre Locataire externe
Démarrage de l’émission de jeton
Début de la collection d’attributs
Envoi de la collection d’attributs
Envoi d’un code secret à usage unique

Démarrage de l’émission de jeton

L’événement de démarrage d’émission de jeton, OnTokenIssuanceStart est déclenché lorsqu’un jeton est sur le point d’être émis à une application. Il s’agit d’un type d’événement configuré au sein d’un fournisseur de revendications personnalisé. Le fournisseur de revendications personnalisées est une extension d’authentification personnalisée qui appelle une API REST pour extraire des revendications à partir de systèmes externes. Un fournisseur de revendications personnalisé mappe les revendications provenant de systèmes externes en jetons et peut être attribué à une ou plusieurs applications de votre répertoire.

Début de la collecte d’attributs

Les événements de démarrage de collection d’attributs peuvent être utilisés avec des extensions d’authentification personnalisées pour ajouter une logique avant que les attributs ne soient collectés auprès d’un utilisateur. L'événement OnAttributeCollectionStart se produit au début de l'étape de collecte des attributs, avant le rendu de la page de collecte des attributs. Il vous permet d'ajouter des actions telles que le préremplissage des valeurs et l'affichage des erreurs bloquantes.

Envoi de la collection d’attributs

Les événements d’envoi de collection d’attributs peuvent être utilisés avec des extensions d’authentification personnalisées pour ajouter une logique une fois les attributs collectés auprès d’un utilisateur. L'événement OnAttributeCollectionSubmit se déclenche une fois que l'utilisateur a saisi et envoyé des attributs, vous permettant d'ajouter des actions telles que la validation d'entrées ou la modification d'attributs.

Envoi d’un code secret à usage unique

L’événement OnOtpSend est déclenché lorsqu’un e-mail de code secret à usage unique est activé. Il vous permet d’appeler une API REST pour utiliser votre propre fournisseur de messagerie. Cet événement peut être utilisé pour envoyer des e-mails personnalisés aux utilisateurs qui s’inscrivent avec l’adresse e-mail, se connecter avec un code secret à usage unique (E-mail OTP), réinitialiser leur mot de passe à l’aide d’E-mail OTP ou utiliser e-mail OTP pour l’authentification multifacteur (MFA).

Lorsque l’événement OnOtpSend est activé, Microsoft Entra envoie un mot de passe à usage unique à l’API REST spécifiée. L’API REST utilise ensuite votre fournisseur de messagerie choisi, tel qu’Azure Communication Service ou SendGrid, pour envoyer le code secret unique avec votre modèle de messagerie personnalisé, à partir de l’adresse et de l’objet de messagerie, tout en prenant en charge la localisation.

Contenu connexe

  • Last updated on