Partage via

Déclencher des applications logiques (Logic Apps) avec des extensions personnalisées dans la gestion des droits d’utilisation

  • Article

Azure Logic Apps permet d’automatiser des flux de travail personnalisés, ainsi que de connecter des applications et des services dans un même emplacement. Les utilisateurs peuvent intégrer des applications logiques avec la gestion des droits d’utilisation pour élargir leurs flux de travail de gouvernance au-delà des cas d’utilisation de base de la gestion des droits d’utilisation.

Ces applications logiques peuvent ensuite être déclenchées pour s’exécuter conformément aux cas d’utilisation de la gestion des droits d’utilisation, par exemple, quand un package d’accès est octroyé ou demandé. Par exemple, un administrateur peut créer, puis lier une application logique personnalisée à la gestion des droits d’utilisation. Ainsi, quand un utilisateur demande un package d’accès, une application logique est déclenchée. Cette application veille à ce que l’utilisateur se voie également attribuer certaines caractéristiques dans une application SaaS tierce (telle que Salesforce) ou reçoive un e-mail personnalisé.

Les cas d’usage de la gestion des droits d’utilisation qui peuvent être intégrés avec Logic Apps incluent les étapes suivantes. Ce sont les déclencheurs associés à un package d’accès qui peuvent lancer l’application logique d’extension personnalisée :

  • Quand une requête de package d’accès est créée

  • Quand une requête de package d’accès est approuvée

  • Quand une affectation de package d’accès est octroyée

  • Quand une affectation de package d’accès est supprimée

  • 14 jours avant l’expiration automatique d’une affectation de package d’accès

  • Un jour avant l’expiration automatique d’une affectation de package d’accès

Ces déclencheurs pour Logic Apps sont contrôlés dans un nouvel onglet au sein de stratégies de package d’accès nommées règles. En outre, un onglet Extensions personnalisées dans la page Catalogue affiche toutes les extensions Logic Apps d’un catalogue donné. Cet article explique comment créer et ajouter des applications logiques à des catalogues et packages d’accès dans la gestion des droits d’utilisation.

Conditions de licence :

L’utilisation de cette fonctionnalité nécessite des licences Gouvernance Microsoft Entra ID ou Suite Microsoft Entra. Pour trouver la licence adaptée à vos besoins, consultez Notions de base sur les licences Gouvernances des ID Microsoft Entra.

Créer, puis ajouter un workflow d’application logique à un catalogue pour utilisation dans la gestion des droits d’utilisation

Conseil

Les étapes décrites dans cet article peuvent varier légèrement en fonction du portail de départ.

  1. Connectez-vous au Centre d’administration Microsoft Entra en tant qu’Administrateur de la gouvernance des identités.

    Conseil

    D’autres rôles de privilège minimum pouvant effectuer cette tâche incluent le Propriétaire du catalogue et le Propriétaire du groupe de ressources.

  2. Accédez à Gouvernance des identités>Catalogues.

  3. Sélectionnez le catalogue pour lequel vous souhaitez ajouter une extension personnalisée puis, dans le menu de gauche, sélectionnez Extensions personnalisées.

  4. Dans la barre de navigation de l’en-tête, sélectionnez Ajouter une extension personnalisée.

  5. Sous l’onglet De base, entrez le nom de l’extension personnalisée, normalement le nom de l’application logique que vous liez, puis une description du workflow. Ces champs s’affichent sous l’onglet Extensions personnalisées du catalogue.

    Volet pour créer une extension personnalisée

  6. L’onglet Type d’extension définit le type de stratégies de package d’accès avec lequel vous pouvez utiliser l’extension personnalisée. Le type « Flux de travail de requête » prend en charge les étapes de stratégie : le package d’accès demandé est créé, quand la requête est approuvée, quand l’affectation est octroyée, puis quand l’affectation est supprimée. Ce type prend également en charge les fonctionnalités Lancer, puis attendre.

  7. Le workflow de pré-expiration prend en charge les étapes de stratégie : 14 jours avant l’expiration de l’affectation du package d’accès et 1 jour jusqu’à l’expiration de l’affectation du package d’accès. Ce type d’extension ne prend pas en charge la fonction Lancer, puis attendre.

    Capture d’écran des options de configuration de la fonction Lancer, puis attendre.

  8. L’onglet Configuration de l’extension vous permet de déterminer si votre extension a le comportement « lancer, puis continuer » ou « lancer, puis attendre ». Avec « Lancer, puis continuer », l’action de stratégie liée sur le package d’accès, telle qu’une requête, déclenche l’application logique attachée à l’extension personnalisée. Une fois l’application logique déclenchée, le processus de gestion des droits d’utilisation associé au package d’accès continue. Pour « Lancer, puis attendre », nous allons suspendre l’action de package d’accès associée jusqu’à ce que l’application logique liée à l’extension termine sa tâche et que l’administrateur envoie une action de reprise pour continuer le processus. Si aucune réponse n’est renvoyée pendant la période d’attente définie, ce processus est considéré comme une défaillance. Ce processus est décrit de manière plus détaillée dans sa propre section Configuration d’extensions personnalisées qui suspendent les processus de gestion des droits d’utilisation.

  9. Sous l’onglet Détails, indiquez si vous voulez utiliser une application logique de plan de consommation existant. Le fait de sélectionner Oui dans le champ « Créer une application logique » (par défaut) crée une application logique de plan de consommation qui est déjà liée à cette extension personnalisée. Quoi qu’il en soit, vous devez fournir :

    1. Un abonnement Azure.

    2. Un groupe de ressources qui dispose des autorisations de création de ressources d’application logique si vous créez une application logique.

    3. Sélectionnez « Créer une application logique » si vous utilisez ce paramètre.

      Capture d’écran de sélections de détails de la création d’application logique.

    Notes

    Lors de la création d’une application logique dans ce mode, la longueur de « /subscriptions/{SubscriptionId}/resourceGroups/{RG Name}/providers/Microsoft.Logic/workflows/{Nom de l’application logique} » ne peut pas dépasser 150 caractères.

  10. Dans Examiner et créer, examinez le résumé de votre extension personnalisée, puis vérifiez que les détails de la légende de votre application logique sont corrects. Sélectionnez ensuite Créer.

  11. Cette extension personnalisée de l’application logique liée apparaît maintenant sous l’onglet Extensions personnalisées dans Catalogues. Vous pouvez l’appeler cette extension personnalisée dans des stratégies de package d’accès.

Afficher, puis modifier des extensions personnalisées existantes pour un catalogue

  1. Accédez à l’onglet Extensions personnalisées dans un catalogue, comme indiqué précédemment, au minimum en tant qu’Administrateur de la gouvernance des identités.

    Conseil

    D’autres rôles de privilège minimum pouvant effectuer cette tâche incluent le Propriétaire du catalogue.

  2. Ici, vous pouvez afficher toutes les extensions personnalisées que vous avez créées, ainsi que l’application logique associée et des informations sur le type d’extension personnalisée. Capture d’écran d’une liste d’extensions personnalisées.

  3. Avec le nom de l’application logique, le type de colonne détermine si l’extension personnalisée a été créée dans le nouveau modèle d’authentification V2 (après le 17 mars 2023) ou dans le modèle d’origine. Si une extension personnalisée a été créée dans le nouveau modèle, la colonne Type correspond au type sélectionné du modal de configuration qui est « requête d’affectation » ou « pré-expiration ». Pour les extensions personnalisées plus anciennes, le type affiche « package d’accès personnalisé ».

  4. La colonne Sécurité des jetons affiche l’infrastructure de sécurité d’authentification associée utilisée lors de la création de l’extension personnalisée. Les nouvelles extensions personnalisées V2 affichent « preuve de possession » (PoP) comme type de sécurité de jeton. Les extensions personnalisées plus anciennes affichent « normal ».

  5. Les extensions personnalisées de l’ancien style ne peuvent plus être créées depuis l’interface utilisateur. Cependant, les extensions existantes peuvent être converties en extensions personnalisées de nouveau style depuis l’interface utilisateur. Capture d’écran de la conversion de l’ancien jeton de sécurité en nouveau.

  6. La sélection des trois points à la fin de la ligne d’une ancienne extension personnalisée vous permet de mettre à jour rapidement l’extension personnalisée vers un nouveau type.

    Notes

    Les extensions personnalisées ne peuvent être converties en nouveau type que si elles ne sont pas en cours d’utilisation ou si elles sont utilisées exclusivement pour les étapes de stratégie d’un type d’extension spécifique (étapes de requête d’affectation ou étapes préalables à l’expiration).

  7. Vous pouvez également modifier n’importe quelle extension personnalisée. Cela vous permet de mettre à jour le nom, la description et d’autres valeurs de champ. Pour ce faire, vous pouvez sélectionner Modifier dans le volet à trois points pour toute extension personnalisée.

  8. Les extensions personnalisées de l’ancien style peuvent continuer à être utilisées et modifiées même si elles ne sont pas converties, bien qu’elles ne puissent plus être créées.

  9. Si une extension personnalisée d’un ancien style ne peut pas être mise à jour vers le nouveau type, car elle est utilisée pour les étapes de stratégie, À LA FOIS des types de requête d’affectation et de pré-expiration, vous devez, pour la mettre à jour, la supprimer de toutes les stratégies liées ou vérifier qu’elle n’est utilisée que pour les étapes de stratégie associées à UN SEUL type (demande d’affectation ou de pré-expiration).  

Ajouter une extension personnalisée à une stratégie dans un package d’accès

  1. Connectez-vous au Centre d’administration Microsoft Entra en tant qu’Administrateur de la gouvernance des identités.

    Conseil

    D’autres rôles de privilège minimum pouvant effectuer cette tâche incluent le Propriétaire du catalogue et le Gestionnaire de package d’accès.

  2. Accédez à Gouvernance des identités>Gestion des droits d’utilisation>Packages d’accès.

  3. Sélectionnez le package d’accès auquel vous souhaitez ajouter une extension personnalisée (application logique) dans la liste des packages d’accès qui ont déjà été créés.

    Notes

    Sélectionnez Nouveau package d’accès si vous souhaitez créer un package d’accès. Si vous souhaitez en savoir plus sur la création d’un package d’accès, veuillez consulter la rubrique Créer un package d’accès dans la gestion des droits d’utilisation. Pour plus d’informations sur la modification d’un package d’accès existant, consultez Modifier les paramètres de requête d’un package d’accès dans la fonctionnalité de gestion des droits d’utilisation Microsoft Entra.

  4. Accédez à l’onglet Stratégie, sélectionnez la stratégie, puis sélectionnez Modifier.

  5. Dans les paramètres de stratégie, accédez à l’onglet Extensions personnalisées.

  6. Dans le menu Index ci-dessous, sélectionnez l’événement de package d’accès que vous souhaitez utiliser comme déclencheur pour cette extension personnalisée (application logique). Par exemple, si vous souhaitez déclencher le flux de travail de l’application logique d’extension personnalisée uniquement quand un utilisateur demande le package d’accès, sélectionnez La demande est créée.

  7. Dans le menu Extension personnalisée ci-dessous, sélectionnez l’extension personnalisée (application logique) que vous souhaitez ajouter au package d’accès. L’action que vous sélectionnez s’exécute quand l’événement sélectionné dans le champ quand se produit.

  8. Sélectionnez Mettre à jour pour l’ajouter à une stratégie du package d’accès existant.

    Ajouter une application logique à un package d’accès

Modifier une définition de workflow de l’application logique liée

Pour les applications logiques (Logic Apps) récemment créées liées à des extensions personnalisées, ces applications logiques commencent vides. Pour créer les workflows dans les applications logiques (Logic Apps) qui seront déclenchées par l’extension lorsque la condition de stratégie du package d’accès lié sera déclenchée, vous devez modifier la définition du workflow d’application logique dans le concepteur d’application logique. Pour ce faire, procédez comme suit :

  1. Accédez à l’onglet Extensions personnalisées dans un catalogue, comme indiqué précédemment, au minimum en tant qu’Administrateur de la gouvernance des identités.

    Conseil

    D’autres rôles de privilège minimum pouvant effectuer cette tâche incluent le Propriétaire du catalogue.

  2. Sélectionnez l’extension personnalisée dont vous souhaitez modifier l’application logique.

  3. Sélectionnez l’application logique sous la colonne Application logique de la ligne d’extension personnalisée associée. Cela vous permet de modifier ou de créer le workflow dans le concepteur d’application logique.

Pour plus d’informations sur la création de workflows d’application logique, consultez Démarrage rapide : créer un exemple de workflow de consommation dans Azure Logic Apps multi-locataire.

Configuration d’extensions personnalisées qui suspendent les processus de gestion des droits d’utilisation

Une nouvelle mise à jour de la fonctionnalité d’extensions personnalisées permet de suspendre le processus de stratégie de package d’accès associé à une extension personnalisée jusqu’à ce que l’application logique se termine, puis qu’une charge utile de requête de reprise soit renvoyée à la gestion des droits d’utilisation. Par exemple, si une extension personnalisée pour une application logique est déclenchée depuis une stratégie d’octroi de package d’accès et que la fonction « Lancer, puis attendre » est activée, une fois l’application logique déclenchée, le processus d’octroi ne reprendra qu’une fois l’application logique terminée, puis une requête de reprise renvoyée à la gestion des droits d’utilisation.

Ce processus de pause permet aux administrateurs de contrôler les workflows qu’ils souhaitent exécuter avant de poursuivre les tâches de cycle de vie d’accès dans la gestion des droits d’utilisation. Le dépassement du délai d’expiration constitue la seule exception à ce principe. Les processus de lancement et d’attente nécessitent un délai d’expiration allant jusqu’à 14 jours, noté en minutes, heures ou jours. Si aucune réponse à une requête de reprise n’est renvoyée à la gestion des droits d’utilisation avant la fin du délai « d’expiration », le processus de flux de requête de gestion des droits d’utilisation s’interrompt.

L’administrateur est responsable de la configuration d’un processus automatisé capable de renvoyer la charge utile requête de reprise d’API à la gestion des droits d’utilisation, une fois le workflow Logic App terminé. Pour renvoyer la charge utile de requête de reprise, suivez les instructions fournies ici dans les documents de l’API graphique. Pour plus d’informations, consultez demande de reprise.

Plus précisément, lorsqu’une stratégie de package d’accès est activée pour appeler une extension personnalisée et que le traitement de la requête attend le rappel du client, le client peut lancer une action de reprise. Cette action s’effectue sur un objet accessPackageAssignmentRequest dont le paramètre requestStatus est à l’état WaitingForCallback.

La requête de reprise peut être renvoyée pour les étapes suivantes :

microsoft.graph.accessPackageCustomExtensionStage.assignmentRequestCreated
microsoft.graph.accessPackageCustomExtensionStage.assignmentRequestApproved
microsoft.graph.accessPackageCustomExtensionStage.assignmentRequestGranted
microsoft.graph.accessPackageCustomExtensionStage.assignmentRequestRemoved

Le diagramme de flux suivant montre l’appel de la gestion des droits d’utilisation au workflow Logic Apps : Diagramme de l’appel de la gestion des droits d’utilisation au workflow Logic Apps.

Le diagramme de flux montre ceci :

  1. L’utilisateur crée un point de terminaison personnalisé capable de recevoir l’appel du service d’identité
  2. Le service d’identité effectue un appel de test pour vérifier que le point de terminaison peut être appelé par le service d’identité
  3. L’utilisateur appelle l’API Graph pour demander l’ajout d’un utilisateur à un package d’accès
  4. Le service d’identité est ajouté à la file d’attente déclenchant le workflow back-end
  5. Le traitement des demandes du service de gestion des droits d’utilisation appelle l’application logique avec la charge utile de la demande
  6. Le flux de travail attend le code accepté
  7. Le service de gestion des droits d’utilisation attend la reprise de l’action personnalisée bloquante
  8. Le système du client appelle l’API de reprise de demande au service d’identité pour reprendre le traitement de la demande
  9. Le service d’identité ajoute le message de demande de reprise à la file d’attente du service de gestion des droits d’utilisation qui reprend le flux de travail back-end
  10. Le service de gestion des droits d’utilisation reprend à partir de l’état bloqué

Voici un exemple de charge utile de requête de reprise :

POST https://graph.microsoft.com/beta/identityGovernance/entitlementManagement/accessPackageAssignmentRequests/00aa00aa-bb11-cc22-dd33-44ee44ee44ee/resume

Content-Type: application/json

{
  "source": "Contoso.SodCheckProcess",
  "type": "microsoft.graph.accessPackageCustomExtensionStage.assignmentRequestCreated",
  "data": {
    "@odata.type": "microsoft.graph.accessPackageAssignmentRequestCallbackData",
    "stage": "assignmentRequestCreated",
    "customExtensionStageInstanceId": "957d0c50-466b-4840-bb5b-c92cea7141ff",
    "customExtensionStageInstanceDetail": "This user is all verified"
  }
}

Avec la fonction Lancer, puis attendre, les administrateurs peuvent également refuser une requête si l’extension est liée aux étapes du package d’accès « la requête est créée » ou « la requête est approuvée ». Dans ce cas, l’application logique peut renvoyer un message « refuser » à la gestion des droits d’utilisation, ce qui mettrait fin au processus avant que l’utilisateur final reçoive le package d’accès.

Comme mentionné, vous pouvez activer les extensions personnalisées créées avec le type de workflow de requête, qui comprend quatre étapes de stratégie associées, avec « Lancer, puis attendre » si vous le souhaitez.

Voici un exemple de reprise du traitement d’une requête d’affectation de package d’accès par refus de la requête en attente d’un rappel. Une requête ne peut pas être refusée à l’étape assignmentRequestCreated de la légende.

POST https://graph.microsoft.com/beta/identityGovernance/entitlementManagement/accessPackageAssignmentRequests/9e60f18c-b2a0-4887-9da8-da2e30a39d99/resume

Content-Type: application/json

{
  "source": "Contoso.SodCheckProcess",
  "type": "microsoft.graph.accessPackageCustomExtensionStage.assignmentRequestCreated",
  "data": {
    "@odata.type": "microsoft.graph.accessPackageAssignmentRequestCallbackData",
    "stage": "AssignmentRequestCreated",
    "customExtensionStageInstanceId": "857d0c50-466b-4840-bb5b-c92cea7141ff",
    "state": "denied",
    "customExtensionStageInstanceDetail": "Potential risk user based on the SOD check"
  }
}

Expérience d’extension de l’utilisateur final

Expérience de l’approbateur

Un approbateur voit la chaîne spécifiée dans la charge utile de la requête de reprise sous customExtensionStageInstanceDetail comme indiqué dans la charge utile située dans extensions personnalisées de configuration qui interrompent les processus de gestion des droits d’utilisation. Capture d’écran de l’écran de l’approbateur.

Expérience du demandeur

Lorsqu’un package d’accès dispose d’une extension personnalisée avec des fonctionnalités de lancement et d’attente, et que l’application logique est déclenchée lors de la création de la requête de package d’accès, les demandeurs peuvent voir l’état de leur demande dans l’historique des requêtes de MyAccess.

Les mises à jour d’état suivantes s’affichent aux utilisateurs en fonction de leur phase d’extension personnalisée :

Étape de l’extension personnalisée Message affiché au demandeur dans l’historique des requêtes MyAccess
Lorsque l’extension est en cours de traitement Attendre des informations avant de continuer
En cas d’échec de l’extension Le processus a expiré
Quand l’extension reprend Le processus continue

Il s’agit d’un exemple d’historique des requêtes MyAccess d’un demandeur après la reprise de l’extension :

Capture d’écran de l’écran du demandeur.

Résolution des problèmes et validation

Pour les extensions personnalisées associées à une requête, vous pouvez afficher les détails du processus d’extension personnalisée (et lancer, puis attendre si cette fonction est activée) depuis le lien de détails de l’historique des requêtes dans la page détails des affichages du package d’accès associé.

Capture d’écran de l’historique des requêtes pour une extension de tâche personnalisée.Capture d’écran des détails de sélection pour une extension de tâche personnalisée.

Par exemple, ici, vous pouvez voir l’heure à laquelle la requête a été envoyée et l’heure à laquelle le processus de lancement et d’attente (en attente de rappel) a commencé. La requête a été approuvée et l’étape de gestion des droits d’utilisation a « repris », une fois l’application logique exécutée, puis la requête de reprise d’activité retournée à 12 h 15.

En outre, un nouveau lien d’instances d’extension personnalisée dans les détails de la demande affiche des informations sur l’extension personnalisée associée au package d’accès pour la requête.
Capture d’écran des éléments de liste des détails de sélection.

Cet écran affiche l’ID d’extension personnalisé et l’état. Ces informations changent en fonction de la présence ou non d’un rappel de lancement et d’attente associé.

Pour vérifier que votre extension personnalisée a correctement déclenché l’application logique associée, vous pouvez également afficher les journaux d’activité de l’application logique, qui comportent un horodatage de la dernière exécution de l’application logique.

Étapes suivantes