OSBI.FR - Open Source Business Intelligence

Sécuriser les données dans Pentaho Report Designer

Depuis la version 3.6 de Pentaho Report Designer (PRD 3.6), la sécurisation des données renvoyées par le rapport s’effectue désormais directement au sein du moteur de reporting.

Cette sécurisation s’appuie sur les droits applicatifs configurés au niveau du serveur Pentaho (dans la console d’admin), je rappelle d’ailleurs que Pentaho s’appuie sur Spring Security (anciennement Acegi) pour la gestion des droits, et qu’on peut facilement récupérer des groupes et des utilisateurs depuis un annuaire LDAP (Active Directory, OpenLDAP) ou tout autre système d’authentification (base de données par exemple).

Désormais, il n’est donc plus nécessaire de passer par Pentaho Design Studio et la création d’une Xaction pour gérer la sécurité des données d’un rapport, comme on devait le faire jusqu’à la version 3.5 de PRD.

Mon exemple s’appuiera sur la version de démonstration du serveur Pentaho, et notamment la base de test SampleData que tous les habitués de l’OSBI connaissent bien. (Pour plus de détails, consulter la rubrique « Guides et Tutoriels »)

Imaginez par exemple que vous souhaitiez permettre aux utilisateurs Joe, Pat et Suzy de récupérer la liste des clients d’un ou plusieurs pays, avec une structure de rapport comme ci-dessous :

Comment faire pour présenter une liste sécurisée à chacun des utilisateurs afin qu’ils ne puissent récupérer uniquement les clients des pays auxquels ils ont droit ?

Rien de compliqué en fait !

Tout d’abord, on doit stocker dans une base de données les différents pays auxquels les users peuvent accéder, dans mon cas ce sera juste une table d’association intitulée « profiles », avec un stockage en 2nde forme normale:

Cette table est créé dans une base MySql, ci-dessous le script SQL de création et de chargement:

DROP TABLE IF EXISTS `profiles`;
CREATE TABLE `profiles` (
`username` VARCHAR(10) NOT NULL,
`country` VARCHAR(45) NOT NULL
);
 
INSERT INTO `profiles` (`username`,`country`) VALUES
('joe','France'),
('joe','Italy'),
('joe','Spain'),
('suzy','Canada'),
('suzy','USA'),
('pat','Japan'),
('pat','Australia'),
('pat','Hong Kong');
  • Dans Pentaho Report Designer, créer un nouveau rapport avec 2 requêtes :
  • Une Query « Liste Clients » sur la connexion « SampleData » (pour les données du rapport)

  • Une Query « Liste Pays » sur la base de données MySql qui contient la table « profiles » :

Cette requête permettra de charger la liste déroulante « Choix du pays » (voir plus bas), en filtrant les données selon l’utilisateur connecté, via la variable d’environnement env::username

Attention, il faudra impérativement publier le rapport sur le serveur Pentaho pour que la variable d’environnement fonctionne !

  • Créer un paramètre « ChoixPays ».

Ce paramètre permettra de présenter une liste déroulante sécurisée avec seulement les pays autorisés pour chaque utilisateur, en s’appuyant sur la Query « Liste Pays »

On peut choisir un paramètre de type « Multi Value List » pour permettre de sélectionner 1 à N pays :

  • Modifier la requête principale en ajoutant un filtre sur le paramètre « ChoixPays » afin de ne renvoyer que les clients des pays sélectionnées pour chaque utilisateur :

  • Publier le rapport sur le serveur Pentaho

Après avoir publié le rapport sur le serveur, il ne faut pas oublier de donner les droits d’accès au rapport à Suzy et Pat (ils ne sont pas Admin, et ne voient donc pas toutes les nouvelles ressources publiées par défaut).

Cela se fera directement dans la console d’utilisation web de Pentaho en partageant le rapport en exécution (bouton droit sur le fichier prpt, « partager ») :

Il suffit ensuite de se connecter successivement avec les utilisateurs Joe, Suzy et Pat pour vérifier que ces 3 utilisateurs ne peuvent récupérer uniquement la liste des clients auxquels ils ont droit !

Vous pouvez télécharger le rapport final ci-dessous (attention fichier zip, renommer l’extension en prpt):

Bien sûr, il est plutôt conseillé de travailler avec des rôles, dans ce cas on utilisera la variable d’environnement env::roles-array (un tableau qui stocke l’ensemble des rôles auxquels est rattaché l’utilisateur connecté)

Bientôt je publierai dans la rubrique « Guides et Tutoriels » un document complet expliquant de manière détaillée la mise en place des paramètres dans Pentaho Reporting 3.6. (paramètres simples, en cascade, sur du SQL, MQL, XML, Flux Kettle, etc)

Alors si vous n’avez pas tout compris ici… un peu de patience, ce document prochainement disponible sera très explicite et encore plus détaillé !

6 Comments

  1. Bonjour Sylvain,

    deux petites questions sur la sécurisation des rapports.
    La première, si on a plusieurs rapports utilisant les mêmes type de sécurité, l’étape de création de la requête pour la création de la liste de sécurité peut-elle être factorisée? (cela me semble un peu lourd à mettre en place sur plus d’un rapport).

    La seconde, le paramétrage par Xaction fonctionne-t-il encore? Le filtrage des données en amont du moteur de reporting me semble plus simple à mettre en place et surtout à maintenir.
    Si jamais les règles de sécurité sont amenées à changer, il faut repasser sur tous les rapports pour que la sécurité soit appliquée.

    Ludovic

  2. Bonjour Ludovic

    Je suis surpris et heureux de voir que tu t’intéresses encore à Pentaho 😉

    Comme tu peux le constater, Pentaho Report Designer 3.6 permet d’accéder désormais à des variables d’environnement (un peu comme Kettle).
    Certaines variables sont prédéfinies à l’avance car connues par le serveur: « username », « roles », « servername »… mais bien sûr, d’autres objets peuvent être mutualisés au niveau de la session utilisateur, notamment des variables d’environnements permettant de gérer facilement la sécurité avec les rôles (chose conseillée car plus simple à gérer).

    Pour ce qui est de la sécurisation au travers des Xactions cela fonctionne toujours bien sûr. Cependant, depuis Pentaho 3.6, les rapports sont complètements autonomes (source de données, requêtes, paramètres et sécurité sont embarqués), je conseille donc de tout paramétrer dans le design du rappport, ce qui à l’usage est beaucoup plus pratique

  3. J’essaye de me tenir au courant de ce qui se passe dans le monde de l’OSBI ;).

    Ok pour les variables, mais ça implique bien de devoir recréer la requête de sécurisation dans chaque rapport si j’ai bien compris.

    Oui c’est vrai que d’avoir tout sous la main lorsqu’on design est bien plus partique, cette question était surtout pour une question de mise en place, sur un faible volume de rapport à designer, c’est plus commode comme cela que d’avoir le PDI à porté de main pour vérifier la sécurité. Par contre, sur un volume de rapport plus conséquent, la mise en place de la même sécurité me parait un peu redondante, sans compter qu’en cas de changement au niveau des règles de sécurisation il faut repasser sur tous les rapports.

    En tout cas merci pour tes réponses.

  4. Si tu veux mutualiser une requête pour un ensemble de rapports Pentaho sans avoir à les toucher, c’est possible également.
    Dans ce cas il ne faudra plus passer par du SQL direct, mais par la couche d’abstraction fournie par Pentaho Metadata, qui va permettre une abstraction de la couche physique avec en plus une gestion sur la sécurité des colonnes et lignes retournées.

    Comme PRD 3.6 peut utiliser de multiples sources de données en entrée (JDBC, OLAP, Metadata, Kettle, XLS, XML), il suffira d’utiliser comme « populateur » du paramètre « ChoixPays » une requête issue du domaine de métadonnées, et les pays des utilisateurs seront retournés automatiquement en fonction de leurs droits, sans faire quoi que ce soit…

    En espérant avoir répondu à ta question…

  5. Hello,
    Can you please list the possible session variables that we can use.
    I’m using the variable ${[session:username]} in a report parameter which works very well
    but I need to use other variables like Language of the user browser logged into Pentaho console.
    can you please help me to do this?

    My aim is to show the translate the columns of the tables shown in the report Ex:
    for « English user » in the dashbord A table : I show name,region,sales Rank
    for « French user » in the dashbord A table : I show nom, region, top des ventes

    thanks you very much for your help in advance

Les commentaires sont fermés.