Vue d’ensemble des extensions de sécurité

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 basée sur Windows, qui utilise des protocoles de compte Windows pour vérifier les identités des utilisateurs qui prétendent avoir des comptes sur le système. Reporting Services utilise un système de sécurité basé sur des rôles pour autoriser les utilisateurs. Le modèle de sécurité en fonction du rôle Reporting Services est similaire aux modèles de sécurité basés sur les rôles d’autres technologies.

Étant donné que les extensions de sécurité sont basées sur une API ouverte et extensible, vous pouvez créer de nouvelles extensions d’authentification et d’autorisation dans Reporting Services. Voici un exemple d’implémentation d’extension de sécurité classique qui utilise l’authentification et l’autorisation basées sur les formulaires :

processus

Comme illustré dans l’illustration, l’authentification et l’autorisation se produisent comme suit :

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

2. L’utilisateur envoie les informations d’identification au formulaire.

3. Les informations d’identification de l’utilisateur sont envoyées au service web Reporting Services via la LogonUser méthode.

4. Le service Web appelle l’extension de sécurité fournie par le client et vérifie que le nom d’utilisateur et le mot de passe 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 le ticket et vérifie le rôle de l’utilisateur pour la page d’accueil du Gestionnaire de rapports.

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

7. Une fois l’utilisateur authentifié, le navigateur envoie des requêtes au Gestionnaire de rapports tout en transmettant le cookie dans l’en-tête HTTP. Ces demandes sont en réponse aux actions de l’utilisateur dans l’application Gestionnaire de rapports.

8. Le cookie est transmis dans l’en-tête HTTP au service Web, ainsi que l’opération 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 à l’extension de sécurité pour vérifier si l’utilisateur est autorisé à effectuer l’opération spécifique.

11. Si l’utilisateur est autorisé, 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’à la fin de la session.

Quand implémenter une extension de sécurité

Nous vous recommandons d’utiliser l’authentification Windows si 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 disposez d’utilisateurs et de rôles définis sur mesure et devez fournir un schéma d’autorisation correspondant dans Reporting Services.

Voir aussi

Implémentation d’une extension de sécuritéconfigurer le Gestionnaire de rapports pour passer des cookies d’authentification personnalisée