Report Builder 2.0 est un outil fantastique pour l’utilisateur final (j’y reviendrai très prochainement avec un Webcast). Il nécessite néanmoins un peu de préparation de la part de l’administrateur Reporting Services afin de donner les bons droits aux utilisateurs sans ouvrir les vannes.

Je décris ici les permissions minimums à accorder aux utilisateurs de Report Builder et quelques bonnes pratiques afin d’éviter le syndrome « Je mets tout le monde Administrateur« .

Quelques mots sur la sécurité

Sans faire tout un article sur la sécurité de Reporting Services, il faut savoir qu’elle est basée sur des rôles donnant accès aux différentes tâches élémentaires de Reporting (afficher un rapport, créer un répertoire, etc.). Pour autoriser des utilisateurs, on leur assigne un ou plusieurs rôles.

Deuxième point important à intégrer, la sécurité est héritée ; c’est à dire que l’affectation à un rôle au niveau racine se propage à tous les niveaux enfants. On peut bien évidemment casser cette sécurité pour une branche donnée de l’arborescence. D’ailleurs, une première bonne pratique est de sécuriser plus fortement le niveau racine et d’affecter des droits de plus en plus fins en descendant dans l’arborescence.

My Reports

Parmi les fonctionnalités de Reporting Services, il existe la notion de « My Reports » qui permet à chaque utilisateur d’avoir un répertoire privé dans lequel il peut créer et modifier des rapports, visibles que de lui (et de l’administrateur). Cette fonctionnalité, qui s’active depuis Management Studio (clic droit->Propriétés), semble idéale pour nos utilisateurs finaux. Le souci est qu’il faut donner des droits sur le répertoire racine pour atteindre ce répertoire spécial, rendant visible du coup les autres répertoires et éléments du niveau racine et des niveaux en héritant (cf. la bonne pratique évoquée ci-dessus). 

Le seul compromis possible est de créer un rôle spécifique pour le dossier racine permettant de ne voir que les dossiers et de casser l’héritage de sécurité pour tous les sous-niveaux.

Que l’on utilise ou pas la fonctionnalité « My Reports » (moi je préfère créer un répertoire de travail fixe pour tous les utilisateurs d’un même service/groupe), il va falloir associer nos utilisateurs aux bons rôles. A notre disposition, nous avons les rôles suivants :

• My Reports : donne tous les droits nécessaire à la création/modification de rapports (attention, à ne mettre QUE sur le répertoire My Reports)
• Report Builder : permet de voir et d’ouvrir des rapports existants (+ les abonnements mais ce n’est pas le sujet)

Pour moi, le premier est trop permissif et le second ne permet pas la modification. Rappelons que le but pour l’utilisateur final est de pouvoir créer ses propres rapports ou bien modifier un rapport existant (j’ai souvent des demandes de mises en page pour lesquelles je n’ai pas de valeur ajoutée en tant que consultant). En plus, il va falloir gérer des points importants comme les droits sur les modèles et sources de données ainsi que la prévisualisation…

Ma solution

Je vais vous livrer ma solution à la problématique de droits minimums pour l’utilisateur final.

1. Je mets l’utilisateur dans le rôle « Report Builder » au niveau racine afin qu’il puisse naviguer et ouvrir les rapports existants. Je prends soin de casser l’héritage de sécurité pour des répertoires sensibles (souvent les RH).
2. Je crée un répertoire de validation afin que les utilisateurs puissent enregistrer leur travail (création ou modification). Je mets l’utilisateur dans le rôle « Publisher » afin qu’il puisse sauvegarder.
   J’utilise cette notion de répertoire de validation afin d’éviter les erreurs de manipulation et qu’un utilisateur ne corrompe un rapport existant.
3. Je donne les droits en lecture sur les sources de données. Le rôle « Report builder » permet d’accèder aux modèles de données mais pas aux sources de données, ce qui est gênant dans un cadre multidimensionnel. J’ajoute donc la tâche « View data sources » dans le rôle « Report Builder » (voire je crée un nouveau rôle juste pour cela).
   J’affecte ce rôle au répertoire contenant les sources de données pour une création de rôle dédié ou bien à toute l’arborescence, ce qui a déjà été fait dans l’étape 1.

   

4. Il reste un droit à donner à l’utilisateur : ExecuteReportDefinition pour permettre la prévisualisation directement dans Report Builder. Ce droit fait partie du rôle système (au niveau serveur) System User. Comme je ne veux pas affecter ce rôle à mes utilisateurs finaux, je crée un rôle système spécifique, ne contenant que ce droit.

   

Voila, notre utilisateur final peut installer Report Builder 2.0 (et le Framework 3.5 SP1) et vous n’avez qu’à lui configurer le Report Server par défaut et préparer les modèles et sources de données partagées.

Il ne reste plus qu’à désigner un utilisateur référant pour déplacer les rapports du répertoire de validation vers leur emplacement définitif. Le rôle Publisher est adéquat pour ce travail même si je préfère en créer un plus limité (qui n’aura pas d’accès aux modèles et sources de données).