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

发布于 2024-07-07 07:54:58 字数 880 浏览 6 评论 0原文

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

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

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

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

[理想情况下，我将使禁用的按钮不可见，但这在这里并不重要]

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

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

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

原文

I have an ASP.NET 2.0 [no ajax...yet] web site that will be deployed in compiled form on multiple customer sites. Typically the site will be intranet only. Some customers trust all of their people and don't care about limiting access to the site and/or page functions, others trust no one and want only certain people and/or groups to be able to view certain pages, click certain buttons, et al.

i could do some home-grown solution, possibly drive the access permissions from a database table, but before i go down that road i thought i'd ask in SO: what is a good solution for this situation? preferably one that can be controlled completedly in the web.config file and/or database, since rebuilding the web site is not possible (for the client, and i don't want to have to do it for them over and over). Active Directory integration would be a bonus, but not a requirement (unless that's just easier).

as a starting point, i'm thinking that each page/function point in the site be given an identity and associated with a permission group...

EDIT: web.config authorization section to allow/deny access by role and user is good, but that is only half of the problem - the other half is controlling access to the individual methods (buttons, whatever) on each page. For example, some users can view whatchamacallits while others are allowed to edit, create, delete, or disable/enable them. All of these buttons/links/actions are on the view page...

[ideally i would make the disabled buttons invisible, but that is not important here]

EDIT: some good suggestions so far, but no complete solution yet - still leaning towards a database-driven solution...

security permission demand attributes will throw exceptions when buttons are clicked, which is not a friendly thing to do; i'd much rather hide buttons that the user is not allowed to use
the LoginView control is also interesting, but would require replicating most of the page content several times (once for each role) and may not handle the case where a user is in more than one role - i cannot assume that the roles are hierarchical since they will be defined by the customer

EDIT: platform is Win2K/XP, Sql Server 2005, ASP.NET 2.0, not using AJAX

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

仙气飘飘 2024-07-14 07:54:58

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

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

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

Rocky Lhotka 的书中有一些使用此模型的代码。新版本不在 Google 尚未。

回复收藏 0 原文

傾城如夢未必闌珊 2024-07-14 07:54:58

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

I prefer to grant access rights to AD groups rather than specific users. I find it's much more flexible.

I don't know much about your application, but you might want to look at the authorization tag in the web.config file:

<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>

You can separate web.config files each directory within your web application, and you can nest directories. Each web.config file can have it's own authorization section. If you put different pages in each directory you can effectively tightly manage security by allowing a specific role in each web.config, and denying everything else. Then you can manage members of each role in active directory. I've found this to be an affective solution because it makes good use of Microsoft's Active Directory and ASP.NET security framework without writing your own custom stuff, and if you use roles, it's possible to offload the management of role membership to someone who doesn't ever have to touch the web.config file they just need to know how to use the AD management console.

回复收藏 0 原文

半窗疏影 2024-07-14 07:54:58

虽然我以前从未在实践中使用过它，也无法争论它的优点，但我知道 .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!");
}

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

此外，您还需要阅读有关集成 Windows 身份验证的信息获得 Active Directory 的可能性。

While I've never used this before in practice and cannot argue its merits, I know that .NET has role based code security which allows you to declaratively lock methods down by role or user. For example:

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

Role based security is covered in more detail here. I don't know that it will help you much though considering it will require a recompile to change it; however slapping labels on methods is faster than building logic to show/hide buttons or do security validation in code.

Additionally, you'll want to read up on Integrated Windows authentication to gain the Active Directory possibility.

回复收藏 0 原文

ㄟ。诗瑗 2024-07-14 07:54:58

听起来您可以使用 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>

It sounds like you could use the LoginView control, which can show panels of controls to only certain users or roles.
Roles are most flexible- if no security is required, put all users in all roles.

Use in combination with standard web.config security (integrated windows with active directory, or forms authentication (the asp 2 Sql server schema or your own).

<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>

回复收藏 0 原文

唔猫 2024-07-14 07:54:58

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

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

示例：

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

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