头图

Authorization 意味着通过向 CDS 模型添加相应的声明来限制对数据的访问,然后在服务实现中强制执行这些声明。 通过添加此类声明,我们实质上撤销了所有默认访问权限,然后授予个人权限。

本质上,authentication 负责验证用户的身份和提出的声明,例如授予的角色和租户成员资格,也就是说,揭示了谁使用该服务。 相反,authorization 控制认证后的用户,如何根据授予的权限与应用程序的资源进行交互。 由于访问控制需要依赖经过验证的声明,因此Authentication 是 Authorization 的先决条件。

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

Static User Claims

CDS 授权是模型驱动的。 这基本上意味着它将 CDS 模型元素的访问规则绑定到用户声明。 例如,对服务或实体的访问取决于用户被分配的角色。 或者,甚至可以限制实例级别的访问,例如,对创建实例的用户进行访问。

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

成功认证后,(CAP)用户由以下属性表示:

  • 标识用户的唯一(登录)名称。 未命名的用户有一个固定的名称,例如systemanonymous
  • 多租户应用程序的租户。
  • 管理员授予用户的角色或由身份验证级别派生的角色。
  • 用户已由管理员分配的属性。

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 限制用户对这些属性进行操作:


注销
1k 声望1.6k 粉丝

invalid