安全体系结构 - 用于驱动UI和Priveledges的设置（权限） - 基于角色的每个用户帐户

大公司如何实施其集中的安全要求，用于驱动人们可以做的事情（允许呼叫某个网络服务，提交订单等）以及驱动UI（禁用按钮，菜单选项，个人）形式领域）？ 我正在考虑RBAC架构：用户 - >角色，角色 - >权限。 具有基于许多单独的field-account-user-role-amountThreshhold的权限的复杂应用程序将具有许多“角色”，并且随着角色数量的增长，管理这变得复杂。 管理所有这些可能的选项似乎令人生畏，我之前的经验是在应用程序中对这种逻辑进行硬编码。 例如：

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

我的任务是设计/实现一个安全服务/体系结构，它将用作任何/所有应用程序的通用身份验证/授权点（所有.NET，但有些GUI和一些面向流程的）。 由于客户帐户周围的业务组织和基于财务金额的权限层，因此无法开箱即用。 例如：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对用户进行身份验证，但所有授权都在内部完成，并存储在经典的“用户，角色，权限”表中。