SAP CDS entity 中使用 @readonly 进行访问控制
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 注释实体以静态限制所有用户允许的操作,如示例中所示:
使用 @readonly 限制用户对这些属性进行操作:
版权声明: 本文为 InfoQ 作者【Jerry Wang】的原创文章。
原文链接:【http://xie.infoq.cn/article/5cd0918be9e19003beb08ed82】。文章转载请联系作者。
评论