Par Emeric lallement, Data architect
Power BI est en constante évolution et nous offre chaque mois de nouvelles fonctionnalités. Dans ce billet, nous allons voir comment mettre en place la sécurité dynamique avec Power BI Embedded à travers le Row Level Security (RLS) dans Azure Analysis Services (AAS).
Il existe 2 variantes pour incorporer les rapports Power BI dans une application :
-
- La première, « embed for your organization », s’adresse à un usage interne et repose sur l’authentification via l’Active Diretory (AD).
-
- La seconde, « embed for your customers », s’adresse aux clients pour lesquels il n’existe pas de compte AD car externes à l’entreprise. Le processus d’identification et de propagation de l’identité est alors différent et nous allons également voir ce cas d’usage.
Le traitement de cette problématique s’articulera autour des points suivants :
-
- Modélisation AAS, RLS et rapport Power BI
- Contexte Organization :
- Configuration de l’application Azure AD pour Power BI Embedded
- Création du rôle AAS
- Incorporation dans PowerBI Playground for Organization
- Mise en place des flux API Embedded
- Authentification du service principal
- Récupération de l’embed token Power BI
- Récupération de l’URL d’incorporation Power BI
- Contexte Customers :
- Incorporation dans Power BI Playground for Customers
- Adaptation pour Analysis Services
- Ajout de la sécurité (RLS) for Customer
- Et ensuite ?
- Sécurité applicative
- Sécurité des données
Pour tester la gestion de la sécurité avec Power BI Embedded, nous utilisons un rapport Power BI connecté en mode « LiveConnection » à un cube Analysis Services possédant un rôle pour la gestion dynamique des droits. Celui-ci est publié dans un workspace Premium du Service Power BI.
Une modélisation très simple va permettre d’expérimenter les droits :
Notre jeu d’essai comporte :
- Une table de permission qui contient l’affectation des personnes dans les Teams
- Une table représentant les Teams équivalent à une dimension (DimTeam)
- Une table représentant la table de faits (FactValue).
Cette modélisation permet de gérer un rôle RLS dynamique basé sur la table des permissions. Pour ce faire, ne pas oublier le spécifier la prise en compte du RLS lors de la configuration de la relation :
Les deux modes de fonctionnement (Organization et Customers) sont similaires en termes d’implémentation et de modélisation, mais comportent une légère différence lors de la mise en place des droits ainsi que la génération des accès.
Configuration de l’application Azure AD pour PowerBI Embedded
Pour commencer, nous devons créer une application dans l’Azure AD et lui attribuer les droits d’accès nécessaires à l’implémentation de la solution.
Les étapes de création et configuration sont identiques à celles décrites dans le chapitre Configuration des environnements de notre précédent article décrivant l’automatisation du déploiement de rapports Power BI via DevOps.
Nous retrouvons également le détail de cette procédure depuis les étapes 2 à 7 de la documentation Microsoft (NDLR : nous recommandons d’utiliser la version avec un Principal de Service qui permet de décorréler le Service d’un compte utilisateur standard).
Une fois la configuration réalisée, nous sommes en possession des éléments suivants :
- Une application Azure AD
- Son ID Client (ou Application ID)
- Sa Clé secrète
- Son ID Tenant
- Son ID Object
- Un espace de travail
- Son ID
Nous pouvons maintenant récupérer les Id du rapport Power BI ainsi que son dataset.
Création du rôle AAS
Depuis le projet Analysis Services accessible via Visual Studio, nous allons paramétrer le rôle de sécurité dynamique. Celui-ci, nommé DynamicOrganization, est basé sur l’identité fédérée de l’utilisateur connecté à Power BI depuis son compte AD. Cette identité est transmise à la base de données Analysis Services via le mode de connexion LiveConnection.
Pour ce faire, nous utilisons la propriété USERPRINCIPALNAME() qui renvoie l’adresse email de l’utilisateur. Celle-ci est comparée aux emails présents dans la table Permission afin de déterminer les Teams auxquelles il peut accéder.
Depuis l’onglet Members, nous ajoutons les groupes ou utilisateurs qui devrons accéder aux données via ce rôle.
La mise en place du RLS depuis AAS est alors terminée. Nous pouvons associer le rapport Power BI à cette source de données et bénéficier de la sécurité dynamique au niveau des lignes.
Incorporation dans PowerBI Playground for Organization
A ce stade, l’ensemble des prérequis pour intégrer le rapport dans une application externe ont été remplis.
Microsoft a mis à disposition l’outil PlayGround, qui permet notamment de tester l’intégration de rapport. Grâce à cela, nous allons être en mesure de tester le fonctionnement des droits d’accès facilement, la partie PowerBI Playgroud étant particulièrement bien pensée.
Une fois que vous êtes connecté à l’interface, trois options s’offrent à vous :
La deuxième option, intitulée Utiliser mon propre rapport Power BI, permet de tester la fonctionnalité aisément en seulement trois clics !
Pour ce faire, il vous suffit de sélectionner votre espace de travail ainsi que le rapport en question. L’authentification est alors activée automatiquement, ce qui permet de prendre en compte le rendu du rapport via Power BI Embedded.
À ce stade, il est déjà possible d’utiliser Power BI Embedded for Organization, car cette partie utilise le profil AD et ne requiert que certaines permissions à accorder depuis le popup suivant :
NB : Pour afficher l’adresse email de l’utilisateur connecté, utilisée par Power BI et AS pour filtrer les données, vous pouvez inclure la mesure DAX suivante :
Profil := USERPRINCIPALENAME()
On vérifie ainsi que la sécurité est active et le contexte utilisateur correctement pris en compte :
Dans cette section, nous allons examiner de manière approfondie la cinématique nécessaire pour générer des accès et pouvoir intégrer un rapport dans un site web. L’ensemble des appels API vont être détaillé de manière à pouvoir reproduire toutes les étapes.
Afin de récupérer l’ensemble des informations nécessaires à l’affichage du rapport, trois étapes sont nécessaires :
- Authentification du service Principal
- Récupération de l’emded token PowerBI
- Récupération de l’URL d’incorporation PowerBI
Le schéma ci-dessous illustre la mise en place (via API) de l’authentification autour de Power BI Embedded for Customers :
Authentification du service principal
La première étape consiste à récupérer le token d’identification depuis l’active directory en utilisant l’application précédemment enregistrée, ce qui simule les flux 2 (via Service principal) et 3.
Pour ce faire, ouvrez Postman et modifiez (ou variabilisez) les informations entre les accolades :
- URL:
- Type : POST
- URL : https://login.microsoftonline.com/{{tenantId}}/oauth2/token
- Body:
- Grant_type = client_credentials
- Client_id = {{ClientID}}
- Client_secret = {{clientSecret}}
- Resource = https://analysis.windows.net/powerbi/api
On obtient la réponse suivante :
{
"token_type": "Bearer",
"expires_in": "3599",
"ext_expires_in": "3599",
"expires_on": "1650447999",
"not_before": "1650444099",
"resource": "https://analysis.windows.net/powerbi/api",
"access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImpTMVhvMU9XRGpfNTJ2YndHTm
…
suCPYXZxk6Wh8dFl6HEePN9nTk6g"
}
Récupération de l’embed token Power BI
Le token retourné par les appels Postman doit être réutilisé pour l’authentification auprès de Power BI via les API REST Power BI.
Dans cet exemple, nous utiliserons Power BI en mode Import de données. Lors de l’appel à l’API, les éléments nécessaires doivent être fournis pour permettre la gestion des droits que nous souhaitons attribuer à l’utilisateur que nous allons authentifier.
Il nous faut alors créer une nouvelle requête Postman avec les paramètres suivants :
- URL :
- Authorization:
- Ajouter le token récupéré lors de l’étape précédente
- Body :
{
"accessLevel": "View",
"identities": [
{
"username": "{{AppObjectID}}",
"roles": [
"DynamicOrganization"
],
"datasets": [
"{{PowerbiDatasetID}}"
]
}
]
}
On obtient la réponse suivante :
{
"@odata.context": "http://wabi-north-europe-g-primary-redirect.analysis.windows.net/v1.0/myorg/groups/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/$metadata#Microsoft.PowerBI.ServiceContracts.Api.V1.GenerateTokenResponse",
"token": "H4sIAAAAAAAEAB2Tta7EVgAF_-
…
ZGVybkVtYmVkIjpmYWxzZX19",
"tokenId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"expiration": "2022-04-20T09:46:39Z"
}
Le token correspond au jeton que nous utiliserons dans Power BI Playground.
Récupération de l’URL d’incorporation Power BI
Cette étape est similaire à l’étape précédente, mais elle permet de récupérer l’URL qui permettra l’incorporation du rapport :
- URL :
- Type : GET
- URL: https://api.powerbi.com/v1.0/myorg/groups/{{workspaceID}}/reports/{{reportImportID}}/GenerateToken
- Authorization:
- Ajouter le token récupéré lors de l’étape 1
- Body :
Le champ embedUrl est celui qui nous intéresse et que nous réutiliserons lors de l’étape suivante.
{
"@odata.context": "http://wabi-north-europe-g-primary-redirect.analysis.windows.net/v1.0/myorg/groups/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/$metadata#reports/$entity",
"id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"reportType": "PowerBIReport",
"name": "POC PowerBI - Secu",
"webUrl": "https://app.powerbi.com/groups/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/reports/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "embedUrl": "https://app.powerbi.com/reportEmbed?reportId=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx&groupId=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx&w=2&config=...%3d%3d",
"isFromPbix": true,
"isOwnedByMe": true,
"datasetId": " xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ",
"datasetWorkspaceId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"users": [],
"subscriptions": []
}
Incorporation dans Power BI Playground for Customers
Sur la page d’accueil, vous devez vous rendre sur le bac à sable. Trois options vous seront proposées, et celle qui vous intéresse est Utiliser mon jeton intégré.
Le dernier popup nous propose de rentrer les informations que l’on a récupéré lors des différents appels API :
- Insérer votre jeton intégré => Récupéré à l’étape 2
- Insérer votre URL incorporée => Récupéré à l’étape 3
- Insérer votre ID de client => Récupérer en phase préparatoire
Normalement un problème de droits d’accès devrait s’afficher :
En effet, à ce moment-là du processus, ce n’est plus le login AD qui est utilisé pour se connecter, mais l’application enregistrée dans l’AD. Pour retrouver l’accès, il faut donc mettre l’application en tant qu’utilisateur du rôle « DynamicOrganization » créé lors de la modélisation.
Votre rapport va maintenant s’afficher dans Power BI mais sans aucune donnée car c’est maintenant l’identité de l’application qui est renvoyée lors de l’utilisation de la fonction USERPRINCIPALNAME() :
La mise en place de Power BI Embedded avec les accès externes nécessite un fonctionnement un peu différent sur 2 éléments :
- La mise en place de la sécurité au niveau d’Analysis Services
- La génération des tokens d’accès pour Power BI
Adaptation pour Analysis Services
La modification des droits nécessite 2 étapes complémentaires afin de pouvoir établir les droits d’accès au niveau d’analysis services :
- Mettre en place les droits
- Changer la génération du token
Nous ne nous appuierons plus sur la propriété USERPRINCIPALENAME() pour établir les droits d’accès, mais plutôt sur la propriété CUSTOMDATA() qui est disponible nativement dans Analysis Services. Cette dernière nous permettra de propager l’identité de l’utilisateur au niveau des permissions.
Nous allons donc définir un nouveau rôle nommé ici DynamicCustomers :
Le seul utilisateur de ce rôle sera notre application enregistrée dans l’Active Directory, car c’est bien elle et elle seule qui se connectera à Analysis Services (nous allons voir cela plus tard).
NB : Ne pas oublier d’enlever l’application du rôle DynamicOrganization.
La seconde étape consiste à générer le jeton en utilisant une légère variation qui permet de définir la propriété CustomData lors de l’appel de l’API pour générer le jeton.
Ajout de la sécurité (RLS) for Customers
Cette étape va permettre de générer les droits d’accès lors de l’authentification et de les transmettre à Analysis Services afin d’appliquer la sécurité dynamique.
La requête Postman ressemblera désormais à ceci :
- URL :
- Type : POST
- URL: https://api.powerbi.com/v1.0/myorg/groups/{{workspaceID}}/reports/{{reportImportID}}/GenerateToken
- Authorization:
- Ajouter le token récupéré lors de l’étape précédente
- Body:
{
"accessLevel": "View",
"identities": [
{
"username": "{{ObjectID}}",
"customData": "MemberTeamB@orga.com",
"roles": [
"DynamicCustomers"
],
"datasets": [
"{{datasetImportID}}"
]
}
]
}
Ce nouveau token contient à la fois l’authentification de l’application auprès du service Power BI et l’information CUSTOMDATA.
Afin de mieux comprendre ce qui se passe, une nouvelle mesure DAX est créée dans le modèle, faisant référence à la propriété CUSTOMDATA :
CustomData:= CUSTOMDATA()
Nous allons maintenant essayer de nous connecter à Power BI Playground en utilisant le nouveau token :
Nous pouvons constater que nous nous sommes toujours connectés avec le compte de service, mais nous avons transmis les informations de l’utilisateur via la propriété CustomData.
Cette propriété est interprétée et utilisée pour mettre en place la sécurité dynamique dans Analysis Services.
Le rapport est maintenant prêt à être exposé directement à vos clients via le site web de votre choix.
Sécurité applicative
La sécurité est un élément crucial à prendre en compte lors de l’utilisation de cette solution. L’envoi direct du CUSTOMDATA lors de l’appel API peut représenter un risque de sécurité si cela n’est pas fait correctement.
Il est donc recommandé de packager l’ensemble des appels API en un seul appel depuis le front-end afin de garantir la sécurité de l’authentification de l’application déclarée dans l’AD ainsi que l’appel API avec l’identité déclarée dans la propriété CUSTOMDATA.
Sécurité des données
Le deuxième point à prendre en compte est que les possibilités sont légèrement différentes par rapport à l’authentification Active Directory habituellement réalisée sur Analysis Services, qui nécessite l’importation des droits dans le cube.
Avec cette méthode, on peut désormais ajouter directement des filtres sur une équipe en renseignant le nom de l’équipe dans la propriété CUSTOMDATA(). Il n’est plus nécessaire de gérer un référentiel de droits dans Analysis Services, ce qui est très pratique !