授权，我有哪些选择？
应用程序旨在向用户提供功能 - 这是他们的主要目标。但是，通常，并非所有用户都可以在应用程序中执行所有操作：功能可能是敏感的，他们可能需要高级订阅，或者有人可能需要向用户授予显式权限才能访问其数据。提供这种功能“限制”也是应用程序设计的关键部分。本文探讨了控制功能访问的选项，并评估了它们的优点和缺点
应用程序、API 和服务通常需要限制使用者（通常是用户）执行的操作。例如，只有医生才能签署死亡证明，而且只有当他们不是主要照顾者时。我们可以将访问控制定义为“主体可以执行给定的操作吗？组织不断发展。人们在部门之间流动，整个部门的职责也会发生变化。面对这种情况，访问控制也必须适应。因此，任何访问控制系统都需要允许管理员快速有效地更改访问控制决策。
变革不仅仅来自组织内部。安全法规更改可能会影响应用程序需要的工作方式。那么，组织如何证明遵守了新法规呢？监管专家的高效审核对于维持服务的交付至关重要。拥有执行审计的自动化流程可以提高企业对持续合规性的信心。
在软件即服务 （SaaS） 环境中，应用程序可以使用访问控制来保护收入。当客户尝试访问他们尚未订阅的 API 或功能时，应用程序必须拒绝其请求。理想情况下，客户随后订阅，付款，并立即被授予访问权限。理想情况下，访问控制应了解订阅中的即时更改。
访问控制是保护个人数据安全、确保合规性和保护公司收入的守门人。所有业务领域都以这种或那种方式依赖于访问控制，因此使所有利益相关者都可以访问和验证规则会带来显着的好处。
访问控制可能性
多年来，开发人员使用各种技术来实现访问控制：
访问控制列表
访问控制列表 （ACL） 要求管理员对每个资源分配显式权限。更改安全策略或审核意味着访问大量资源，应用程序开发人员必须注意确保所有资源从创建之时起就具有适当的保护。
基于角色的访问控制)
基于角色的访问控制 （RBAC） 在 2000 年代流行，它定义了角色成员身份和权限之间的一系列关系。RBAC 的扩展性优于 ACL，但随着组织的发展，它通常会导致角色爆炸。例如，允许访问客户记录的销售角色最初运行良好。随着组织的扩展和创建地理销售团队，必须对客户记录的访问在地理上受到限制，从而导致美国销售和 EMEA 销售角色。RBAC 是一个大量手动过程，要求 IT 管理员手动更新用户的权限集，从而导致高昂的拥有成本。RBAC可以很好地解决粗粒度访问控制。例如，方案：
具有管理角色的用户可以批准采购订单
它未能提供的是细粒度访问控制，例如：
经理可以批准采购订单，但仅适用于来自其部门的采购订单
为了解决第二种情况，应用程序开发人员需要在应用程序代码中编写额外的检查，从而在两个位置定义访问控制。将安全性驻留在两个位置会导致：
- 安全管理成本高
- 合规和审计成本高
- 没有单一的安全策略视图
RBAC用于管理细粒度访问控制的系统是一个不可持续的手动过程，无法扩展。
声明为权限
许多组织使用某种形式的基于声明的标识解决方案进行访问控制。一旦用户证明了他们是谁，应用程序就可以访问与该用户关联的一组声明。这些声明可以是名字，姓氏，出生日期以及他们在组织内担任的角色。实际上，这些声明与用户的身份有关，例如物理护照或公司ID卡。
标识声明为做出授权决策提供了良好的起点。例如，组织分配经理角色的所有用户都可以创建采购订单;这类似于 RBAC 样式的解决方案，其中应用程序代码将角色映射到权限。纯粹依赖于标识声明可能适用于某些粗粒度解决方案。但是，开发人员通常倾向于使用标识声明来提供细粒度权限。向用户授予细粒度权限几乎可以实现给定用户可以实现的目标的无限可能性。例如，如果我们需要在人力资源部门授予 Sally 执行 Bob 的提货订单工作的临时权限，请将特定权限添加到 Sally：
{
"sub": "1234567890",
"name": "Sally",
"role": "manager",
"department": "personal",
"canRaiseAPurchaseOrder": "true",
"maxValueForPurchaseOrder": "1000",
}
因此，虽然非常灵活，但标识声明方法存在以下问题：
- 很难审核和验证正确的人员是否具有其工作职能的正确权限。
- 重新组织角色和职责是一个手动过程。
- 当员工的工作职能在组织中发生变化时，管理员会添加权限，但很少将其带走。
- 决策数据（）是在安全系统中定义的，几乎可以肯定是从其“事实来源”，即财务系统中复制的。
maxValueForPurchaseOrder - 利用 OAuth 和 OpenID SSO 会导致包含用户完整权限集的大型访问令牌。
- 标识声明正是 – 有关标识的信息。它们不应该是权限。
到目前为止考虑的所有解决方案都具有以下特征：
- 静态规则
- 管理权限的手动过程
- 审计难度大且成本高昂
- 适应组织变化的成本高昂
使用应用程序逻辑的声明
拒绝使用标识声明作为权限后，开发人员通常使用标识声明将访问控制策略添加到应用程序代码中：
{
"sub": "1234567890",
"name": "John Doe",
"role": "manager",
"department": "sales "
}
var maxPo = FindMaxPoValue(department)
If ( role ==‘manager’ && poTotal < maxPo )
此方法的优点是访问控制逻辑可以从其原始系统获取数据。在此示例中，财务系统将设置采购订单限制。然后，访问控制逻辑不是将采购订单限制作为声明交付，而是从财务系统（单一事实来源）中检索它。如果 John 移动部门，则使用的采购订单限制将来自他的新部门。将访问控制逻辑从标识声明添加到应用程序中肯定会达到最佳状态：
- IT 管理员管理标识
- 决策是由信息源驱动的，而不是输入到门禁系统中的副本。
这种方法无法实现的是：
- 易于审计：它需要审计员读取应用程序代码
- 更新访问控制逻辑，无需重新部署应用程序
- 鼓励明确区分关注点
- 与所有利益相关者共享访问控制逻辑
能够提供以下功能的访问控制解决方案是非常可取的：
- 由组织中自然发生的信息驱动
- 无额外管理开销
- 无需重新部署应用程序即可更改
- 所有利益相关者均可阅读
- 可审计
基于属性的访问控制)
其中一种方法是基于属性的访问控制 （ABAC），有时称为基于策略的访问控制。策略不是直接向用户分配访问权限，而是通过评估布尔规则来授予使用者的访问权限。例如，下面是一些允许门禁的规则的伪代码，可以表示为
如果当前时间介于 08：00 和 18：00 之间，并且用户具有员工角色
用于驱动规则的数据称为属性，可以源自任何位置，而不仅仅是标识声明。例如，属性可以是当前时间，也可以是使用者尝试获取访问权限的资源的所有者。
与到目前为止列出的所有其他方法不同，由于需求变化，ABAC 不需要手动设置权限。相反，它需要对策略逻辑进行更改，然后可以立即影响所有主体的访问控制。
ABAC 不是从单个安全系统获取用于驱动策略的属性，而是从组织中的任何位置获取。例如，如果员工移动部门，则 HR 系统将更新，访问控制策略会立即发现由于移动而导致的任何安全后果。ABAC 已经存在了很多年。国家信息与培训中心对 ABAC 有一个正式的定义。正式定义包含以下组件：
- 策略实施点 （PEP）
- 策略决策点
- 策略接入点
- 策略信息点
当 PEP 需要决定是允许还是拒绝请求时，应用程序代码会与 PEP 交互。PEP 为请求构建上下文，并要求 PDP 做出决定。PDP 从 PAP 中提取策略，并使用提供的上下文中的属性并根据策略评估请求，并从 PIP 获取任何必需的其他属性。可以对策略存储中的更改做出反应的 PAP 解决方案会导致立即更改安全策略，而无需重新部署应用程序。
许多 ABAC 解决方案都基于 绿洲 XACML 架构 。顾名思义，它植根于XML。安全专业人员定义 XML 策略或使用图形工具来构建 XML。这就是绿洲XACML倒塌的地方;它不提供非安全专业人员可使用的格式。巴勃罗·詹比亚吉设计了一种XACML的替代方案，称为ALFA，这是一种用于描述绿洲政策的特定于域的语言。以下是ALFA的一个片段，它定义了门禁策略：
namespace AcmeCorp.DoorPolicy
{
import Oasis.Attributes
policy buildingAccess
{
target clause ResourceType == "door"
apply denyUnlessPermit
// Employees can open the door during office hours only
rule openMainDoor
{
target clause Resource == "mainDoor" and
Action == "open"
permit
condition Subject.Role == "employee" and
CurrentTime >= "08:00:00":time and
CurrentTime < "18:00:00":time
}
}
}
ALFA的核心目标是几乎任何人都可以阅读和验证意图。绿洲于 2014 年 3 月采用了 ALFA 作为 XML 的替代方案。使用特定于域的语言编写安全策略允许审计员和业务利益干系人根据组织的职责和不断变化的目标贡献和验证安全策略。
ABAC 在希望提供可扩展的访问控制策略（可由所有人验证）的企业中越来越受欢迎。我们的实施器组件提供了一个基于 ALFA 和绿洲 ABAC 策略模型的 ABAC 解决方案，可帮助您在 .NET 应用程序中实现 ABAC 的强大功能。
上次更新：15年2020月<>日
浙公网安备 33010602011771号