安全体系结构-驱动UI和特权的设置(权限)-基于角色，每个用户帐户 [英] Security Architecture - Settings to drive UI and Priveledges (Rights) - Role-Based, per User-Account

问题描述

大公司如何实施集中化的安全要求，并用来驱动人们可以做的事情(允许调用某些Web服务，提交订单等)以及驱动UI(禁用按钮，菜单)选项，单个表单字段)?

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)?

我正在考虑RBAC架构:用户->角色，角色->特权.

I am considering RBAC architecture: Users -> Roles, Roles -> Privileges.

具有基于许多单独的field-account-user-role-amountThreshhold权限的复杂应用程序将具有许多角色"，并且随着角色数量的增加，管理该角色变得越来越复杂.

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.

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

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

我的任务是设计/实施安全服务/体系结构，将其用作任何/所有应用程序(所有.NET，但有些GUI和某些面向过程的)的通用身份验证/授权点.

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.

例如:John是用户，他可以查看和提交对帐户"Microsoft"和"Google"的请求. Mike可以查看"Microsoft"和"Google"请求，但只能提交"Google"请求.

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.

如果我遵循RBAC，将有数百个角色"可以容纳所有必需的权利(特权).这无济于事，因为最终目标是提供易于管理的GUI工具，以便管理员可以将其直接报告分配给适当的角色.

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.

我当时正在考虑使用以下API(伪代码中的草稿)实现此安全性部分:

I was thinking to implement this security piece with the following API (rough draft in pseudo-code):

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

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

And usage in application would be like this: if (securityContext.RequestManager.CanSubmitRequest("Google")) {...}

这样，将有成千上万个这样的"Can(params)"方法来检查权限，这使得管理或使用此模式变得不容易.

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.

这是一个.NET商店，但是我从.NET(成员资格/AzMan)看到的任何内容都无法满足我们所要求的粒度和委派要求. ActiveDirectory/Oracle LDAP集成会很好，但不是必需的.

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.

旧的(当前)系统使用LDAP验证用户身份，但是所有授权均在内部完成，并存储在经典的用户，角色，权限"表中.

Old (current) system uses LDAP to authenticate users, but all authorization is done in-house and stored in classic "Users, Roles, Rights" tables.

推荐答案

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

We were having almost same requirement, where we had multiple apps inside big organization, and we had to

• 保护多个应用程序的身份验证和授权 并从同一中央位置管理所有这些应用程序 这些应用程序是.net还是非.net，基于GUI或进程

• 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,

正在运行的应用程序可能是基于Internet或基于Intranet

running applications might be internet based or intranet based

应用程序应支持AD用户或联盟用户 身份验证和授权

Applications should support AD users or federated users for authentication and authroziation

应用很多基于角色"或基于权限"的安全性，或者 自定义.

Apply lots of 'role based' or 'permission based' security or customizations.

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

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.

• 保护Web服务或wcf服务以进行身份​​验证和授权

• 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.

这篇关于安全体系结构-驱动UI和特权的设置(权限)-基于角色，每个用户帐户的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！