Les bases de l’extension de sécurité de Reporting Services

oeuvre l’interface d’extension de sécurité IAuthenticationExtension et, pour employer l’autorisation personnalisée, vous faites appel à l’interface IAuthorizationExtension. Du point de vue déploiement, votre mise en oeuvre de ces interfaces est compilée dans une DLL.

Vous déployez cette dernière vers le répertoire de Reporting Services et modifiez un ensemble de fichiers de configuration en conséquence. Reporting Services 2000 exploitait cette architecture d’extension de sécurité, et celle-ci n’a pas changé fondamentalement dans la version 2005. Toutefois, Microsoft a amélioré la documentation de l’architecture et fournit désormais un exemple d’extension de sécurité. Vous pourrez consulter les informations détaillées sur les extensions de sécurité dans la documentation en ligne SQL Server 2005, mais voici un résumé des deux interfaces d’extension que nous allons employer :

IAuthenticationExtension.
Cette interface représente une extension d’authentification et contient les trois méthodes suivantes :
• GetUser – Renvoie l’identité de l’utilisateur. Dans un environnement Internet, vous allez généralement obtenir l’identité de l’utilisateur à partir du contexte http du serveur Web (par ex., HTTPContext.Current. User.Identity).
• IsValidPrincipalName – Est appelée lorsque le serveur de rapports définit une sécurité sur un élément. Vous allez configurer cette méthode pour interroger votre référentiel personnalisé d’utilisateurs.
• LogonUser – Sert à soumettre les informations d’identification au serveur de rapports aux fins d’authentification. Après un appel réussi, le serveur de rapports utilise les entêtes HTTP pour passer en retour un ticket d’authentification (par ex., un cookie) au client. Ce dernier se sert du cookie pour les requêtes suivantes pendant le reste de la session. La figure 1 illustre une représentation graphique du flux de ce processus.

IAuthorizationExtension.
Cette interface gère les autorisations via trois méthodes :
• CheckAccess – Cette méthode de surcharge détermine si un utilisateur a l’autorisation d’accéder à un élément (par ex., un rapport) pour une opération de catalogue donnée (par ex., ExecuteReportDefinition). CheckAccess comporte en fait 10 signatures différentes. Par conséquent, pour gagner du temps, je conseille fortement d’utiliser l’exemple de code comme point de départ.
• CreateSecurityDescriptor – Sert à sérialiser la liste de codes d’accès appliquée à un élément de serveur de rapports. Similaire à une liste de contrôle d’accès dans Windows, la liste de codes d’accès contient les droits d’accès de chaque utilisateur sur des éléments de base de données Report Server, notamment des dossiers ou des rapports individuels. Cette méthode est employée par la méthode CheckAccess.
• GetPermissions – Utilisée par la méthode GetPermissions des services Web, elle retourne l’ensemble des autorisations octroyées à un utilisateur donné pour un élément spécifique.

Lorsque j’ai examiné pour la première fois les extensions de sécurité, je me suis demandé s’il était réellement nécessaire de mettre en oeuvre IAuthorizationExtension. Par exemple, prenons l’hypothèse suivante : je souhaite substituer l’authentification par formulaires à l’authentification Windows, mais je ne veux pas remplacer les rôles et tâches prédéfinis employés par mon mode d’authentification pour l’autorisation.

L’extension d’autorisation est alors incontournable. Heureusement, vous pouvez encore utiliser les rôles et tâches au sein de votre logique d’autorisation et c’est ce que nous ferons dans nos exemples. Maintenant que nous avons une connaissance de base des interfaces, nous sommes prêts à nous plonger dans un exemple d’implémentation tout simple.