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

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.

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

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

我可以做一些自己开发的解决方案,可能会从数据库表中驱动访问权限,但在我走下去之前,我想我会问:在这种情况下,什么是好的解决方案?最好是可以在web.config文件和/或数据库中完全控制的一个,因为重建网站是不可能的(对于客户端,我不想一遍又一遍地为它们做这件事)。 Active Directory集成将是一个奖励,但不是一个要求(除非这更容易)。

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

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

[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

LoginView控件也很有趣,但需要多次复制大部分页面内容(每个角色一次),并且可能无法处理用户在多个角色中的情况 - 我不能认为这些角色是分层的,因为它们是将由客户定义

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

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

5 个解决方案

#1

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

我更愿意为AD组而不是特定用户授予访问权限。我觉得它更灵活。

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

我对您的应用程序了解不多,但您可能希望查看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>

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.

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

#2

I think what you need to do here is implement a set of permissions query methods in either your business objects or your controller. Examples: CanRead(), CanEdit(), CanDelete()

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

When the page renders, it needs to query the business object and determine the users authorized capabilities and enable or disable functionality based on this information. The business object can, in turn, use Roles or additional database queries to determine the active user's permissions.

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

I can't think of a way to declaratively define these permissions centrally. They need to be distributed into the implementation of the functions. If you want do improve the design, however, you could use dependency injection to insert authorizers into your business objects and thus keep the implementations separate.

我想不出一种集中声明性地定义这些权限的方法。它们需要分配到函数的实现中。但是,如果要改进设计,可以使用依赖项注入将授权程序插入到业务对象中,从而使实现保持独立。

There's some code that uses this model in Rocky Lhotka's book. The new version isn't in Google yet.

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

#3

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:

虽然我以前从未在实践中使用过这个并且无法论证其优点,但我知道.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!");
}

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.

此外,您还需要阅读集成Windows身份验证以获得Active Directory的可能性。

#4

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.

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

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

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

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

#5

i think i'm going to have to combine AD authorization with 'features and permissions' tables in the database in order to get the fine-grained control that we need -

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

• use the web.config file to allow only authorized users (via AD groups) to visit the web site

使用web.config文件仅允许授权用户(通过AD组)访问该网站

• make a 'features' table listing each page and feature that can be affected, e.g. page 1 edit button, page 2 delete button, page 3 detail grid, etc.

制作一个“功能”表,列出可能受影响的每个网页和功能,例如:第1页编辑按钮,第2页删除按钮,第3页详细网格等

• make a 'permissions' table specfying a feature and an AD group that is allowed to use the feature

制作一个“权限”表,用于指定允许使用该功能的功能和AD组

• alter the site pages to check feature-permissions on page-load (or prerender, as appropriate) to disable/hide forbidden features as appropriate

更改网站页面以检查页面加载(或适当时为预渲染)的功能权限,以根据需要禁用/隐藏禁用的功能

examples:

• Administrators can use all features of the site

管理员可以使用该站点的所有功能

• Developers can use all features of the site

开发人员可以使用该网站的所有功能

• Managers can view all pages, but can only add and edit information, no deletions

管理员可以查看所有页面,但只能添加和编辑信息,不能删除

• Supervisors can view summaries for all departments, but see and edit details only for their own department (there is an AD group for each department and dept-supervisor)

主管可以查看所有部门的摘要,但只能查看和编辑自己部门的详细信息(每个部门和部门主管都有一个AD组)

• Staff can view details only for their department

工作人员只能查看其部门的详细信息

• etc.

The final solution reduced the notion of 'feature' to a binary can-use or cannot-use decision, and added a 'permissive/not-permissive' flag to each feature. This allows features that most everyone can use to be defined as 'permissive', and then the permissions table only has to record the groups that are denied permission to use that feature. For a feature defined as not-permissive, by default no one can use the feature and you have to create permission table entries for the groups that are allowed to use the feature. This seems to give a best-of-both-worlds solution in that it reduces the number of permission records required for each feature.

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