一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第6天，点击查看活动详情。
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 限制用户对这些属性进行操作：