ssrs web服务：Web服务访问所需的基本权限？

Question

我正在为SSRS构建一个轻量级Web界面，其中Web应用程序用户映射到Web应用程序角色，而后者又映射到SSRS用户。

这个错综复杂的方案之所以没有争议：简而言之，不能使用AD组，该站点使用Forms auth并且有固定数量的角色。

 Web Role   | SSRS User

Admin       | AdminUser
Supervisor  | SuperUser
User        | BasicUser
Guest       | GuestUser 

目标是枚举用户有权查看的所有报告，并允许用户使用ReportViewer控件查看报告。

更重要的是，它是为用户，管理员和其他人简化用户体验：防止管理员必须使用报告管理器网站（即，选择复选框而不是手动键入哪些网络角色用户可以访问哪些报告），并提供一个简单的用户界面，用户可以从中查看和执行所有报告。

当用户是AdminUser时，一切正常。

但是，当用户未包含在至少具有浏览器SSRS角色的Home / Root文件夹中的Policy中时，我无法调用Web服务。 （授予用户'computer \ username'的权限不足以执行此操作。）

由于以下几个原因，这是有问题的：

1. 如果每个用户都必须是浏览器才能连接到Web服务并枚举他们有权查看/执行的报告，则默认情况下所有用户都可以访问所有新报告/文件夹。 （儿童自动继承新权限）
2. 如果嵌套文件夹中存在不继承权限且用户不是浏览器但是用户是嵌套报表上的浏览器的报表，则ListChildren()将不会返回该报表。

这似乎给我留下了2 不太理想的选项：

1. 请勿使用不同的用户调用Web服务。相反，仅使用admin用户枚举ListChildren()的报告。然后，对于每个报告，请致电GetPolicies()，然后从该政策集合中确定用户可以查看的报告。
2. 与不同的用户进行通话。默认情况下，每个人都可以访问新发布的报告的缺陷，直到更改权限。除非用户有权访问该路径，否则还会显示嵌套报表的缺陷。如果管理员希望在具有显式权限的文件夹中的嵌套报表可供无法查看该文件夹的用户使用，则必须修改所有祖先文件夹及其子项的策略。

＃1显然非常笨拙且效率低下。但＃2有明显的缺点，变得像繁重的一样。在某些情况下设置权限时效率低下。

有更好的方法吗？我错过了明显的东西吗？

<小时/> 的 [编辑]

第三个选项是使用查询like this直接查询ReportServer数据库。这有利于返回用户有权访问的所有内容，无论它是否存在于用户无法访问的子文件夹中（也就是说，无法使用Web服务的ListChildren方法进行检索）。但是，如果使用AD组，我将不得不知道用户所属的组，而Web服务将为我执行此操作。这个选项对我来说有点像黑客，但它可以工作。

事实证明，我们通过放弃限制Web角色报告访问的要求，围绕此问题运行了一个终点路径，并使我们在Web服务中查询的路径成为可以更改的web.config设置，从而允许报告作者如果将来需要“隐藏”父文件夹中的报告。

Answer 1

最好的解决方案是直接查询ReportServer数据库。

然而，客户改变了他们的想法和最后不想基于Web用户角色限制报表，所以问题解决了！