Gestion de sécurité SSRS

-
SQL Server Reporting services fonctionne avec l'autorisation basé sur le rôle, et un sous-systéme pour attribuer/octroyer/accorder aux utilisateurs/groupes l'accés aux éléments d'un serveur de rapport.
chaque utilisateur interagit avec le serveur de rapports dans le contexte d'un rôle qui lui définit ses accés attribués.

Reporting services inclut des rôles prédéfinis, qui sont :
  • Content Manager (gestionnaire de contenu) : a la capacité maximale de tout gérer, créer l'arborescence des rapports et les datasources y compris l'attribution de droits à d'autres utilisateurs.
  • Publisher (rôle de publication) a le droit de publier/ajouter des rapports au serveur en plus de la création et gestion des dossiers.
  • Browser (lecteur) a le droit d'exécuter les rapports, voir les dossiers et s'abonner sur des rapports.
  • Report Builder (générateur de rapports)  crée/modifie des rapports dans Report Builder.
  • My report (Mes rapports) a le droit de gérer un espace personnel pour stocker des rapports et les utiliser.
On peut utiliser les rôles existants en mode natif, ou définir ses propres rôles en leur affectant les tâches adèquates (attention aux rôles ambigus). Il existe 2 manières pour y parvenir  :
  • via le portail web de SSRS
  • En passant par la base de données ReportServer
    Pour modifier la configuration par défaut d'un rôle à inclure/exclure des tâches que l'utilisateur peut faire, on peut procéder comme suit : 
           - se connecter à l'instance Reporting Services via SSMS.
          - Aller à Security >> roles >> My Reports  : clic droit sur le rôle "My Reports" afin de  voir/modifier  ses propriètès



les attributions de rôles sur un dossier, sont héritèes , pour rompre ce comportement par défaut, il faut gérer la sécurité sur un élément en particulier.

Commentaires

Enregistrer un commentaire

Posts les plus consultés de ce blog

Comment calculer YTD, MTD en MDX - PeriodsToDate

-
Un besoin récurrent dans les rapports de Business Intelligence est de comparer les mesures à fréquence journalière ou mensuelle (chiffre d’affaire à titre d’exemple) par rapport aux mesures cumulées jusqu’à une date donnée (jour ou mois). Pour cette raison, on utilise fréquemment les notions de YTD (Year-to-Date) et MTD (month-to-Date). Plus souvent les mesures citées précédemment sont calculées dans le cube, d’autres mesures peuvent être rajoutées par ex. QTD (Qurter-to-Date) et WTD (Week-to-Date) Donc, comment calcule-t-on ces mesures en MDX ?  Pour ce faire, il existe des fonctions, à savoir : 1. YTD (member_expression) : est une fonction qui renvoie un ensemble de membres du même parent (sibling), cette liste contient en première position le premier frère et en dernière position le membre spécifié : member_expression. Ex. La fonction utilisée toute seule : YTD([Time].[CalendarMonth].[Month Id].&[201606]) renvoie la liste suivante : J...
Lire la suite

Comment vérifier l'existence d'un fichier avant d'exécuter des tâches

-
Image
Scénario :  Souvent on est amené à vérifier l'existence d'un fichier dans un répertoire avant de lancer l'exécution les tâches restantes dans un package ou pas. Solution :  Pour ce faire, on créée 3 variables dans le package : Folder_Path: nom du répertoire dans lequel on vérifie l’existence du fichier File_Path: pour le chemin absolu du ficher (concaténation du chemin du répertoire et 'MonFichier.txt') File_Exist_Flg : flag qui égal à "1" si le fichier existe, sinon "0" Glisser le composant Script Task et renseigner les variables comme ci-dessous : Le script en C# teste si le fichier existe ou pas, et affecte la bonne valeur à la variable  File_Exist_Flg: On ajoute la contrainte de précédence,  Si le fichier existe, on poursuit l'exécution du flux de données qui suit, sinon, on l'exécute pas.
Lire la suite