我正在为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'的权限不足以执行此操作。)
由于以下几个原因,这是有问题的:
ListChildren()
将不会返回该报表。 这似乎给我留下了2 不太理想的选项:
ListChildren()
的报告。然后,对于每个报告,请致电GetPolicies()
,然后从该政策集合中确定用户可以查看的报告。 #1显然非常笨拙且效率低下。但#2有明显的缺点,变得像繁重的一样。在某些情况下设置权限时效率低下。
有更好的方法吗?我错过了明显的东西吗?
<小时/> 的 [编辑]
第三个选项是使用查询like this直接查询ReportServer数据库。这有利于返回用户有权访问的所有内容,无论它是否存在于用户无法访问的子文件夹中(也就是说,无法使用Web服务的ListChildren方法进行检索)。但是,如果使用AD组,我将不得不知道用户所属的组,而Web服务将为我执行此操作。这个选项对我来说有点像黑客,但它可以工作。
事实证明,我们通过放弃限制Web角色报告访问的要求,围绕此问题运行了一个终点路径,并使我们在Web服务中查询的路径成为可以更改的web.config设置,从而允许报告作者如果将来需要“隐藏”父文件夹中的报告。
答案 0 :(得分:0)
最好的解决方案是直接查询ReportServer数据库。
然而,客户改变了他们的想法和最后不想基于Web用户角色限制报表,所以问题解决了!