Question

大公司如何实施其集中的安全要求，用于驱动人们可以做的事情（允许呼叫某个网络服务，提交订单等）以及驱动UI（禁用按钮，菜单选项，个别表格领域）？

我正在考虑RBAC架构：用户 - ＆gt;角色，角色 - ＆gt;特权。

具有基于许多单个field-account-user-role-amountThreshhold的权限的复杂应用程序将拥有许多“角色”，并且随着角色数量的增长，管理这一点会变得复杂。

管理所有这些可能的选项似乎令人生畏，我之前的经验是在应用程序中对这种逻辑进行硬编码。

例如：If (User.Roles("IsAccounting")) { btnEditOrder.enabled = false; }

我的任务是设计/实现一个安全服务/体系结构，它将用作任何/所有应用程序的通用身份验证/授权点（所有.NET，但有些GUI和一些面向流程的）。

由于客户帐户周围的业务组织和基于财务金额的权限层，因此无法开箱即用。

Ex：John是一名用户，他可以查看和提交帐户“Microsoft”和“Google”的请求。 Mike可以查看“Microsoft”和“Google”请求，但只能提交“Google”请求。

帐户/用户数量很大且可变。

如果我遵循RBAC，将有数百个“角色”来容纳所有必需的权利（特权）。这没有用，因为最终目标是提供易于管理的GUI工具，以便管理人员可以将他们的直接报告分配给适当的角色。

我正在考虑使用以下API（伪代码草案）实现此安全性文件：

UserContext securityContext = Security.GetContext(userID, userPwd);

应用程序中的用法如下： if (securityContext.RequestManager.CanSubmitRequest("Google")) {...}

通过这种方式，会有成千上万的“Can（params）”方法来检查权限，这些方法无法管理或使用此模式。

赞赏任何链接/想法/指示。

这是一个.NET商店，但我从.NET（Membership / AzMan）看到的任何东西都不会给我们所需的粒度和委托要求。 ActiveDirectory / Oracle LDAP集成会很好，但不是必需的。

旧（当前）系统使用LDAP对用户进行身份验证，但所有授权都在内部完成，并存储在经典的“用户，角色，权限”表中。

Answer 1

我们有几乎相同的要求，我们在大型组织内部有多个应用程序，我们必须

离。启用/禁用功能 - 如启用按钮，禁用按钮，隐藏某些菜单，更改控件的背景颜色或更改.net组件的任何.net支持的属性等。