Incorporer un rapport avec RLS

S’APPLIQUE À : L’application est propriétaire des données L’utilisateur est propriétaire des données

Cet article explique comment intégrer du contenu Power BI qui utilise la RLS dans une application de données appartenant à une application Power BI standard.

Prérequis

Pour une explication détaillée sur la façon de configurer RLS, reportez-vous à Sécurité au niveau des lignes (RLS) avec Power BI.

Lorsque vous définissez vos rôles RLS, n’oubliez pas que l’expression DAX que vous utilisez détermine si le modèle RLS est statique ou dynamique.

Quand utiliser la sécurité statique et dynamique

La sécurité statique utilise une valeur fixe dans le filtre DAX pour définir chaque rôle. C’est simple à implémenter, mais difficile à gérer quand de nombreux utilisateurs ou organisations sont impliqués.

La sécurité statique fonctionne mieux pour un éditeur de logiciels indépendant qui sert un ou plusieurs grands clients où chaque service doit accéder à des données différentes.

La sécurité dynamique utilise une fonction DAX (username() ou userprincipalname()) pour définir les rôles. La sécurité dynamique offre plus de souplesse et vous permet de gérer vos données avec moins de rôles et moins de maintenance.

Sécurité statique

Avec les rôles statiques, vous transmettez le rôle à Power BI lorsque vous générez un jeton d’intégration, et l’utilisateur voit les données en fonction de ce rôle. Pour créer des rôles de sécurité statiques, saisissez une valeur fixe dans le filtre DAX.

Par exemple, vous pouvez définir le rôle de USA Est comme [Region] = "East"

Disons que john@contoso.com est un utilisateur de votre application. Vous voulez donner à John l’accès aux données du rôle USA Est. Pour intégrer un rapport pour john@contoso.com, générez un jeton d’intégration en utilisant le rôle USA Est. Les données résultantes sont filtrées pour [Region] = "East".

Sécurité dynamique

La sécurité dynamique utilise la fonction DAX (username() ou userprincipalname()) pour définir le rôle.

Dans le scénario L’utilisateur possède les données, le modèle RLS filtre automatiquement les données en fonction des rôles de l’utilisateur spécifique. Avec L’application possède les données, Power BI ne connaît pas les noms d’utilisateur des clients de l’éditeur de logiciels indépendant, vous pouvez donc utiliser la fonction username() pour filtrer dynamiquement les données.

Créez un rôle dans Power BI Desktop en utilisant la fonction username(). Par exemple, vous pouvez créer un rôle appelé CountryDynamic et le définir comme [CountryRegionCode] = username()

Disons que vous voulez donner à votre utilisateur, jane@contoso.com, l’accès aux données de France. Lorsque vous générez un jeton intégré pour jane@contoso.com, vous transmettez la chaîne France comme nom d’utilisateur dans le rôle CountryDynamic. Vos données sont filtrées en fonction de [CountryRegionCode] = France.

{
    "accessLevel": "View",
    "identities": [
        {
            "username": "France",
            "roles": [ "CountryDynamic"],
            "datasets": [ "fe0a1aeb-f6a4-4b27-a2d3-b5df3bb28bdc" ]
        }
    ]
}

Lorsque vous utilisez la sécurité dynamique dans ce scénario, vous n’avez besoin que d’un seul rôle pour toutes les régions. Le nom de la région est utilisé comme identité effective.

Générer un jeton d’intégration

Lorsque vous êtes prêt à intégrer le rapport dans votre application, vous devez générer un jeton d’incorporation. Pour générer un jeton à l’aide de l’API Jeton d’incorporation, transmettez les informations suivantes à l’API.

• username (requis) : Si les rôles sont dynamiques, la chaîne username est utilisée comme filtre. Pour les rôles statiques, le nom d’utilisateur n’affecte pas la RLS et peut être n’importe quelle chaîne. Un seul nom d’utilisateur peut être répertorié.
• roles (requis) : Le(s) rôle(s) utilisé(s) lors de l’application des règles de sécurité au niveau des lignes. Si vous transmettez plusieurs rôles, ceux-ci doivent l’être en tant que tableau de chaînes.
• Jeu de données (requis) : jeu de données applicable à l’élément que vous incorporez.

Vous pouvez maintenant intégrer le rapport dans votre application. Le rapport filtre les données en fonction de la RLS appliquée.

public EmbedToken GetEmbedToken(Guid reportId, IList<Guid> datasetIds, [Optional] Guid targetWorkspaceId)
    {
        PowerBIClient pbiClient = this.GetPowerBIClient();

       // Defines the user identity and roles.
        var rlsIdentity = new EffectiveIdentity(
            username: "France",
            roles: new List<string>{ "CountryDynamic" },
            datasets: datasetIds.Select(id => id.ToString()).ToList());
        );
       
        // Create a request for getting an embed token for the rls identity defined above
        var tokenRequest = new GenerateTokenRequestV2(
            reports: new List<GenerateTokenRequestV2Report>() { new GenerateTokenRequestV2Report(reportId) },
            datasets: datasetIds.Select(datasetId => new GenerateTokenRequestV2Dataset(datasetId.ToString())).ToList(),
            targetWorkspaces: targetWorkspaceId != Guid.Empty ? new List<GenerateTokenRequestV2TargetWorkspace>() { new GenerateTokenRequestV2TargetWorkspace(targetWorkspaceId) } : null,
            identities: new List<EffectiveIdentity> { rlsIdentity }
        );

        // Generate an embed token
        var embedToken = pbiClient.EmbedToken.GenerateToken(tokenRequest);

        return embedToken;
    }

Observations et limitations

• Selon votre configuration, vous devrez peut-être effectuer plusieurs étapes avant de pouvoir générer un jeton incorporé. Pour plus d’informations sur les différents scénarios, consultez Incorporer un rapport qui utilise des fonctionnalités de sécurité.
• L’utilisateur qui génère le jeton d’incorporation doit être membre ou administrateur des deux espaces de travail (le jeu de données et le rapport).
• Lors de la génération du jeton incorporé, vous devez fournir un nom d’utilisateur et un rôle. Si ce n’est pas le cas, l’un des évènements suivants se produisent, selon que le jeton est généré par le principal du service ou l’utilisateur principal :
  • Pour un principal de service, la génération de jetons échoue.
  • Pour un utilisateur maître, la génération de jetons réussit, mais les données ne sont pas filtrées (toutes les données sont retournées).

Contenu connexe

• Conseils de RLS
• Générer un jeton d’intégration

D’autres questions ? Essayez la communauté Power BI.