0

大公司如何实现他们的安全要求，这些要求集中并用于驱动人们可以做的事情（允许调用某个 Web 服务、提交订单等）以及驱动 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（成员资格/AzMan）中看到的任何内容都不会为我们提供所需的粒度和委派要求。ActiveDirectory / Oracle LDAP 集成会很好，但不是必需的。

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

4

1 回答 1

0

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

  • 保护多个应用程序以进行身份​​验证和授权，并从同一中心位置管理所有这些应用程序，无论这些应用程序是 .net 还是非 .net、基于 GUI 或面向流程，

  • 运行的应用程序可能基于 Internet 或基于 Intranet

  • 应用程序应支持 AD 用户或联合用户进行身份验证和授权

  • 应用大量“基于角色”或“基于权限”的安全性或自定义。

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

  • 用于身份验证和授权的安全 Web 服务或 wcf 服务

  • 通过组和用户管理为多租户应用程序应用基于角色的安全性

  • 从中心位置管理多个应用程序的组织用户

  • 跟踪用户的操作或审核。

于 2015-08-03T11:54:14.087 回答