OIDC 集成
今天,当我们使用 rabbitmq-management 和 rabbitmq_auth_backend_oauth2 插件时,唯一支持的授权服务器是 UAA,这使得连接到其他 OAuth 2.0 服务器变得困难。此外,rabbitmq-management 插件使用 OAuth 2.0 隐式流程,但出于安全原因,该流程已不再推荐使用。
RabbitMQ 3.11 将支持几乎所有符合 OpenID Connect 和 OAuth 2.0 协议的授权服务器。此外,OAuth 2.0 授权码许可将成为默认许可,并且不再支持隐式许可。
概述
在 RabbitMQ 3.11 之前,当将 OAuth 2.0 与 Management UI 结合使用时,由于使用了 UAA 提供的 javascript 库,RabbitMQ 仅支持 UAA 作为 OAuth 2.0 服务器。此外,该库仅支持隐式许可类型,并以自定义 UAA 的 HTTP 端点为目标,这些端点不遵循任何标准,例如 OpenID Connect。
RabbitMQ 3.11 将所有 OAuth 2.0 和 OpenID Connect 协议委托给 oidc-client-ts 库,并且不再依赖 UAA 客户端库。通过此更改,RabbitMQ 不再支持隐式许可类型,但现在支持授权码许可类型。此外,带有前缀 uaa_
的旧设置(例如 uaa_location
)已被弃用,并被一组带有前缀 oauth_
的新设置所取代,这将在下一节用法中进行说明。
用法
要配置 rabbitmq-management 以使用任何 OAuth 2.0 服务器对用户进行身份验证,我们需要提供以下设置
oauth_enabled
替代了enable_uaa
oauth_client_id
替代了uaa_client_id
oauth_client_secret
包含与oauth_client_id
对应的密钥。这是一个新设置,因为隐式许可流程不需要密钥。oauth_provider_url
替代了uaa_location
。它是 OpenID Connect 端点 URL,RabbitMQ 通过此端点发现所有其他 OAuth 2.0 端点。
这是一个插件配置示例,包含以上设置
{ rabbitmq_management,
...
{oauth_enabled, true},
{oauth_client_id, "PUT YOUR AUTH CLIENT ID"},
{oauth_client_secret, "PUT YOUR AUTH CLIENT SECRET"},
{oauth_provider_url, "PUT YOUR OpenID Connect URL"}
...
}
除了以上四个必需设置外,还有一个可选设置
oauth_scopes
设置 RabbitMQ 代表访问管理 UI 的用户请求的范围。当enable_uaa
未设置或为 false 时,默认值为openid profile
;当enable_uaa
为 true 时,默认值为openid profile <rabbitmq_auth_backend_oauth2.resource_server_id>.*
我们何时需要设置 oauth_scopes
?
有些 OAuth 2.0 服务器可以自动授予用户范围,而无需考虑 RabbitMQ 在授权请求期间请求的范围。如果您的 OAuth 2.0 服务器具有此功能,则无需在 oauth_scopes
中指定所有范围。
相反,如果您的 OAuth 2.0 服务器仅授予在授权请求期间请求的那些范围,则必须在 oauth_scopes
设置中指定它们。
现有集群如何受此更改影响?
只有当前配置为使用 UAA 进行身份验证的 RabbitMQ 集群会受此更改影响。除非进行这些更改,否则它们将停止工作
- 添加
{oauth_enabled, true},
- 添加
{oauth_client_secret, "UAA_CLIENT_SECRET"},
,其中UAA_CLIENT_SECRET
是与先前配置的uaa_client_id
关联的客户端密钥
但是,强烈建议将配置为使用 UAA 进行 OAuth 2.0 的现有集群完全重新配置为新设置,因为旧配置已被弃用,并将在未来版本中删除。
当前支持哪些 OAuth 2.0 服务器?
理论上,任何符合 OpenID Connect 标准的 OAuth 2.0 服务器都应该被支持。RabbitMQ 已经针对以下 OAuth 2.0 服务器进行了测试
- Keycloak
- Auth0
- Azure Active Directory