CAS单点登录（第7版）7.授权

如有疑问，请看视频：CAS单点登录（第7版）

授权
1. 概述
  1. 授权和访问管理

可以使用以下策略实施授权策略以保护 CAS 中的应用程序和依赖方。

1. 1. 1. 服务访问策略

服务访问策略允许您定义授权和访问策略，以控制对向 CAS 注册的应用程序的入口访问。此策略通常最适合基于 Web 的应用程序，而不管身份验证协议如何，并强制执行 Course-grained 访问策略来描述谁有权访问给定应用程序。一旦访问被授予，授权策略以及扩展后的 CAS 本身就完全不再干预，接下来由应用程序自身决定经过身份验证的主体在应用程序中被允许做什么或访问什么，这通常基于用户权限、组成员身份和其他属性。

在此处（服务与应用）阅读有关此主题的更多信息。

1. 1. 1. 细粒度授权

细粒度授权将允许您使用专用语言模型构建细粒度权限改造。该策略超越了控制向CAS注册的应用程序的入口访问，并允许您定义和开发详细的授权规则，以确定是否允许访问给定的API请求、资源或操作。此类API请求通常由API网关代理，该网关将充当PEP（授权执行），将请求路由到CAS，然后充当PDP（策略定义点）。

在此处阅读有关此主题的更多信息。

1. Heimdall
  1. Heimdall 授权

Heimdall 是一个简单的基于规则的授权引擎，其主要职责是接受 HTTP 有效负载形式的授权请求，并以 HTTP 响应代码的形式返回是允许还是拒绝请求的决定。您可以将此授权引擎放在 API 网关和反向代理后面，以保护您的 API 和服务，并允许它们制定对 CAS 的授权请求，接收响应并将其转换回调用方。

在北欧神话中，Heimdall是守护入侵者的神和守门人，并被证明拥有先见之明和敏锐的感官。作为看门人，他负责彩虹桥 Bifrost 并密切关注乘客。

一般流程可使用以下步骤进行总结：

可授权资源已向 CAS 注册

…使用适当的方法、URI、命名空间和上下文
…使用适当的授权策略

授权请求已提交给 CAS

…与适当的校长/科目
…使用适当的方法、URI、命名空间和上下文

CAS 根据请求查找匹配的可授权资源

…然后根据请求确定主体/主题

然后，CAS 会咨询授权引擎，以根据资源、委托人和请求做出决策
CAS 向调用方返回响应，接受或拒绝请求

用法

请注意，CAS 只是充当策略定义点（PDP）和策略信息点（PIP）。授权执行（PEP）必须由调用方在其他地方进行，这通常发生在 bean API 网关或 nginx 反向代理等上。

1. 1. 1. 配置

通过在覆盖中包含以下依赖项来启用 Heimdall 授权支持：

Apache Maven

Gradle

BOM - Spring

BOM - Gradle

资源

dependencies {

The following platform references should be included automatically and are listed here for reference only.

implementation enforcedPlatform("org.apereo.cas:cas-server-support-bom:${project.'cas.version'}")

implementation platform(org.springframework.boot.gradle.plugin.SpringBootPlugin.BOM_COORDINATES)

implementation "org.apereo.cas:cas-server-support-heimdall"}

CAS 配置目录中提供了以下设置和属性：

必填

笔记

下面列出的配置设置在 CAS 配置元数据中标记为 Required。此标志表示可能需要该设置的存在才能激活或影响 CAS 功能的行为，并且通常应进行审查、可能拥有和调整。如果为该设置分配了默认值，则无需严格将该设置放在配置副本中，但仍应对其进行检查以确保它符合您的部署预期。

Show entries

搜索：

· cas.heimdall.json.location=

在 CAS 能够自动监视底层资源的更改并动态检测更新和修改的情况和场景中，您可以将以下设置指定为环境变量或系统属性，其值为 false，以禁用资源观察程序：org.apereo.cas.util.io.PathWatcherService。

org.apereo.cas.configuration.model.SpringResourceProperties.

如何配置此属性？

显示 1 到 1 的 1 个条目

1. 1. 1. 授权请求

授权请求是一个简单的负载，它使用终端节点 /heimdall/authorize 通过 POST 发送到 Heimdall 授权引擎。有效负载具有以下结构：

{

"method" : "POST",

"uri" : "/api/example?hello=world",

"namespace" : "API_EXAMPLE",

"context" : {

"key" : "value"

}}

…它试图询问 CAS：

是否允许使用 HTTP 方法 POST 对 API_EXAMPLE 拥有的 /api/example?hello=world 的请求？

支持以下元素：

田	描述
method	请求的 HTTP 方法以允许或拒绝。
uri	供调用方访问和调用的请求 URI。
namespace	相关 API 或资源的所有者的逻辑名称。
context	自由格式的键值对，用于基于任意上下文数据的更高级决策。

典型响应包括 200、401 或 403。

1. 1. 1. 授权委托人

授权请求应使用 Bearer 或 Basic 方案（Authorization: Bearer/Basic ...）提供 Authorization 标头。标头中的令牌必须指示要使用请求中指定的详细信息访问资源的人员、使用者或授权委托人。

authorization 标头值可以是以下值之一：

一个 OpenID Connect ID 令牌，作为Bearer名令牌传递，由 CAS 在充当 OpenID Connect 提供商时生成。
一个 JWT 访问令牌，作为Bearer名令牌传递，由 CAS 在充当 OAuth 或 OpenID Connect 身份提供者时生成。
不透明的访问令牌（即 AT-1-...），作为Bearer记名令牌传递，由 CAS 在充当 OAuth 或 OpenID Connect 身份提供商时生成。
一个有效的 Base64 编码的 username:password，作为 Basic 令牌传递，可被 CAS 身份验证引擎接受。

提取所有令牌类型的声明或属性并将其附加到最终委托人，然后将其传递给授权策略引擎以做出决策。

1. 1. 1. 授权资源

Heimdall 支持和保护的可授权资源和 API 应在 CAS 中注册。这是通过平面 JSON 文件定义和配置资源及其关联所有者的列表来完成的。为了便于发现，文件按 API 所有者或组（即 API_EXAMPLE.json）进行命名和分类，这些 API 所有者或组描述了该命名空间中的 API 集合：

{

"@class": "org.apereo.cas.heimdall.authorizer.resource.AuthorizableResources",

"resources": [

"java.util.ArrayList",

[

{

"@class": "org.apereo.cas.heimdall.authorizer.resource.AuthorizableResource",

"id": 1,

"pattern": "/api/example.*",

"method": "PUT",

"enforceAllPolicies": false,

"policies": [ "java.util.ArrayList", [

{}

]],

"properties" : {

"@class" : "java.util.HashMap",

"key" : "value"

}

]

"namespace": "API_EXAMPLE"}

请注意，策略的加载、排序和评估是按照它们在文件中定义的顺序进行的。如果您的策略对模式进行操作，则可能需要确保首先列出最具体的策略。

用法

请记住，文件名大多无关紧要。虽然我们建议使用合理的命名约定，但策略中的 namespace 字段实际上是确定其所有者的部分。

指定命名空间和资源拥有的授权策略支持以下元素：

田	描述
id	此资源的唯一数字标识符。
pattern	描述资源或 API 终端节点的 URI 正则表达式模式。
method	允许访问资源的 HTTP 方法（作为正则表达式模式，或 * 表示所有）。
policies	附加到资源以允许或拒绝访问的策略列表。
enforceAllPolicies	是否必须查阅所有策略才能授权请求。默认值为 false。
properties	附加到资源的任意键值对，用于高级决策。

1. 1. 1. 1. 自定义

您还可以构建自己的存储库实现来注册和加载可授权资源。这可以通过提供 AuthorizableResourceRepository的专用实现并将其注册到运行时来完成：

@Beanpublic AuthorizableResourceRepository authorizableResourceRepository(

return new MyResourceRepository();}

请参阅本指南，了解有关如何将配置注册到 CAS 运行时的更多信息。

1. 1. 1. 授权策略

策略是附加到资源以允许或拒绝访问的规则。每个可授权资源都可以分配有一个或多个策略。策略按照为资源定义策略的顺序进行评估。CAS 支持以下策略：

Groovy

GROUPER 组

组权限

必需属性

被拒绝的属性

必需的 ACR

所需的 AMR

所需受众

必需的颁发者

必需的范围

REST API

OPENFGA

一个授权策略，可以接受内联或外部 Groovy 脚本来做出决策：

{

"@class": "org.apereo.cas.heimdall.authorizer.resource.policy.GroovyAuthorizationPolicy",

"script" :

'''

groovy {

def iAllowThis = true

return iAllowThis

? AuthorizationResult.granted("OK")

: AuthorizationResult.denied("NOPE")

}

'''}

以下参数将传递给脚本：

参数	描述
resource	匹配的 AuthorizableResource 对象。
request	提供的 AuthorizationRequest 对象。
applicationContext	对 Spring ApplicationContext 引用的引用。
logger	负责发出日志消息的对象，例如 logger.info(...)

1. 1. 1. 执行器端点

CAS 提供以下端点：

GET	/cas/actuator/heimdall/resources

获取所有可授权资源。

GET	/cas/actuator/heimdall/resources/{namespace}

GET	/cas/actuator/heimdall/resources/{namespace}/{id}

POST	/cas/actuator/heimdall/resource

1. OpenFGA
  1. 服务访问策略 - OpenFGA

OpenFGA 是一种快速、灵活的细粒度授权系统，旨在实现大规模的可靠性和低延迟。它由 Okta/Auth0 设计、构建和赞助。

此访问策略构建授权请求并将其提交到 OpenFGA 的check API 终端节点。授权请求的细节使用访问策略本身中通常定义的设置传授给 CAS：

{

"@class" : "org.apereo.cas.services.CasRegisteredService",

"serviceId" : "^https://.+",

"name" : "test",

"id" : 1,

"accessStrategy" : {

"@class": "org.apereo.cas.services.OpenFGARegisteredServiceAccessStrategy",

"apiUrl": "http://localhost:8080",

"object": "my-document",

"relation": "owner",

"storeId": "Y75hgyt75mhp",

"token": "92d4a401-86b4-4636-b742-a7c8034756a0"

}}

以下字段可用于此访问策略：

田	目的
relation	[1] 授权元组中的访问关系或类型;默认为 owner。
object	[1] 授权元组的对象;如果未定义，则默认为服务 URL。
storeId	[1] 授权存储标识符。
apiUrl	[1] OpenFGA 端点 URL。
token	[1] 如果需要，要在 Authorization 标头中使用的不记名令牌。

此字段支持 Spring 表达式语言语法。
1. Cerbos
  1. 服务访问策略 - Cerbos

Cerbos 是一种与语言无关的开放核心可扩展授权解决方案，通过为应用程序资源编写上下文感知访问控制策略，使用户权限和授权易于实施和管理。

此访问策略构建授权请求并将其提交到 Cerbos 的 check/resources API 端点。有关授权请求的要点：

资源 ID 分配给 CAS 注册服务的数字标识符。

所有 principal 属性都打包并包含在授权请求中。

授权请求中包含有关 CAS 注册服务的以下详细信息：

serviceUrl：应用程序 URL。

serviceName：已注册的服务名称。

serviceId：已注册的服务 ID。

serviceFriendlyName：已注册的服务友好名称。

serviceType：已注册的服务类型。

授权请求的细节使用通常在访问策略本身中定义的设置教给 CAS：

{

"@class" : "org.apereo.cas.services.CasRegisteredService",

"serviceId" : "^https://.+",

"name" : "test",

"id" : 1,

"accessStrategy" : {

"@class": "org.apereo.cas.services.CerbosRegisteredServiceAccessStrategy",

"apiUrl": "http://localhost:3592",

"token": "...",

"scope": "scope1",

"requestId": "...",

"rolesAttribute": "memberOf",

"kind": "kind1",

"actions": [ "java.util.ArrayList", [ "read", "write", "view"] ],

"auxData": {

"@class": "java.util.HashMap"

"jwt": {

"@class": "java.util.HashMap",

"token": "...",

"keySetId": "..."

}

}}

以下字段可用于此访问策略：

田	目的
apiUrl	[1] Cerbos 端点 URL 默认为 http://localhost:3592。
token	[1] 如果需要，要在 Authorization 标头中使用的不记名令牌。
requestId	[1] 请求 ID 可以是唯一标识请求的任何内容。
kind	[1] 资源类型。必填。此值用于确定要评估的资源策略。
scope	[1] 资源范围。自选。
rolesAttribute	[1] 属性名称，默认为 memberOf，表示分配给 CAS 主体的角色列表。
actions	对资源执行的操作列表。
auxData	自选。用于提供辅助数据的 block。有关更多信息，请参阅 Cerbos。

此字段支持 Spring 表达式语言语法。
1. Permit.io
  1. 服务访问策略 - Permit.io

Permit.io 以服务形式提供权限，使开发人员能够快速将权限和访问控制融入到应用程序中。它提供了一个集中式控制面板、SDK、API 和微服务，开发人员需要添加这些微服务来创建决策和执行点。

此访问策略尝试将用户与 Permit.io 同步，然后构建授权请求并将其提交给 Permit.io。授权请求的细节使用访问策略本身中通常定义的设置传授给 CAS：

{

"@class" : "org.apereo.cas.services.CasRegisteredService",

"serviceId" : "^https://.+",

"name" : "test",

"id" : 1,

"accessStrategy" : {

"@class": "org.apereo.cas.services.PermitRegisteredServiceAccessStrategy",

"action": "...",

"resource": "...",

"apiKey": "...",

"tenant": "default",

"pdpAddress": "https://cloudpdp.api.permit.io",

"emailAttributeName": "email",

"firstNameAttributeName": "firstname",

"lastNameAttributeName": "lastname",

"context" : {

"@class" : "java.util.TreeMap",

"param1" : "value1"

}

}}

以下字段可用于此访问策略：

田	目的
apiKey	[1] Permit.io API SDK 密钥，允许 SDK 进行身份验证、同步帐户等。
action	需要执行或评估的操作或权限。
resource	正在请求访问的资源。
tenant	自选。租户 ID 或密钥在 Permit.io 中定义，并在您可能拥有多个租户的情况下使用。
pdpAddress	[1] 可选。Permit.io API 终端节点。
emailAttributeName	自选。同步账户时用于标识委托人电子邮件的属性名称。
firstNameAttributeName	自选。在同步账户时用于标识委托人名字的属性名称。
lastNameAttributeName	自选。同步账户时用于标识委托人的姓氏的属性名称。

此字段支持 Spring 表达式语言语法。
1. Open Policy 代理
  1. 服务访问策略 - 开放策略代理（OPA）

Open Policy Agent 是一个开源的通用策略引擎，可在整个堆栈中实现统一、精细和上下文感知的策略实施。策略以高级声明性语言表示，具有给定的上下文，可促进安全、高性能、精细的控制。

此访问策略构建授权请求并通过 POST 将其提交给 OPA。授权请求的细节使用访问策略本身中通常定义的设置传授给 CAS：

{

"@class" : "org.apereo.cas.services.CasRegisteredService",

"serviceId" : "^https://.+.example.org",

"name" : "test",

"id" : 1,

"accessStrategy" : {

"@class": "org.apereo.cas.services.OpenPolicyAgentRegisteredServiceAccessStrategy",

"apiUrl": "http://localhost:8080",

"decision": "example/authz/allow",

"token": "92d4a401q26o0",

"context" : {

"@class" : "java.util.TreeMap",

"param1" : "value1"

}

}}

以下字段可用于此访问策略：

田	目的
apiUrl	[1] OPA 端点 URL。
decision	在 OPA 中定义的策略决策的名称。
token	[1] 如果需要，要在 Authorization 标头中使用的不记名令牌。
context	自定义上下文，用于携带数据以协助策略决策。

[1] 此字段支持 Spring 表达式语言语法。

input 参数下的授权请求正文与以下结构匹配：

{

"input": {

"principal": "casuser",

"service": "https://myapp.example.com",

"attributes": {

"email": ["user@example.org"]

"context": { "parameter1": "value1" }

}}

如果策略评估成功，OPA 将返回 HTTP 200 响应代码。非 HTTP 200 响应代码指示配置或运行时错误。策略决策结果包含在响应消息正文的 result key 中：

{

"result": true}

1. AWS 验证权限
  1. 服务访问策略 - AWS Verified Permissions

Amazon Verified Permissions 是一种可扩展的权限管理和细粒度授权服务，适用于您构建的应用程序。

此访问策略会构建授权请求并将其提交给 Amazon Verified Permissions。授权请求的细节使用访问策略本身中通常定义的设置传授给 CAS：

{

"@class": "org.apereo.cas.aws.authz.AmazonVerifiedPermissionsRegisteredServiceAccessStrategy",

"credentialAccessKey": "...",

"credentialSecretKey": "...",

"region": "us-east-1",

"policyStoreId": "...",

"actionId": "read",

"context": {

"@class": "java.util.LinkedHashMap",

"key": "value"

}}

以下字段可用于此访问策略：

田	目的
credentialAccessKey	[1]（可选）用于验证请求的访问密钥。
credentialSecretKey	[1]（可选）用于验证请求的密钥。
region	[1]（可选）用于授权 API 请求的 AWS 区域。
policyStoreId	[1]（可选）此策略存储中用于使用授权的策略
context	（可选）用于精细授权决策的其他上下文。
actionId	[1] 指定要授权的请求操作。