Vue d’ensemble des extensions de sécurité - Reporting Services (SSRS)

Une extension de sécurité Reporting Services permet l’authentification et l’autorisation des utilisateurs ou des groupes ; autrement dit, il permet à différents utilisateurs de se connecter à un serveur de rapports et, en fonction de leurs identités, d’effectuer différentes tâches ou opérations. Par défaut, Reporting Services utilise une extension d'authentification Windows, qui utilise des protocoles de compte Windows pour vérifier l'identité des utilisateurs qui prétendent avoir des comptes sur le système. Reporting Services utilise un système de sécurité basé sur les rôles pour l'autorisation des utilisateurs. Le modèle de sécurité Reporting Services basé sur les rôles est identiques aux modèles de sécurité basé sur les rôles d'autres technologies.

Les extensions de sécurité étant basées sur une API ouverte et extensible, vous pouvez créer des extensions d'authentification et d'autorisation dans Reporting Services. L’exemple suivant illustre une implémentation d’extension de sécurité classique qui utilise l’authentification et l’autorisation basées sur les formulaires :

Screenshot of the Reporting Services security extension process.

Comme indiqué dans l'illustration, l'authentification et l'autorisation se déroulent comme suit :

  1. Un utilisateur tente d’accéder au portail web à l’aide d’une URL et est redirigé vers un formulaire qui collecte ses informations d’identification pour l’application cliente.

  2. L'utilisateur indique ses informations d'identification sur le formulaire.

  3. Les informations d'identification de l'utilisateur sont transmises au service Web Reporting Services via la méthode LogonUser.

  4. Le service Web appelle l'extension de sécurité fournie par le client et vérifie que le nom et le mot de passe de l'utilisateur existent dans l'autorité de sécurité personnalisée.

  5. Après l’authentification, le service web crée un ticket d’authentification (appelé « cookie »), gère ce dernier et vérifie le rôle de l’utilisateur pour la page d’accueil du portail web.

  6. Le service web retourne le cookie au navigateur et affiche l’interface utilisateur appropriée dans le portail web.

  7. Une fois l’utilisateur authentifié, le navigateur envoie des demandes au portail web lors de la transmission du cookie dans l’en-tête HTTP. Ces demandes font suite aux actions de l’utilisateur dans l’application du portail web.

  8. Le cookie est transmis dans l'en-tête HTTP au service Web avec l'opération d'utilisateur demandée.

  9. Le cookie est validé et, s’il est valide, le serveur de rapports retourne le descripteur de sécurité et d’autres informations relatives à l’opération demandée à partir de la base de données du serveur de rapports.

  10. Si le cookie est valide, le serveur de rapports effectue un appel vers l'extension de sécurité afin de vérifier si l'utilisateur dispose des autorisations nécessaires pour effectuer l'opération demandée.

  11. Si tel est le cas, le serveur de rapports effectue l'opération demandée et retourne le contrôle à l'appelant.

  12. Une fois l'utilisateur authentifié, l'accès URL au serveur de rapports utilise le même cookie. Le cookie est transmis dans l'en-tête HTTP.

  13. L’utilisateur continue de demander des opérations sur le serveur de rapports jusqu’à ce que la session se termine.

Quand implémenter une extension de sécurité

Nous vous recommandons d'utiliser l'authentification Windows dans la mesure du possible. Toutefois, l’authentification et l’autorisation personnalisées pour Reporting Services peuvent être appropriées dans les deux cas suivants :

  • Vous disposez d’une application Internet ou extranet qui ne peut pas utiliser de comptes Windows.

  • Vous avez des utilisateurs et des rôles personnalisés et devez fournir un schéma d'autorisation correspondant dans Reporting Services.