安全架构 - 驱动 UI 和权限（权利）的设置 - 基于角色、每个用户帐户
大公司如何实现他们的安全要求，这些要求是集中的，用于驱动人们可以做的事情（允许调用某个 Web 服务、提交订单等）以及驱动 UI（禁用按钮、菜单选项、个人界面）。表单字段）？
我正在考虑RBAC架构：用户->角色，角色 ->特权。
具有基于许多单独的字段帐户用户角色金额阈值的权限的复杂应用程序将具有许多许多“角色”，并且随着角色数量的增加，管理变得复杂。
管理所有这些可能的选项似乎令人畏惧，我之前的经验是在应用程序中对此类逻辑进行硬编码。
例如：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 来验证用户身份，但所有授权都是在内部完成并存储在经典的“用户、角色、权限”表中。
How do large companies implement their security requirements which are centralized and used to drive things people can do (allowed to call a certain web-service, submit an order, etc.) as well as to drive UI (disable buttons, menu options, individual form fields)?
I am considering RBAC architecture: Users -> Roles, Roles -> Privileges.
Complex applications with permissions based on many individual field-account-user-role-amountThreshhold would have many, many "Roles" and managing this gets complicated as number of roles grows.
Managing all these possible options seems daunting, and my prior experience is to hard-code such logic in the application.
Ex: If (User.Roles("IsAccounting"))
{
btnEditOrder.enabled = false;
}
I am tasked with designing / implementing a security service/architecture which will be used as common authentication/authorization point for any/all applications (all .NET, but some GUI and some process-oriented).
This is not possible out of the box because of the business organization around client accounts and permission tiers based on financial amounts.
Ex: John is a User and he can View and Submit requests for account "Microsoft" and "Google".
Mike can View "Microsoft" and "Google" requests but can only Submit "Google" requests.
Number of accounts / users is large and variable.
If I follow RBAC, there will be hundreds of "Roles" to accommodate all required Rights (Privileges). This doesn't help because the end goal is to give easy to manage GUI tool so that managers can assign their direct reports to appropriate Roles.
I was thinking to implement this security piece with the following API (rough draft in pseudo-code):
UserContext securityContext = Security.GetContext(userID, userPwd);
And usage in application would be like this:if (securityContext.RequestManager.CanSubmitRequest("Google")) {...}
This way there would be thousands of these 'Can(params)' methods to check permissions which doesn't make it easy to either manage or use this pattern.
Any links / ideas / pointers are appreciated.
It's a .NET shop, but nothing I've seen from .NET (Membership / AzMan) will give us the granularity and delegation requirements required. ActiveDirectory / Oracle LDAP integration would be nice, but not necessary.
Old (current) system uses LDAP to authenticate users, but all authorization is done in-house and stored in classic "Users, Roles, Rights" tables.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我们有几乎相同的要求，我们在大型组织内有多个应用程序，并且我们必须
保护多个应用程序以进行身份验证和授权
并从同一中央位置管理所有这些应用程序，无需
无论这些应用程序是 .net 还是非 .net、基于 GUI 或进程
面向，
运行的应用程序可能基于 Internet 或基于 Intranet
应用程序应支持 AD 用户或联合用户
身份验证和授权
应用大量“基于角色”或“基于权限”的安全性或
自定义。
前任。启用/禁用功能 - 例如启用按钮、禁用按钮、隐藏某些菜单、更改控件的背景颜色或更改 .net 组件的任何 .net 支持的属性等。
用于身份验证和授权的安全 Web 服务或 WCF 服务
通过组为多租户应用程序应用基于角色的安全性
和用户管理
管理多个应用程序的组织用户
中心位置
跟踪用户的操作或审核。
We were having almost same requirement, where we had multiple apps inside big organization, and we had to
Secure multiple applications for authentication and authorizations
and manage all these applications from same central location, no
matter these applications are .net or non .net, GUI based or process
oriented,
running applications might be internet based or intranet based
Applications should support AD users or federated users for
authentication and authroziation
Apply lots of 'role based' or 'permission based' security or
customizations.
ex. Enable/Disable features -like Enable buttons, Disable buttons, Hide some menus, Change background color of controls, or change any .net supported properties of .net components etc.
Secure webservice or wcf service for authentication and authorization
apply role based security for multi-tenant applications via groups
and users management
Manage organization's users for multiple applications from
central location
Tracing user's actions or auditing.