Autorisations d’API pour le kit de développement logiciel (SDK) Microsoft Information Protection
Le SDK MIP utilise deux services Azure principaux pour l’étiquetage et la protection. Dans le panneau Autorisations d’application Microsoft Entra, ces services sont les suivants :
- Azure Rights Management Service
- Service de synchronisation de Protection des données Microsoft Purview
Les autorisations d’application doivent être accordées à une ou plusieurs API lors de l’utilisation du kit de développement logiciel (SDK) MIP pour l’étiquetage et la protection. Différents scénarios d’authentification d’application peuvent nécessiter des autorisations d’application différentes. Pour les scénarios d’authentification d’application, consultez Scénarios d’authentification.
Le consentement administrateur à l’échelle du client doit être accordé pour les autorisations d’application où le consentement d’Administrateur est requis. Si vous souhaitez obtenir plus d’informations, consultez la Documentation de Microsoft Entra.
Autorisations d’application
Les autorisations d’application permettent à une application dans Microsoft Entra ID d’agir en tant qu’entité propre, plutôt que pour le compte d’un utilisateur spécifique.
| Service | Nom de l’autorisation | Description | Consentement administrateur requis |
|---|---|---|---|
| Azure Rights Management Service | Content.SuperUser | Lire tout le contenu protégé pour ce client | Oui |
| Azure Rights Management Service | Content.DelegatedReader | Lire le contenu protégé pour le compte d’un utilisateur | Oui |
| Azure Rights Management Service | Content.DelegatedWriter | Créer le contenu protégé pour le compte d’un utilisateur | Oui |
| Azure Rights Management Service | Content.Writer | Créer le contenu protégé | Oui |
| Azure Rights Management Service | Application.Read.All | Autorisation non requise pour l’utilisation du SDK MIP | Non applicable |
| Service de synchronisation MIP | UnifiedPolicy.Tenant.Read | Lire toutes les stratégies unifiées du client | Oui |
Content.SuperUser
Cette autorisation est requise lorsqu’une application doit être autorisée à déchiffrer tout le contenu protégé pour le client spécifique. Des exemples de services qui nécessitent des droits Content.Superuser sont la protection contre la perte de données ou les services de broker de sécurité d’accès au cloud qui doivent afficher tout le contenu en texte en clair pour prendre des décisions de stratégie sur l’endroit où ces données peuvent circuler ou être stockées.
Content.DelegatedWriter
Cette autorisation est requise lorsqu’une application doit être autorisée à chiffrer le contenu protégé par un client spécifique. Des exemples de services qui nécessitent des droits Content.DelegatedWriter sont des applications métier qui doivent chiffrer du contenu en fonction des stratégies des étiquettes de l’utilisateur pour appliquer des étiquettes et/ou chiffrer du contenu de manière native. Cette autorisation permet à l’application de chiffrer du contenu dans le contexte de l’utilisateur.
Content.DelegatedReader
Cette autorisation est requise lorsqu’une application doit être autorisée à déchiffrer tout le contenu protégé pour un client spécifique. Des exemples de services qui nécessitent des droits Content.DelegatedReader sont des applications métier qui doivent déchiffrer du contenu en fonction des stratégies des étiquettes de l’utilisateur pour afficher du contenu de manière native. Cette autorisation permet à l’application de déchiffrer et de lire du contenu dans le contexte de l’utilisateur.
Content.Writer
Cette autorisation est requise lorsqu’une application doit être autorisée à répertorier les modèles et à chiffrer le contenu. Un service qui tente de répertorier les modèles sans cette autorisation recevra un jeton Message rejeté par le service. Les services qui requièrent Content.writer sont par exemple une application métier qui applique des étiquettes de classification aux fichiers lors de leur exportation. Content.Writer chiffre le contenu en tant qu’identité du principal de service ; le propriétaire des fichiers protégés est donc l’identité du principal de service.
UnifiedPolicy.Tenant.Read
Cette autorisation est requise lorsqu’une application doit être autorisée à télécharger des stratégies d’étiquetage unifiées pour le client. Des exemples de services nécessitant UnifiedPolicy.Tenant.Read sont des applications qui nécessitent un travail avec des étiquettes en tant qu’identité de principal de service.
Autorisations déléguées
Les permissions déléguées permettent à une application dans Microsoft Entra ID d’effectuer des actions pour le compte d’un utilisateur particulier.
| Service | Nom de l’autorisation | Description | Consentement administrateur requis |
|---|---|---|---|
| Azure Rights Management Service | user_impersonation | Créer du contenu protégé et y accéder pour l’utilisateur | Non |
| Service de synchronisation MIP | UnifiedPolicy.User.Read | Lire toutes les stratégies unifiées auxquelles un utilisateur a accès | Non |
User_Impersonation
Cette autorisation est requise lorsqu’une application doit être autorisée à utiliser les services Azure Rights Management pour le compte de l’utilisateur. Des exemples de services qui nécessitent des droits User_Impersonation sont des applications qui doivent chiffrer du contenu ou accéder à du en fonction des stratégies des étiquettes de l’utilisateur pour appliquer des étiquettes ou chiffrer du contenu de manière native.
UnifiedPolicy.User.Read
Cette autorisation est requise lorsqu’une application doit être autorisée à lire des stratégies d’étiquetage unifiées relatives à un utilisateur. Des exemples de services qui nécessitent des autorisations UnifiedPolicy.User.Read sont des applications qui doivent chiffrer et déchiffrer du contenu, en fonction des stratégies des étiquettes de l’utilisateur.