Reporting Service et rôle d'application

Première affiche, longtemps caché ici. Quelle est la meilleure façon d'activer le rôle d'application dans un rapport?

J'ai essayé différentes choses et jusqu'à présent, la seule méthode qui fonctionne est d'incorporer l'appel au rôle d'application comme ceci: -

EXEC sp_setapprole 'REPORTZ', 's3cr3t';
select *
from mytable
where ID < 10000

dans l'ensemble de données. Cela fonctionne ... mais pas à mon goût (certainement pas dans la forme que je voudrais utiliser dans l'environnement de production).

Je préférerais que je puisse en quelque sorte `` détourner '' ou `` injecter '' la ligne d'activation du rôle d'application lors de l'exécution via des assemblys personnalisés ou probablement une sorte de `` hook de serveur '' dans Reporting Service (qui, dans les deux cas, je ne sais pas comment )

Très apprécié pour votre temps + votre attention.

YS.

sql-server ssrs role

— YS.
source

vous pouvez commencer à partir d'ici msdn.microsoft.com/en-us/library/aa237582(v=SQL.80).aspx pour comprendre comment étendre Reporting Service (injecter du code qui définit le rôle de l'application), mais je ne prendrais pas ce commentaire comme réponse, je ne suis pas sûr que ce soit le moyen le plus simple et cela ne pourrait pas être fait dans la configuration

selon la façon dont les gens accèdent à ce rapport, vous pouvez incorporer les informations d'identification de l'utilisateur du rapport dans l'ensemble de données, puis configurer le côté du serveur SQL de connexion afin qu'il dispose de privilèges limités.

— DForck42

Salut DForck - tout le système était basé sur l'approle et nous voulons qu'il en soit ainsi.

Je vois deux façons de le faire sans recourir à quelque chose de trop sophistiqué.

La première serait d'utiliser l'authentification intégrée de Windows et d'attribuer des autorisations aux groupes qui représentent les utilisateurs de l'application.
Vous pouvez créer des rôles qui pourraient être accordés, puis utiliser set rolepour assumer le rôle dans votre code dans la base de données. De cette façon, vous ne transmettez pas de mot de passe et vous authentifiez d'abord l'application.

L'avantage du premier est qu'il est facile de gérer, dans un domaine AD, qui a accès à l'application. La gestion serait relativement simple. Les principaux inconvénients seraient qu'elle serait limitée aux cas où l'authentification intégrée a un sens et que vous devriez prendre en charge l'authentification intégrée tout au long du processus. De plus, chaque tronçon finit par nécessiter une authentification à trois voies (entre le serveur, le client et KDC).

L'avantage de la seconde est qu'elle est probablement la plus simple à shim, et qu'elle n'expose aucune information de sécurité sur le réseau, et cela fonctionne dans les cas où l'authentification intégrée ne fonctionnera pas bien.

J'essaierais ces deux approches avant d'essayer d'étendre le service de signalement. Comme le commentaire l'a suggéré, http://msdn.microsoft.com/en-us/library/aa237582%28v=SQL.80%29.aspx peut être utile et peut fonctionner, mais il est conceptuellement plus complexe que d'essayer de gérer des rôles directement.

— Chris Travers
source