C#细粒度权限：多个内部系统、内网场景
我有以下场景：
- 多个用户（<100）
- 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是不够的；所以基本上开发团队所做的就是嵌入一个特定的授权程序集，该程序集使用当前系统作为参数（它支持其他系统）查询数据库并返回一组列名作为结果；然后，这些结果将用于另一个仅检索特定用户列的查询。
这一遗留系统即将被新系统所取代；经过大量考虑（包括可维护性 - 系统架构一团糟），因为它只是以最少的处理进行数据检索和显示，所以我们决定使用（部分）查询并重写数据检索逻辑。
最重要的是，大多数现有的基于网络的系统都是硬编码许可的（if (sADLogin == "userA") {..}）；其中一些仅依赖于发送给特定用户的超不直观的 URL，并祈祷。伤心。
我们希望使用更抽象的权限方法（这样我们就可以让每个系统使用相同的身份验证提供程序）。使用 Web 服务/WCF 似乎很合适（还考虑到我仍然必须验证基于桌面的系统和一些电子表格，也许使用名字）；但是我找不到合适的模式或架构模型。 Microsoft 文档中有一个 WCF Intranet 模式可以解决大部分问题- 除了我不能使用我的 Windows 组作为角色之外。有一种 Internet 模式 (http://msdn.microsoft.com/en- us/library/ff650091.aspx），但是，这似乎可以解决角色问题（这就是我现在要做的），但由于这是我第一次处理 WCF 安全性，我希望一些专家对此事的看法。
有什么想法吗？
谢谢，
I have the following scenario:
- Multiple users (< 100)
- User accounts in AD (under different groups)
- Every group in AD corresponds to a internal department; each department have at least one supervisor
- (One may say) We have cross-supervisioning (there are supervisor roles appliable to group of groups, i.e., there may be one supervisor that actually supervises three or for groups - as existent in AD)
- Multiple internal systems, half of them web-based, all of them built over .Net framework
Currently we have most of desktop-based systems authenticating users by folder permissions (deployed in network environment using ClickOnce, each deployment folder permissioned by individual users). That does not work for all desktop systems, though; we have two of them using their own embedded authentication system, as follows:
System A consists basically of different datatables (just shows some data in the screen).
All of the datatables are actually different groupings of the same data; this data refers to specific account.
Every account row contain the columns {number, owner, type, data1, data2, data3, data4 ...}; the different groupings are based on number/owner/type.
All of the data(n) columns are numbers (the sum for each grouping is displayed when grouping is done)
For this specific system, the data columns are attributed to groups. So, users in AD Group1 can see columns data(1-5), Group2 can se columns data (7-9) and so on. However, supervisor for each group can see one extra column for their group (supervisor of Group1 can see data(1-5) and data6 - lets call it "special column" for the group); there are supervisors who can see other groups columns (either including the "special column" or not), there are general supervisors who can see all of the columns and there are also users who can see all of the non-special columns. It's a mess.
In order to solve this problem ClickOnce is not enough; so basically what the dev team did was to embed a particular authorization assembly, which queries a database using the current system as a parameter (it supports other systems) and returning a set of column names as results; these results are then used in another query that retrieves only the specific user columns.
This legacy system is about to be replaced by a newer one; after a lot of consideration (including maintainability - the system architecture is a mess), since it's just about data retrieval and displaying with minimal processing we decided to use (some of) the queries and re-write the data retrieval logic.
On top of that, most of the existing web-based systems are hard-code permissioned (if (sADLogin == "userA") {..}); a few of them only rely on ultra-non-intuitive URLs sent to specific users and fingers crossed. Sad.
We'd like to use a more abstract approach for permission (so we can make every system use the same authentication provider). Using web services/WCF just seems appropriate (also considering that I still have to authenticate desktop-based systems and some spreadsheets, maybe using monikers); however I couldn't find an adequate pattern or architecture model for it. There is one WCF Intranet pattern in Microsoft documentation that solves most of it - except that I can't use my Windows Groups as roles. There is an Internet pattern (http://msdn.microsoft.com/en-us/library/ff650091.aspx), however, that seems to handle the roles problem (that's what I'm going with right now), but since it's my first time dealing with WCF security I'd like to have some expert opinions on this matter.
Any ideas?
Thanks,
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（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 安全性的所有内置功能。希望有帮助。
For web-based applications, this can be simply solved with single-signon to Active Directory using the built-in ASP.NET Provider Model (see: http://msdn.microsoft.com/en-us/library/aa478948.aspx). You can use Active Directory for authentication, and domain groups for authorization. There are several built-in ways you can limit access to pages (using tags in web.config), access to certain parts of a page (using ), and access to code (using User.IsInRole() or RolePermission attribute) - that all works automatically. For web, this is sort of the standard (internet or intranet).
For non-web-based applications, you can actually still use features of that same provider model. You can also pretty easily look up group membership in Active Directory.
If all you need is to know what groups someone is in, this is probably how you should do it. If instead, that database table you have, has something more complicated (like delegation authorization), then yeah - you may want to throw a WCF service in front of that, and have all your applications use that. However, in the case of ASP.NET, I'd STILL use the provider model, and just write my own RoleProvider, so I could still use all the built-in features of the ASP.NET security. Hope that helps.