Comment Michelin a combiné Power BI et Salesforce pour le reporting externe
Publié par Clément Bohic le | Mis à jour le
L’une des équipes de Michelin revient sur sa mise en place d’un accès externe à un rapport Power BI par l’intermédiaire d’un portail Salesforce.
Et si, plutôt que d’exploiter un module complémentaire, on embarquait nos dashboards dans un composant Lightning via un iframe ?
L’une des équipes du département BI & Analytics de Michelin sur la plaque Amériques a fait cet arbitrage. Le contexte : un projet d’ouverture de rapports Power BI à des clients externes.
Des jalons étaient déjà posés, mais avec Microstrategy en back-end. L’accès se faisait par l’intermédiaire d’un portail internet (Michelin MyPortal) basé sur Salesforce.
Le premier dashboard mis en place (Fleet Business Insights) ciblait gestionnaires de flottes et concessionnaires. Il fallait aussi assurer un accès à l’équipe commerciale de Michelin – qui accédait déjà à Salesforce par intégration avec Azure Active Directory. Et, évidemment, à l’équipe chargée du projet.
Pour les utilisateurs externes se sont posées des questions en matière d’authentification et de gestion des droits : pouvait-on créer des comptes invités dans Azure AD ? Fallait-il préférer OAuth ou SAML ?…
Un double mécanisme d’authentification
Pour le scénario envisagé, les utilisateurs externes n’avaient pas besoin d’accéder au réseau interne de Michelin (comptes MyPortal indépendants). Ainsi, on a segmenté l’authentification en deux systèmes.
Donner des logins Michelin à des utilisateurs externes n’était pas envisageable. Il a donc été décidé d’utiliser un compte de service pour récupérer les données dans le data lake et charger le dashboard.
Lorsqu’un utilisateur accède à la web app, celle-ci passe par le compte de service pour contacter Azure AD, qui lui transmet un token confirmant la possibilité de charger le rapport. Cette communication se fait exclusivement côté serveur : elle n’existe pas au sein de la session web.
La web app appelle ensuite les API REST de Power BI, qui transmettent à l’utilisateur un jeton de session. Ce dernier spécifie quel contenu peut être embarqué et à quelle URL y accéder.
Cette méthode suppose que l’utilisateur de la web app a l’autorisation d’y accéder. Là intervient le deuxième mécanisme d’authentification. Les détenteurs de comptes MyPortal sont d’abord séparés en groupes (internes vs externes). Puis on peut filtrer plus finement les accès à deux niveaux. D’un côté, les dashboards. De l’autre, l’URL embarquée dans l’iframe.
Les test de sécurité ont impliqué, entre autres :
– Une tentative de déconnexion puis de renvoi immédiat de requête
– Un essai de connexion directe à l’URL qu’appelle le composant Lightning
– Une vérification de l’éventuelle possibilité de voir les données destinées à un autre utilisateur
Illustration principale © Summit Art Creations – Adobe Stock