Authorization 意味着通过向 CDS 模型增加相应的申明来限度对数据的拜访，而后在服务实现中强制执行这些申明。通过增加此类申明，咱们本质上撤销了所有默认拜访权限，而后授予集体权限。

实质上，authentication 负责验证用户的身份和提出的申明，例如授予的角色和租户成员资格，也就是说，揭示了谁应用该服务。相同，authorization 管制认证后的用户，如何依据授予的权限与应用程序的资源进行交互。因为访问控制须要依赖通过验证的申明，因而 Authentication 是 Authorization 的先决条件。

从 CAP 的角度来看，authentication 办法是可自在配置的，通常应用底层平台的地方身份和身份验证服务。针对本地开发场景，CAP 内置了基于 mock 用户的认证。

Static User Claims

CDS 受权是模型驱动的。这基本上意味着它将 CDS 模型元素的拜访规定绑定到用户申明。例如，对服务或实体的拜访取决于用户被调配的角色。或者，甚至能够限度实例级别的拜访，例如，对创立实例的用户进行拜访。

通用 CDS 受权建设在 CAP 用户概念之上，CAP 用户概念是由平台的身份服务确定的具体用户类型的形象。该设计决策使不同的身份验证策略可插入通用 CDS 受权。

胜利认证后，（CAP）用户由以下属性示意：

• 标识用户的惟一（登录）名称。未命名的用户有一个固定的名称，例如 system 或 anonymous。
• 多租户应用程序的租户。
• 管理员授予用户的角色或由身份验证级别派生的角色。
• 用户已由管理员调配的属性。

User Roles

作为访问控制的根底，您能够设计特定于应用程序的概念角色。这样的角色应该反映用户如何与应用程序交互。例如，供应商角色能够形容容许浏览销售文章和更新销售数据的用户。相同，ProcurementManager 能够齐全拜访销售文章。用户能够领有多个角色，这些角色由平台受权治理解决方案中的治理用户调配。

Pseudo Roles

常常须要定义不是基于特定于应用程序的用户角色，而是基于申请的身份验证级别的拜访规定。例如，一项服务不仅能够被辨认的用户拜访，而且还能够被匿名（例如，未经身份验证的）用户拜访。此类角色称为伪角色，因为它们不是由用户管理员调配的，而是在运行时主动增加的。

CAP 以后反对以下预约义的伪角色：

• authenticated-user 指的是（已命名或未命名的）已提交无效身份验证申明（例如登录令牌）的用户。
• system-user 示意用于技术交换的未命名用户。
• any 是指所有用户，包含匿名用户（这意味着无需身份验证的公共拜访）。

伪角色 system-user 容许将技术用户的外部拜访与业务用户的内部拜访离开。技术用户能够来自 SaaS 或 PaaS 租户。此类技术用户申请通常以特权模式运行，对实例级别没有任何限度。例如，将数据复制到另一个零碎的操作须要拜访订阅的 SaaS 租户的所有实体，并且不能裸露给任何业务用户。请留神，system-user 也意味着通过身份验证的用户。
默认状况下，CDS 服务没有访问控制。因而，依据配置的身份验证，CDS 服务最后对匿名用户凋谢。为了依据您的业务需要爱护资源，您能够定义使运行时强制执行适当访问控制的限度。或者，您能够通过受权强制 API 增加自定义受权逻辑。

您能够通过在 CDS 模型中抉择适当的层次结构级别来影响限度的范畴。例如，对 Service 级别的限度实用于服务中的所有实体。

应用 @readonly 或 @insertonly 正文实体以动态限度所有用户容许的操作，如示例中所示：

entity my.bookshop.Addresses as projection on external.A_BusinessPartnerAddress {
  key AddressID as ID,
  key BusinessPartner as businessPartner,
  @readonly Country as country,
  @readonly CityName as city,
  @readonly PostalCode as postalCode,
  @readonly StreetName as street,
  @readonly HouseNumber as houseNumber,
  false as tombstone: Boolean
}

应用 @readonly 限度用户对这些属性进行操作：