Gérer les stratégies de consentement des applications

  • Article

Les stratégies de consentement des applications permettent de gérer les autorisations dont disposent les applications pour accéder aux données de votre organisation. Elles sont utilisées pour contrôler les applications auxquelles les utilisateurs peuvent consentir et pour s’assurer que les applications répondent à certains critères avant de pouvoir accéder aux données. Ces stratégies aident les organisations à garder le contrôle sur leurs données et à s’assurer qu’elles accordent l’accès uniquement aux applications de confiance.

Dans cet article, vous apprendrez à gérer les stratégies de consentement des applications intégrées et personnalisées pour contrôler le moment où le consentement peut être accordé.

Avec Microsoft Graph et Microsoft Graph PowerShell, vous pouvez afficher et gérer les stratégies de consentement d’application.

Une stratégie de consentement d’application se compose d’un ou plusieurs ensembles de conditions d’inclusion et de zéro ou plusieurs ensembles de conditions d’exclusion. Pour qu’un événement soit pris en compte dans une stratégie de consentement d’application, il doit correspondre à au moins un ensemble de conditions d’inclusion et ne doit pas correspondre à un ensemble de conditions d’exclusion.

Chaque ensemble de conditions est constitué de plusieurs conditions. Pour qu’un événement corresponde à un ensemble de conditions, toutes les conditions de l’ensemble de conditions doivent être remplies.

Les stratégies de consentement d’application dont l’ID commence par « Microsoft- » sont des stratégies intégrées. Certaines de ces stratégies intégrées sont utilisées dans les rôles d’annuaire intégrés existants. Par exemple, la stratégie de consentement d’application microsoft-application-admin décrit les conditions dans lesquelles les rôles administrateur d’application et administrateur d’application cloud sont autorisés à accorder le consentement administrateur au niveau du locataire. Les stratégies intégrées peuvent être utilisées dans des rôles d’annuaire personnalisés et pour configurer les paramètres de consentement de l’utilisateur, mais elles ne peuvent pas être modifiées ou supprimées.

Prérequis

  • Un utilisateur ou un service avec l’un des rôles suivants :

Pour gérer les stratégies de consentement des applications pour les applications avec Microsoft Graph PowerShell, connectez-vous à Microsoft Graph PowerShell.

Connect-MgGraph -Scopes "Policy.ReadWrite.PermissionGrant"

Il est judicieux de commencer par vous familiariser avec les stratégies de consentement d’application existantes dans votre organisation :

  1. Listez des stratégies de consentement d’application :

    Get-MgPolicyPermissionGrantPolicy | ft Id, DisplayName, Description

  2. Affichez les ensembles de conditions « include » d’une stratégie :

    Get-MgPolicyPermissionGrantPolicyInclude -PermissionGrantPolicyId "microsoft-application-admin" | fl

  3. Affichez les ensembles de conditions « exclude » d’une stratégie :

    Get-MgPolicyPermissionGrantPolicyExclude -PermissionGrantPolicyId "microsoft-application-admin" | fl

Pour créer une stratégie de consentement d’application personnalisée, procédez comme suit :

  1. Créez une stratégie de consentement d’application personnalisée vide.

    New-MgPolicyPermissionGrantPolicy `
    -Id "my-custom-policy" `
    -DisplayName "My first custom consent policy" `
    -Description "This is a sample custom app consent policy."

  2. Ajoutez des ensembles de conditions « include ».

    # Include delegated permissions classified "low", for apps from verified publishers
New-MgPolicyPermissionGrantPolicyInclude `
    -PermissionGrantPolicyId "my-custom-policy" `
    -PermissionType "delegated" `
    -PermissionClassification "low" `
    -ClientApplicationsFromVerifiedPublisherOnly

    Répétez cette étape pour ajouter d’autres ensembles de conditions « include ».

  3. Ajoutez si besoin des ensembles de conditions « exclude ».

    # Retrieve the service principal for the Azure Management API
$azureApi = Get-MgServicePrincipal -Filter "servicePrincipalNames/any(n:n eq 'https://management.azure.com/')"

# Exclude delegated permissions for the Azure Management API
New-MgPolicyPermissionGrantPolicyExclude `
    -PermissionGrantPolicyId "my-custom-policy" `
    -PermissionType "delegated" `
    -ResourceApplication $azureApi.AppId

    Répétez cette étape pour ajouter d’autres ensembles de conditions « exclude ».

Après avoir créé la stratégie de consentement de l’application, vous devez l’attribuer à un rôle personnalisé dans Microsoft Entra ID. Vous devez ensuite attribuer ce rôle personnalisé, attaché à la stratégie de consentement de l’application que vous avez créée, à des utilisateurs. Pour plus d’informations sur l’attribution de la stratégie de consentement de l’application à un rôle personnalisé, consultez Autorisations de consentement d’application pour les rôles personnalisés.

La cmdlet suivante montre comment vous pouvez supprimer une stratégie de consentement des applications personnalisées.

   Remove-MgPolicyPermissionGrantPolicy -PermissionGrantPolicyId "my-custom-policy"

Pour gérer les stratégies de consentement d’application, connectez-vous à l’Explorateur Graph avec l’un des rôles répertoriés dans la section Prérequis.

Vous devez consentir à l’autorisation Policy.ReadWrite.PermissionGrant.

Il est judicieux de commencer par vous familiariser avec les stratégies de consentement d’application existantes dans votre organisation :

  1. Listez des stratégies de consentement d’application :

    GET /policies/permissionGrantPolicies?$select=id,displayName,description

  2. Affichez les ensembles de conditions « include » d’une stratégie :

    GET /policies/permissionGrantPolicies/{ microsoft-application-admin }/includes

  3. Affichez les ensembles de conditions « exclude » d’une stratégie :

    GET /policies/permissionGrantPolicies/{ microsoft-application-admin }/excludes

Pour créer une stratégie de consentement d’application personnalisée, procédez comme suit :

  1. Créez une stratégie de consentement d’application personnalisée vide.

    POST https://graph.microsoft.com/v1.0/policies/permissionGrantPolicies
Content-Type: application/json

{
  "id": "my-custom-policy",
  "displayName": "My first custom consent policy",
  "description": "This is a sample custom app consent policy"
}

  2. Ajoutez des ensembles de conditions « include ».

    Inclure des permissions déléguées classées « faible » pour les applications provenant d’éditeurs vérifiés

    POST https://graph.microsoft.com/v1.0/policies/permissionGrantPolicies/{ my-custom-policy }/includes
Content-Type: application/json

{
  "permissionType": "delegated",
  "PermissionClassification": "low",
  "clientApplicationsFromVerifiedPublisherOnly": true
}

    Répétez cette étape pour ajouter d’autres ensembles de conditions « include ».

  3. Ajoutez si besoin des ensembles de conditions « exclude ». Exclure les autorisations déléguées pour l’API de gestion Azure (appId 46e6adf4-a9cf-4b60-9390-0ba6fb00bf6b)

    POST https://graph.microsoft.com/v1.0/policies/permissionGrantPolicies/my-custom-policy /excludes
Content-Type: application/json

{
  "permissionType": "delegated",
  "resourceApplication": "46e6adf4-a9cf-4b60-9390-0ba6fb00bf6b "
}

    Répétez cette étape pour ajouter d’autres ensembles de conditions « exclude ».

Après avoir créé la stratégie de consentement de l’application, vous devez l’attribuer à un rôle personnalisé dans Microsoft Entra ID. Vous devez ensuite attribuer ce rôle personnalisé, attaché à la stratégie de consentement de l’application que vous avez créée, à des utilisateurs. Pour plus d’informations sur l’attribution de la stratégie de consentement de l’application à un rôle personnalisé, consultez Autorisations de consentement d’application pour les rôles personnalisés.

  1. L’exemple suivant montre comment vous pouvez supprimer une stratégie de consentement d’application personnalisée.

    DELETE https://graph.microsoft.com/v1.0/policies/permissionGrantPolicies/ my-custom-policy

Avertissement

Les stratégies de consentement d’application supprimées ne peuvent pas être restaurées. Si vous supprimez accidentellement une stratégie de consentement d’application personnalisée, vous devez recréer cette stratégie.

Conditions prises en charge

Le tableau suivant fournit la liste des conditions prises en charge pour les stratégies de consentement des applications.

Condition Description
PermissionClassification La classification des autorisations pour l’autorisation accordée, ou « All » pour correspondre à toute classification d’autorisation (y compris les autorisations qui ne sont pas classées). La valeur par défaut est « All ».
PermissionType Type d’autorisation de l’autorisation accordée. Utilisez « application » pour les autorisations de l’application (par exemple, les rôles d’application) ou « delegated » pour les autorisations déléguées.

Remarque : la valeur « delegatedUserConsentable » indique des autorisations déléguées qui ne sont pas configurées par l’éditeur d’API pour exiger le consentement de l’administrateur. Cette valeur peut être utilisée dans les stratégies d’octroi d’autorisations intégrées, mais elle ne peut pas être utilisée dans les stratégies d’octroi d’autorisations personnalisées. Obligatoire.
ResourceApplication AppId de l’application de ressource (par exemple, l’API) pour laquelle une autorisation est accordée, ou « any » pour correspondre à n’importe quelle application ou API de ressources. La valeur par défaut est « Any ».
Autorisations Liste des ID d’autorisation pour les autorisations spécifiques de correspondance ou une liste avec la valeur unique « all » pour toutes les autorisations. La valeur par défaut est la seule valeur « All ».
– Les ID de permission déléguée se trouvent dans la propriété OAuth2Permissions de l’objet ServicePrincipal de l’API.
– Les ID d’autorisation d’application se trouvent dans la propriété AppRoles de l’objet ServicePrincipal de l’API.
ClientApplicationIds Liste de valeurs AppId auxquelles les applications clientes doivent correspondre ou liste avec la valeur unique « all » pour correspondre à n’importe quelle application cliente. La valeur par défaut est la seule valeur « All ».
ClientApplicationTenantIds Liste d’identifiants de locataires Microsoft Entra dans lesquels l’application cliente est inscrite, ou liste avec la valeur unique « all » pour correspondre aux applications clientes inscrites dans n’importe quel locataire. La valeur par défaut est la seule valeur « All ».
ClientApplicationPublisherIds Liste d’ID de partenaires Microsoft Partner Network (MPN) pour les serveurs de publication vérifiés de l’application cliente, ou liste avec la valeur unique « all » pour qu’elle corresponde aux applications clientes de n’importe quel serveur de publication. La valeur par défaut est la seule valeur « All ».
ClientApplicationsFromVerifiedPublisherOnly Affectez ce commutateur pour qu’il corresponde uniquement aux applications clientes disposant d’un serveur de publication vérifié. Désactivez ce commutateur (-ClientApplicationsFromVerifiedPublisherOnly:$false) pour qu’il corresponde à toute application cliente, même si elle n’a pas de serveur de publication vérifié. La valeur par défaut est $false.
scopeType Type d’étendue de ressource auquel s’applique la préapprobation. Valeurs possibles : group pour les groupes et les équipes, chat pour les conversations ou tenant pour l’accès à l’échelle du locataire. Obligatoire.
sensitivityLabels Étiquettes de confidentialité applicables au type d’étendue et ne sont pas préapprouvées. Elles vous permettent de protéger les données sensibles de l’organisation. En savoir plus sur les étiquettes de confidentialité. Remarque : la ressource de conversation ne prend pas encore en charge sensitivityLabels.

Étapes suivantes

Pour obtenir de l’aide ou trouver des réponses à vos questions :