0

Je travaille pour la société A. La société A a une société sœur B. Les deux sociétés A et B utilisent la même base de données ERP. J'ai créé un rapport SSRS 2005 qui peut être utilisé par les deux sociétés. Il a un paramètre CompanyID qui détermine s'il faut afficher les données pour la société A ou la société B.SSRS 2005 Sécurité basée sur les paramètres

Pour la plupart des rapports, cela sera OK, mais pour les informations sensibles de l'entreprise (telles que la paie), ce sera un problème puisque toute personne dans l'entreprise A peut changer le paramètre CompanyID en ID de la société B, et vice versa. Mon idée initiale pour gérer ceci était de créer un linked repor t pour chaque entreprise dans leurs propres dossiers respectifs, A et B, où la sécurité sur le dossier A permettait uniquement aux utilisateurs de la société A et au dossier B de n'autoriser que les utilisateurs B. Ensuite, je voudrais ajouter un paramètre CompanyID par défaut à chaque rapport lié et masquer les paramètres de l'utilisateur. Jusqu'ici tout va bien. Le problème avec ceci est que vous pouvez toujours changer les valeurs des paramètres en utilisant la chaîne de requête d'URL. Par exemple, un utilisateur à la société A pourrait changer l'URL du rapport:

http://server/ReportServer/ReportViewer.aspx?/Payroll/A & rs: Command = Render

à:

http://server/ReportServer/ReportViewer.aspx?/Payroll/A & rs: Command = Render & CompanyID = B

Maintenant, ils ont complètement contourné le défaut caché dernier paramètre.

Quelle est une bonne approche pour résoudre ce problème? J'aimerais partager des rapports entre les deux entreprises si possible.

Mise à jour: Nous avons également intranets ASP.NET spécifique de l'entreprise qui restreignent déjà l'accès basé sur la société par domaine AD. Je suppose que je pourrais utiliser le contrôle ReportViewer sur une page intranet pour appliquer les paramètres appropriés à l'exécution. Je pourrais probablement incorporer cette logique dans une page de rapport générique qui pourrait être utilisée pour n'importe quel rapport, n'est-ce pas? (S'il vous plaît excusez mon ignorance, je suis un total SSRS n00b)

Répondre

1

Quel est votre appareil de sécurité ici? Il me semble qu'une solution solide et sécurisée serait de conduire l'accès aux données basées sur le compte de l'utilisateur. Comment les données du rapport sont-elles collectées? Est-ce que SELECT est directement dans votre jeu de données? Appelez-vous des procédures? choisir contre une vue? EDIT: Puisque vous sélectionnez par rapport à une vue qui regroupe les données de l'entreprise, si vous accordez des droits aux vues aux utilisateurs ou aux rôles qui ont accès, vous pouvez créer un scénario dans lequel les données sont renvoyées utilisateur en fonction de leurs droits.

+0

Il s'agit d'une sélection à partir d'une vue qui sélectionne dans les deux tables de l'entreprise avec union tous. – jrummell

+0

Si nous divisons la vue union en deux vues séparées, nous pourrions probablement utiliser les rôles de base de données pour accorder select uniquement sur la vue de l'entreprise appropriée. Est-ce ce à quoi vous faites allusion? – jrummell

+0

Oui, cela devrait créer un moyen transparent d'obtenir uniquement les données appropriées. – keithwarren7

0

Vous pouvez utiliser Expression Based Connection Strings pour ne pas avoir à utiliser les rapports liés, mais cela signifie toujours transmettre des informations en tant que paramètre qui sera exposé dans la requête GET.

Il n'y a pas de problème que vous devez distinguer pour qui le rapport va être affiché/exécuté.

Questions connexes