基于角色的多级授权的数据库设计

发布于 2024-12-12 02:59:49 字数 328 浏览 2 评论 0原文

我正在 ASP.NET Web-From 中设计一个应用程序，它需要基于角色的多级授权和权限（CRUD 操作）。

它需要对用户访问Web表单以及表单和数据库表上的CRUD操作进行授权。

应用程序的管理员将能够确定哪些角色有权访问特定页面以及有权执行哪些操作。

//More Info :

我正在使用 ASP.NET Web-Form 4.0 和 Entity Framework 4.1 数据库优先方法。

我熟悉 ASP.NET 2.0 成员资格、角色、表单身份验证。

我将不胜感激设计数据库的任何建议或帮助。

原文

I'm designing an application in ASP.NET Web-From which require Multilevel role-based authorization and permission (CRUD Operation ) .

It required to do authorization users at accessing Web-Forms and CRUD Operations On Forms And tables of database .

Administrator of the application would be able to determine which roles has access to specific page and which operation authorized to do .

//More Info :

I'm using ASP.NET Web-Form 4.0 and Entity Framework 4.1 Database First approach.

I'm familiar with ASP.NET 2.0 Membership, Roles, Forms Authentication .

I would appreciate any recommendation or help in designing Database .

分享到QQ

分享到微博

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

发布评论

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

番薯 2024-12-19 02:59:49

如果我理解正确的话，您将拥有一组用户（可能细分为子集：每个子集都是一个组）。

另外：

用户始终是至少一个组的一部分
组可以是另一个组的一部分
实际 ACL 在组级别设置并定义为
每个表格或表格。

所以：

    Item     Type  GroupId     C R U D
   Form001    F    ALL_USERS   N Y N N
   Form001    F    Sales       N R U N
   Form002    F    Admin       N Y Y Y
   All_FORMS  T:F  Admin       Y Y Y Y
   Tab-045A   D    Sales       Y Y Y Y

其中说：
Form001 是一个 (F)orm，每个人都可以阅读它（但不能修改其结构）。
SALES 组的用户也可以使用表格 1 进行更新。
管理员（组）可以修改、删除或使用表单Form002（但不能创建它...）
管理员可以创建新表单。
Tab-045A是一个表，其记录可以由销售组的用户创建/使用/修改/删除。

一些注意事项：

请帮大家一个忙，不要允许在单用户级别设置权限，而始终仅在组级别设置权限。新用户将自动成为 ALL_USERS 的一部分，并且可以稍后添加到其他组（或从其他组中删除）。
最好不仅有表和表单，还有“表单组”（假设表单可以由最终用户创建）。如果情况并非如此，则 CRUD 标志设置中的“C”字段对于表单将变得无用。（表单是用户组可以设计的东西吗？还是它们是应用程序的一部分，就像我认为表格的情况一样？）。
一般来说，您必须为创建/读取/更新/删除定义适当的语义。对于表格，我想这意味着创建一条记录（不是表格），但对于表格来说，目前有点混乱。
上表只是一个示例，并未正确标准化。根据具体情况，您可能必须将其拆分为至少两个表，甚至可能更多。
为了查明用户 X 是否可以对对象 Z 执行操作 Y，您基本上必须查找项目/组表上的权限集，并查看用户 X 属于哪些组。
当用户属于两个不同组时，您必须正确管理这种情况，并始终选择具有最多权限的组或所有权限的并集。
您必须管理以下情况：用户是某个组的一部分，该组是另一个组的子组，并且权限已在更高级别的组中定义。

必须管理组和子组，您最好查看目标数据库中存在哪些类型的设施来管理树结构。你最好通过看几个与此相关的问题来温习一下这个主题。这是一个让您开始的方法，但它不是唯一的方法：

如何在SQL数据库中存储树

If I understand this correctly, you will then have a Set of Users (possibly subdivided in SubSets: each Subset being a Group).

Also:

A User is always part of at least one Group
A Group may be part of another Group
Actual ACLs are set at Group Level and defined for
each Form or Table.

So:

    Item     Type  GroupId     C R U D
   Form001    F    ALL_USERS   N Y N N
   Form001    F    Sales       N R U N
   Form002    F    Admin       N Y Y Y
   All_FORMS  T:F  Admin       Y Y Y Y
   Tab-045A   D    Sales       Y Y Y Y

Which says:
Form001 is a (F)orm and Everyone can Read it (but not modify its structure).
Users from the SALES group can use Form 1 to update, too.
Administrators (a Group) can modify, delete or use Form Form002 (but not create it...)
Administrators can Create new Forms.
Tab-045A is a table, whose records can be created/used/modified/deleted by users from the Sales group.

A few caveats:

Please do everybody a favour and don't allow privileges to be set at the SINGLE USER level but always at group level only. A new user will automatically be part of ALL_USERS, and may be later added to (or removed from) other groups.
It's probably best to have not only Tables and Forms, but "groups of forms" too (assuming forms can be created by end-users). If this is not the case, then the "C" field i the CRUD flags set becomes useless for forms. (Are forms something that a user group can design? or are they part of the application, as I suppose would be the case with Tables?).
In general you have to define the appropriate semantics for Create/Read/Update/Delete. For tables I suppose this means CREATING A SINGLE RECORD (not a table), but for forms it's a bit confused at the moment.
The table above is just an example and is not properly normalized. Depending on specifics you may have to split it into at least two tables, possibly more.
In order to find out if User X can do Operation Y on Object Z you basically have to lookup the permission set on the Item/Group table, and see which groups User X is part of.
You have to properly manage cases when a User is part of two distinct groups, and always choose the one with most permissions, or the union of all permissions.
You have to manage the cases where a User is part of a Group which is a Subgroup of another one, and the privileges have been defined at the higher-level group.

Having to manage groups and subgroups you better look what kinds of facilities exist in your target DB to manage Tree structures. And you better brush up on the subject by looking at a few questions about this. Here is one to give you a start, but it's not the only one:

How to store a tree in SQL database

回复收藏 0 原文

~没有更多了~