客户可配置的 asp.net 网站安全性，用于对页面和按钮访问进行细粒度控制

Posted 2023-03-14

【中文标题】客户可配置的 asp.net 网站安全性，用于对页面和按钮访问进行细粒度控制

【英文标题】：customer-configurable asp.net web site security for fine-grained control of page and button access

【发布时间】：2010-09-15 15:15:32

【问题描述】：

我有一个 ASP.NET 2.0 [还没有 ajax...] 网站，它将以编译的形式部署在多个客户网站上。通常，该站点将仅是 Intranet。一些客户信任他们所有的人，不关心限制对站点和/或页面功能的访问，其他人不信任任何人，只希望某些人和/或组能够查看某些页面、单击某些按钮等人。

我可以做一些本土解决方案，可能从数据库表驱动访问权限，但在我走这条路之前，我想我会问：对于这种情况，什么是好的解决方案？最好可以在 web.config 文件和/或数据库中完全控制，因为重建网站是不可能的（对于客户端，我不想一遍又一遍地为他们做）。 Active Directory 集成将是一个奖励，但不是必需的（除非这更容易）。

作为一个起点，我认为网站中的每个页面/功能点都被赋予一个身份并与一个权限组相关联...

编辑：web.config 授权部分允许/拒绝按角色和用户访问是好的，但这只是问题的一半 - 另一半是控制对每个页面上各个方法（按钮等）的访问。例如，一些用户可以查看 whatchamacallits，而其他用户则可以编辑、创建、删除或禁用/启用它们。所有这些按钮/链接/操作都在视图页面上...

[理想情况下，我会让禁用的按钮不可见，但这并不重要]

编辑：目前有一些很好的建议，但还没有完整的解决方案 - 仍然倾向于数据库驱动的解决方案......

安全权限需求属性会在按钮被点击时抛出异常，这不是一件友好的事情；我宁愿隐藏不允许用户使用的按钮 Lo​​ginView 控件也很有趣，但需要多次复制大部分页面内容（每个角色一次），并且可能无法处理用户拥有多个角色的情况 - 我不能假设角色是分层，因为它们将由客户定义

编辑：平台是 Win2K/XP，Sql Server 2005，ASP.NET 2.0，不使用 AJAX

【参考方案1】：

我认为您需要在这里做的是在您的业务对象或控制器中实现一组权限查询方法。示例：CanRead()、CanEdit()、CanDelete()

页面呈现时，需要查询业务对象，确定用户授权的能力，并根据这些信息启用或禁用功能。反过来，业务对象可以使用角色或其他数据库查询来确定活动用户的权限。

我想不出一种以声明方式集中定义这些权限的方法。它们需要分发到功能的实现中。但是，如果您想改进设计，您可以使用依赖注入将授权者插入到您的业务对象中，从而保持实现分离。

Rocky Lhotka 的书中有一些代码使用了这个模型。 Google 中还没有新版本。

【讨论】：

我开始使用这种方法，但很快就遇到了问题，因为并非所有权限都基于实体访问；有些只是行为上的，相当随意。

查看我的答案的编辑；二进制 AD 组授权加上功能权限似乎可以解决所有要求

【参考方案2】：

我更愿意将访问权限授予 AD 组而不是特定用户。我发现它更灵活。

我对你的应用了解不多，但你可能想看看 web.config 文件中的授权标签：

<authorization>
    <!--  
        <deny users="?" />
        <allow     users="[comma separated list of users]"
                   roles="[comma separated list of roles]"/>
        <deny      users="[comma separated list of users]"
                   roles="[comma separated list of roles]"/>
    -->
</authorization>

您可以在 Web 应用程序中的每个目录中分隔 web.config 文件，并且可以嵌套目录。每个 web.config 文件都可以有自己的授权部分。如果您在每个目录中放置不同的页面，您可以通过在每个 web.config 中允许特定角色并拒绝其他所有内容来有效地严格管理安全性。然后您可以管理活动目录中每个角色的成员。我发现这是一个有效的解决方案，因为它很好地利用了 Microsoft 的 Active Directory 和 ASP.NET 安全框架，而无需编写您自己的自定义内容，而且如果您使用角色，则可以将角色成员的管理分担给无需接触 web.config 文件，他们只需要知道如何使用 AD 管理控制台。

【讨论】：

一个有趣的方法，但只解决了一半的问题 - 一些用户可能能够查看某个页面，但无法点击该页面上的某些按钮...

被接受为“答案”，因此统计页面将不再纠缠我

【参考方案3】：

虽然我以前从未在实践中使用过它并且无法争论它的优点，但我知道 .NET 具有基于角色的代码安全性，它允许您以声明方式按角色或用户锁定方法。例如：

[PrincipalPermissionAttribute(SecurityAction.Demand, Name = "MyUser", Role = "User")]
public static void PrivateInfo()
   
    //Print secret data.
    Console.WriteLine("\n\nYou have access to the private data!");

here 更详细地介绍了基于角色的安全性。我不知道它会对你有多大帮助，但考虑到它需要重新编译才能改变它；然而，在方法上贴标签比构建逻辑来显示/隐藏按钮或在代码中进行安全验证要快。

此外，您还需要在集成 Windows 身份验证上 read up 以获得 Active Directory 的可能性。

【讨论】：

谢谢，但是安全需求属性只会在未经授权的用户单击按钮时抛出异常，这不是一件非常“友好”的事情......

【参考方案4】：

听起来您可以使用LoginView 控件，它可以仅向某些用户或角色显示控件面板。 角色最灵活 - 如果不需要安全性，则将所有用户置于所有角色中。

与标准 web.config 安全性（带有活动目录的集成窗口或表单身份验证（asp 2 Sql 服务器架构或您自己的架构）结合使用。

<asp:LoginView id="LoginView1" runat="server">
                    <RoleGroups>
                        <asp:RoleGroup Roles="Admin">
                            <ContentTemplate>
                                <asp:LoginName id="LoginName2" runat="Server"></asp:LoginName>, you
                                are logged in as an administrator.
                            </ContentTemplate>
                        </asp:RoleGroup>
                        <asp:RoleGroup Roles="User">
                            <ContentTemplate>
                                <asp:Button id="Button1" runat="Server" OnClick="AllUserClick">
                            </ContentTemplate>
                        </asp:RoleGroup>
                    </RoleGroups>
                </asp:LoginView>

【讨论】：

另一种有趣的方法，谢谢 - 但使用这意味着我必须多次复制每个页面的大部分 html，并且不会处理用户可能担任多个角色的情况

【参考方案5】：

我认为我必须将 AD 授权与数据库中的“功能和权限”表结合起来，以获得我们需要的细粒度控制 -

使用 web.config 文件只允许授权用户（通过 AD 组）访问网站 制作一个“功能”表，列出可能受影响的每个页面和功能，例如第 1 页编辑按钮、第 2 页删除按钮、第 3 页详细信息网格等。 制作“权限”表，指定功能和允许使用该功能的 AD 组 更改网站页面以检查页面加载（或预渲染，视情况而定）的功能权限，以酌情禁用/隐藏禁止的功能

例子：

管理员可以使用网站的所有功能 开发者可以使用网站的所有功能 管理员可以查看所有页面，但只能添加和编辑信息，不能删除 主管可以查看所有部门的摘要，但只能查看和编辑自己部门的详细信息（每个部门和部门主管都有一个 AD 组） 员工只能查看其部门的详细信息 等

最终解决方案将“功能”的概念简化为可以使用或不能使用的二元决定，并为每个功能添加了“允许/不允许”标志。这允许将大多数人都可以使用的功能定义为“允许的”，然后权限表只需记录被拒绝使用该功能的组。对于定义为不允许的功能，默认情况下没有人可以使用该功能，您必须为允许使用该功能的组创建权限表条目。这似乎提供了一个两全其美的解决方案，因为它减少了每个功能所需的权限记录数量。