Autorisation dans Reporting Services
L'autorisation est le processus permettant de déterminer si une identité peut se voir accorder le type d'accès demandé à une ressource donnée dans la base de données du serveur de rapports. Reporting Services utilise une architecture d'autorisation basée sur les rôles qui permet à un utilisateur d'accéder à une ressource donnée en fonction de l'attribution de rôle de l'utilisateur pour l'application. Les extensions de sécurité pour Reporting Services contiennent une implémentation d’un composant d’autorisation utilisé pour accorder l’accès aux utilisateurs une fois qu’ils sont authentifiés sur le serveur de rapports. L'autorisation est appelée lorsqu'un utilisateur tente d'effectuer une opération sur le système ou sur un élément du serveur de rapports par le biais de l'API SOAP et via l'accès URL. Ce scénario est rendu possible via l’interface d’extension de sécurité IAuthorizationExtension2. Comme indiqué précédemment, toutes les extensions héritent d' IExtension , l'interface de base pour n'importe quelle extension que vous déployez. IExtension et IAuthorizationExtension2 sont membres de l’espace de noms Microsoft.ReportingServices.Interfaces.
Vérifier l’accès
En matière d'autorisation, l'élément fondamental de toute implémentation de sécurité personnalisée est la vérification de l'accès, qui est implémentée dans la méthode CheckAccess. CheckAccess est appelé chaque fois qu'un utilisateur tente une opération sur le serveur de rapports. La méthode CheckAccess est surchargée pour chaque type d'opération. Pour les opérations de dossier, un exemple d’accès case activée peut ressembler à l’exemple suivant :
// Overload for Folder operations
public bool CheckAccess(
string userName,
IntPtr userToken,
byte[] secDesc,
FolderOperation requiredOperation)
{
// If the user is the administrator, allow unrestricted access.
if (userName == m_adminUserName)
return true;
AceCollection acl = DeserializeAcl(secDesc);
foreach(AceStruct ace in acl)
{
if (userName == ace.PrincipalName)
{
foreach(FolderOperation aclOperation in
ace.FolderOperations)
{
if (aclOperation == requiredOperation)
return true;
}
}
}
return false;
}
Le serveur de rapports appelle la méthode CheckAccess en passant le nom de l'utilisateur connecté, un jeton utilisateur, le descripteur de sécurité de l'élément et l'opération demandée dans le nom de l'utilisateur connecté. Ici, vous devez vérifier le descripteur de sécurité pour le nom d'utilisateur et l'autorisation appropriée pour effectuer la demande, puis retourner true pour indiquer que l'accès est accordé ou false pour indiquer que l'accès est refusé.
Descripteurs de sécurité
Lors de la définition de stratégies d'autorisation sur des éléments dans la base de données du serveur de rapports, une application cliente (telle que le Gestionnaire de rapports) envoie les informations utilisateur ainsi qu'une stratégie de sécurité pour l'élément à l'extension de sécurité. La stratégie de sécurité et les informations utilisateur sont désignées collectivement sous le nom de « descripteur de sécurité ». Un descripteur de sécurité contient les informations suivantes pour un élément dans la base de données du serveur de rapports :
le groupe ou l'utilisateur étant autorisé d'une certaine manière à effectuer des opérations sur l'élément ;
le type de l'élément ;
une liste de contrôle d'accès discrétionnaire qui contrôle l'accès à l'élément.
Les descripteurs de sécurité sont créés à l'aide des méthodes SetPolicies et SetSystemPolicies du service Web.
Flux d’autorisation
L'autorisation Reporting Services est contrôlée par l'extension de sécurité actuellement configurée pour s'exécuter sur le serveur. L'autorisation, basée sur les rôles, est limitée aux autorisations et aux opérations fournies par l'architecture de la sécurité Reporting Services. Le diagramme suivant représente le processus permettant d'autoriser des utilisateurs à manipuler des éléments dans la base de données du serveur de rapports :
Comme représenté dans ce diagramme, l'autorisation suit la séquence suivante :
Une fois authentifié, les applications clientes font des demandes au serveur de rapports par le biais des méthodes du service Web Reporting Services. Un ticket d'authentification est passé au serveur de rapports sous forme d'un cookie dans l'en-tête HTTP de chaque demande Web.
Le cookie est validé avant toute vérification d'accès.
Une fois le cookie validé, le serveur de rapports appelle GetUserInfo et une identité est attribuée à l'utilisateur.
L'utilisateur tente une opération par le biais du service Web Reporting Services.
Le serveur de rapports appelle la méthode CheckAccess.
Le descripteur de sécurité est récupéré et passé à une implémentation d'extension de sécurité personnalisée de CheckAccess. À ce stade, l'utilisateur, le groupe ou l'ordinateur est comparé au descripteur de sécurité de l'élément en cours d'accès et est autorisé à effectuer l'opération demandée.
Si l'utilisateur est autorisé, le service Web effectue l'opération et retourne une réponse à l'application appelante.