Microsoft Information Protection SDK - Autorisations définies par l’utilisateur

Le sdk Microsoft Information Protection prend en charge deux types principaux d’autorisations basées sur des étiquettes : basées sur des modèles et définies par l’utilisateur.

  • Autorisations basées sur des modèles : L’administrateur d’étiquette définit ces droits dans le portail Microsoft Purview. Ces étiquettes sont gérées de manière centralisée et les modifications de configuration affectent les utilisateurs qui ont déjà des copies des fichiers. Par exemple, si l’administrateur supprime un utilisateur de la liste des utilisateurs autorisés, cet utilisateur n’a plus accès aux données protégées la prochaine fois qu’il tente d’extraire une licence.

  • Autorisations définies par l’utilisateur : l’utilisateur final ou l’application définit ces droits au moment de l’étiquetage. Transmettez les autorisations au SDK MIP sous forme d’une collection d’associations entre utilisateurs et rôles ou entre utilisateurs et droits. Le SDK MIP écrit ces droits dans la licence de publication du document protégé. Contrairement aux autorisations basées sur des modèles, vous ne pouvez pas gérer ou modifier ces droits de manière centralisée après le partage sans accès direct et modification du document.

Utilisateurs, droits et rôles

Étant donné que l’utilisateur définit les droits au moment de l’étiquetage, votre application doit fournir une interface permettant à l’utilisateur ou au service d’entrer des adresses e-mail et des droits ou rôles. Pour configurer l’accès, transmettez une collection d’objets UserRolesUserRights qui définissent qui a le niveau d’accès aux documents.

// Create a List<string> of the first set of permissions. 
List<string> users = new List<string>()
{
    "alice@contoso.com",
    "bob@contoso.com"
};

// Create a List<string> of the Rights the above users should have. 
List<string> rights = new List<string>()
{
    Rights.View,
    Rights.Edit                
};

// Create a UserRights object containing the defined users and rights.
UserRights userRights = new UserRights(users, rights);

// Add them to a new List<UserRights>
List<UserRights> userRightsList = new List<UserRights>()
{
    userRights
};

Le résultat est une List<UserRights> collection qui spécifie que Alice et Bob ont VIEW et EDIT sur le fichier protégé. Pour ajouter d’autres utilisateurs avec un autre ensemble d’autorisations, répétez le processus pour créer un deuxième UserRights objet, transmettez les nouveaux utilisateurs et autorisations, puis ajoutez-le à la List<UserRights> collection en appelant userRightsList.Add(userRights2).

Le même modèle s’applique à UserRoles. Pour l’implémenter, remplacez les droits par les rôles et créez une List<UserRoles> collection.

Protection d’un domaine

L’application d’autorisations définies par l’utilisateur pour un domaine nécessite un préfixe de messagerie connu et le domaine cible comme adresse de messagerie. Cette adresse ressemble à AllStaff-7184AB3F-CCD1-46F3-8233-3E09E9CF0E66@contoso.com.

Dans votre application, les utilisateurs doivent pouvoir spécifier un domaine, comme contoso.com ou fabrikam.com. Lorsque l’application crée le descripteur de protection, il précède AllStaff-7184AB3F-CCD1-46F3-8233-3E09E9CF0E66@ au suffixe de domaine.

Ce groupe connu est également la façon dont vous accordez des droits à tous les utilisateurs authentifiés d’une organisation. Le AllStaff-7184AB3F-CCD1-46F3-8233-3E09E9CF0E66@ groupe contient chaque utilisateur dans le locataire Microsoft Entra spécifié. Il s'agit donc de l'équivalent le plus proche du groupe ANYONE de Active Directory Rights Management Services (AD RMS). La portée se limite toujours à un seul locataire : il n’existe pas d’identité inter-locataires qui accorde des droits à n’importe quel utilisateur authentifié, quel que soit le locataire. Ajoutez donc une entrée distincte AllStaff-...@domain pour chaque organisation que vous souhaitez inclure. Pour plus d’informations, consultez Configurer des droits d’utilisation pour Azure Information Protection.

Dans l’exemple suivant, l’utilisateur spécifie alice@contoso.com ainsi que l’ensemble du domaine Fabrikam.com comme destinataires valides.

// Create a List<string> of the first set of permissions. 
List<string> users = new List<string>()
{
    "alice@contoso.com",
    "AllStaff-7184AB3F-CCD1-46F3-8233-3E09E9CF0E66@fabrikam.com"
};

// Create a List<string> of the Rights the above users should have. 
List<string> rights = new List<string>()
{
    Rights.View,
    Rights.Edit                
};

// Create a UserRights object containing the defined users and rights.
UserRights userRights = new UserRights(users, rights);

// Add them to a new List<UserRights>
List<UserRights> userRightsList = new List<UserRights>()
{
    userRights
};

Appliquer la protection

Pour définir la protection, créez un ProtectionDescriptor élément à partir de l’objet List<UserRights> ou List<UserRoles> , puis passez ce descripteur à FileHandler.SetProtection(). Enfin, validez la modification apportée au fichier pour écrire un nouveau fichier.

Quand appliquer la protection aux fichiers

Lorsque vous définissez une étiquette à l’aide de FileHandler.SetLabel(), le SDK MIP dispose de tout ce dont il a besoin pour agir et appliquer toute protection nécessaire. Lorsqu’une étiquette utilise des autorisations définies par l’utilisateur (UDP), votre application n’a aucun moyen de savoir à l’avance que l’étiquette est une étiquette UDP. Le SDK MIP expose ces informations en levant une exception de type Microsoft.InformationProtection.Exceptions.AdhocProtectionRequiredException. Votre FileHandler code doit intercepter cette exception, puis déclencher votre interface utilisateur ou service pour définir les autorisations personnalisées. Une fois ce processus terminé, vous pouvez définir la protection. L’exemple suivant montre le modèle de bout en bout, mais suppose que vous avez déjà implémenté une fonction pour générer l’objet List<UserRights> .

try
{
    // Attempt to set the label. If it's a UDP label, this will throw. 
    handler.SetLabel(engine.GetLabelById(options.LabelId), labelingOptions, new ProtectionSettings());
}

catch (Microsoft.InformationProtection.Exceptions.AdhocProtectionRequiredException)
{
    // Assumes you've create a function that returns the List<UserRights> as previously detailed. 
    List<UserRights> userRightsList = GetUserRights();

    // Create a ProtectionDescriptor using the set of UserRights.
    ProtectionDescriptor protectionDescriptor = new ProtectionDescriptor(userRightsList);
    
    // Apply protection to the file using the new ProtectionDescriptor. 
    handler.SetProtection(protectionDescriptor, new ProtectionSettings());

    // Set the label. This will now succeed as protection has been defined. 
    handler.SetLabel(engine.GetLabelById(options.LabelId), labelingOptions, new ProtectionSettings());

    // Commit the change. 
    var result = Task.Run(async () => await handler.CommitAsync("myFileOutput.xlsx")).Result;
}

Protection personnalisée

Vous pouvez également utiliser ce processus pour définir uniquement la protection en définissant la protection et en ignorant l’étape SetLabel() . Si votre application n’a pas besoin d’appliquer une étiquette, le gestionnaire d’exceptions n’est pas obligatoire. Pour définir la protection, suivez le ProtectionDescriptor modèle ->>SetProtection()CommitAsync() - .

Étapes suivantes

  • Dernière mise à jour :