【问题标题】:C# fine-grained permissions: multiple internal systems, intranet scenarioC#细粒度权限:多内部系统、内网场景
【发布时间】:2010-06-28 07:03:50
【问题描述】:

我有以下场景:

  • 多个用户 (
  • AD 中的用户帐户(在不同组下)
  • AD 中的每个组对应一个内部部门;每个部门至少有一名主管
  • (有人可能会说)我们有交叉监督(有适用于一组组的主管角色,即,可能有一个主管实际上监督三个或一组组 - 正如 AD 中存在的那样)
  • 多个内部系统,其中一半基于 Web,全部基于 .Net 框架构建

目前我们有大多数基于桌面的系统通过文件夹权限对用户进行身份验证(使用 ClickOnce 部署在网络环境中,每个部署文件夹都由单个用户授予权限)。但是,这不适用于所有桌面系统;我们有两个使用自己的嵌入式身份验证系统,如下所示:

  • 系统 A 基本上由不同的数据表组成(只是在屏幕上显示一些数据)。

  • 所有的数据表实际上都是相同数据的不同分组;此数据是指特定帐户。

  • 每个帐户行都包含列 {number, owner, type, data1, data2, data3, data4 ...};不同的分组基于数量/所有者/类型。

  • 所有数据(n)列都是数字(分组完成时显示每个分组的总和)

对于这个特定的系统,数据列属于组。因此,AD Group1 中的用户可以看到列数据(1-5),Group2 可以看到列数据(7-9)等等。但是,每个组的主管可以看到他们组的一个额外列(Group1 的主管可以看到 data(1-5) 和 data6 - 我们称之为组的“特殊列”);有主管可以看到其他群组栏目(包括“专栏”或不包含),有普通主管可以看到所有栏目,也有用户可以看到所有非特殊栏目。真是一团糟。

为了解决这个问题,ClickOnce 是不够的;所以基本上开发团队所做的就是嵌入一个特定的授权程序集,它使用当前系统作为参数查询数据库(它支持其他系统)并返回一组列名作为结果;然后将这些结果用于仅检索特定用户列的另一个查询中。

这个旧系统即将被新系统取代;经过大量考虑(包括可维护性 - 系统架构一团糟),因为它只是关于数据检索和以最少的处理显示,我们决定使用(一些)查询并重新编写数据检索逻辑。

最重要的是,大多数现有的基于 Web 的系统都是硬编码许可的(if (sADLogin == "userA") {..});其中一些只依赖于发送给特定用户和手指交叉的超非直观 URL。伤心。

我们希望对权限使用更抽象的方法(这样我们就可以让每个系统都使用相同的身份验证提供程序)。使用 Web 服务/WCF 似乎是合适的(还考虑到我仍然必须验证基于桌面的系统和一些电子表格,可能使用名字);但是我找不到合适的模式或架构模型。 Microsoft 文档中有 one WCF Intranet pattern 解决了大部分问题 - 除了我不能将我的 Windows 组用作角色。但是,有一个 Internet 模式 (http://msdn.microsoft.com/en-us/library/ff650091.aspx),它似乎可以处理角色问题(这就是我现在要处理的问题),但是由于这是我第一次处理 WCF 安全问题,所以我想请一些专家就此事发表意见。

有什么想法吗?

谢谢,

【问题讨论】:

    标签: c# .net wcf-security legacy-code


    【解决方案1】:

    对于基于 Web 的应用程序,这可以通过使用内置 ASP.NET 提供程序模型单点登录到 Active Directory 来解决(请参阅:http://msdn.microsoft.com/en-us/library/aa478948.aspx)。您可以使用 Active Directory 进行身份验证,使用域组进行授权。有几种内置方法可以限制对页面的访问(使用 web.config 中的标签)、对页面某些部分的访问(使用 )以及对代码的访问(使用 User.IsInRole() 或 RolePermission 属性)-一切都会自动进行。对于网络,这是一种标准(互联网或内部网)。

    对于非基于 Web 的应用程序,您实际上仍然可以使用相同提供程序模型的功能。您还可以很容易地在 Active Directory 中查找组成员身份。

    如果您只需要知道某人所在的群组,那么您应该这样做。相反,如果您拥有的那个数据库表有一些更复杂的东西(例如委托授权),那么是的 - 您可能希望在它前面抛出一个 WCF 服务,并让您的所有应用程序都使用它。但是,在 ASP.NET 的情况下,我仍然会使用提供程序模型,并且只编写自己的 RoleProvider,因此我仍然可以使用 ASP.NET 安全性的所有内置功能。希望对您有所帮助。

    【讨论】:

    • 罗布,感谢您的回复。事实上,最后一个模式假设使用 SQL Server 成员资格提供程序;需要的两个自定义是 a) 关于成员身份提供者身份验证(我仍然想根据 AD 对用户进行身份验证 - 业务合规性要求,因此我不会为用户提供另一组登录名)和 b) 自定义角色提供者,所以我2n 个用户不必拥有 n 个左右的角色。
    • 使用 WCF 路径实际上是一种公开身份验证服务的方法,而无需分发身份验证程序集、使用 DCOM 等。只是不确定这是否是可行的方法 - 性能是一个问题,并且系统过于异构(即对于 Windows 环境)。
    • 标记为已回答,因为我没有找到任何合适的替代方案。我现在要使用 CustomRoleProvider。还是谢谢。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2010-10-17
    相关资源
    最近更新 更多