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

我正在为SSRS构建一个轻量级Web界面，其中Web应用程序用户映射到Web应用程序角色，然后映射到SSRS用户。ssrs web服务：Web服务访问所需的基本权限？

这个复杂的计划的原因是没有争议的：简而言之，AD组不能使用，该网站使用Forms身份验证，并有固定数量的角色。

Web Role | SSRS User 

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

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

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

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

但是，如果用户未包含在至少具有浏览器SSRS角色的Home/Root文件夹中的策略中，则无法调用Web服务。（授权给用户计算机\用户名“的权限不足，无法执行此操作。）

这是有问题的一对夫妇的原因：

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

看来，这给我留下了理想选项少2 ：

不要用不同的用户调用Web服务。相反，只使用管理员用户枚举报告ListChildren()。然后，对于每个报告，请拨打GetPolicies()，并从该组策略中确定用户能够查看哪些报告。

拨打不同用户的电话。生活在新出版报告的缺陷中，默认情况下每个人都可以访问，直到权限发生变化。除非用户有权访问该路径，否则还会生活在嵌套报告的陷阱中。如果管理员希望具有显式权限的文件夹中的嵌套报表对于无法看到该文件夹的用户可用，则必须修改所有祖先文件夹及其子级上的策略。

＃1显然非常笨拙和低效。但＃2有明显的缺点，并且在某些情况下设置权限时会变得效率低下，效率不高。

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

[编辑]

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

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

来源

2014-02-10 JoeBrockhaus

您是否已将SSRS配置为使用表单身份验证，还是您的“SSRS用户”AD帐户？ – kyzen

他们是有效的AD帐户（本地Windows用户） – JoeBrockhaus

将配置SSRS使用表单auth，连接到您的现有用户数据库的凭据池是一个选项吗？您大概也可以桥接您在其他系统中的任何基于角色的安全规则。 – kyzen

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

但客户改变主意&不想限制基于web用户角色的报表最终解决问题！

来源

2014-02-13 18:33:24 JoeBrockhaus

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

回答

相关问题