Authelia 与 Gravitee APIM 集成使用 OpenID Connect 1.0 实现单点登录与角色映射【免费下载链接】autheliaThe Single Sign-On Multi-Factor portal for web apps. OpenID Certified™ and Post-Quantum Cryptography Ready.项目地址: https://gitcode.com/GitHub_Trending/au/authelia本篇技术指南讲解如何将 Gravitee Provider实现基于 Authelia 的统一身份认证SSO。读完本文你将掌握在 Authelia 中注册 Gravitee 客户端、在 Gravitee 中通过配置文件或 Web GUI 配置 OIDC 认证源以及利用 Authelia 的groups声明在 Gravitee 中实现组织与环境角色自动映射的完整方法。测试版本与适用范围本指南依据 Gravitee 集成文档 编写其集成测试基于以下版本Autheliav4.39.24GraviteeAPIM v4.7该集成由社区维护support level: community并在仓库中标记为已针对上述版本完成测试。由于版本差异可能导致端点或配置项变化实际部署时建议以你使用的具体版本为准。假设条件本示例基于以下假设后续所有配置均围绕这些值展开项目值应用根 URLGraviteehttps://gravitee.example.com/Authelia 根 URLhttps://auth.example.com/Client IDgraviteeClient Secretinsecure_secret本文示例中的域名、Client ID 与 Client Secret 仅用于演示。生产环境务必替换为真实值并使用安全随机数生成凭据。配置前的必读事项在开始配置 OpenID Connect 1.0 注册客户端之前有几个来自 oidc-common 公共片段 的重要约定需要先了解client_id必须是全局唯一值且仅能包含 RFC3986 Unreserved Characters本文中的gravitee仅为可读性演示。client_secret不应在生产中使用明文存储Authelia 配置中的明文 secret 已被标记为弃用未来不保证继续支持。强烈推荐使用 PBKDF2 摘要形式下文示例即采用此方式并参考 Plaintext 与 Tuning the work factors 调整哈希成本避免因成本过高导致客户端请求超时。下文 Authelia 配置示例只包含客户端注册部分你仍然必须配置 OpenID Connect 1.0 Provider 所要求的其余必要配置如 issuer、密钥等。在 Authelia 中注册 Gravitee 客户端以下 YAML 是 Authelia 侧针对 Gravitee 的 客户端配置 示例与上述应用示例配套使用identity_providers: oidc: ## The other portions of the mandatory OpenID Connect 1.0 configuration go here. ## See: https://www.authelia.com/c/oidc clients: - client_id: gravitee client_name: Gravitee client_secret: $pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng # The digest of insecure_secret. public: false authorization_policy: two_factor require_pkce: false pkce_challenge_method: redirect_uris: - https://gravitee.example.com/ scopes: - openid - email - profile - groups response_types: - code grant_types: - authorization_code access_token_signed_response_alg: none userinfo_signed_response_alg: none token_endpoint_auth_method: client_secret_basic关键配置项解析对照 OpenID Connect 1.0 Clients 配置文档逐项说明上述参数的作用client_id/client_name客户端唯一标识与界面显示名。client_name默认与 ID 相同此处显式设置为Gravitee以便在 Authelia 的授权/同意界面中友好展示。client_secretAuthelia 与应用共享的机密必须与 Gravitee 侧配置的 secret 完全一致。示例中存放的是insecure_secret的$pbkdf2-sha512摘要而非明文这是推荐的存储方式。当客户端为 confidential 类型时该字段必填若使用 public 客户端类型或采用密钥型认证方式如private_key_jwt则情况不同。public: false声明为机密confidential客户端。机密客户端可以在 Token 端点使用 secret 进行客户端认证public 客户端则默认使用none认证方式。authorization_policy: two_factor要求该客户端的所有授权必须通过双因素认证。这是 Authelia 对每个客户端可独立配置的安全策略。require_pkce: false/pkce_challenge_method: 不强制要求 PKCE。若希望提升安全性可设置require_pkce: true并推荐pkce_challenge_method: S256前提是 Gravitee 支持。redirect_uris授权完成后 Authelia 允许回调的 URI 白名单此处为 Gravitee 应用根 URLhttps://gravitee.example.com/。scopesopenid、email、profile、groups。其中groups是 Authelia 提供的组声明后续 Gravitee 的角色映射将依赖它openid是 OpenID Connect 强制要求的 scope。response_types: [code]仅使用 Authorization Code Flow授权码流程。grant_types: [authorization_code]仅允许授权码授权类型。Authelia 还支持refresh_token、client_credentials、implicit、设备码等但 Gravitee 场景下此配置最贴合。access_token_signed_response_alg: none/userinfo_signed_response_alg: noneAccess Token 与 UserInfo 响应不进行 JWT 签名。根据 User Information Signing Algorithm 说明none时 UserInfo 端点返回普通 JSONapplication/json这也是多数不支持 JWT 化响应的客户端的通用选择。token_endpoint_auth_method: client_secret_basic在 Token 端点使用 HTTP Basic 认证RFC6749 附录 B 的 URL 编码规则携带客户端凭据。confidential 客户端默认即为此值。在 Gravitee 中配置 Authelia 认证源Gravitee 支持两种配置方式配置文件与Web GUI。官方文档指出仅有 Web GUI 一种官方方法但配置文件方式同样可行配置文件通常命名为gravitee.yaml。方式一通过配置文件gravitee.yamlsecurity: providers: - type: oidc clientId: gravitee clientSecret: insecure_secret tokenIntrospectionEndpoint: https://auth.example.com/api/oidc/introspection tokenEndpoint: https://auth.example.com/api/oidc/token authorizeEndpoint: https://auth.example.com/api/oidc/authorization userInfoEndpoint: https://auth.example.com/api/oidc/userinfo syncMappings: true scopes: - openid - email - profile - groups userMapping: id: sub email: email lastname: family_name firstname: given_name picture: photo roleMapping: - condition: {(#jsonPath(#profile, $.groups) matches gravitee-admin )} roles: - ORGANIZATION:ADMIN - ENVIRONMENT:ADMIN配置项说明端点地址上述/api/oidc/...路径与 Endpoint Implementations 文档 中记录的 Authelia 端点一致——/api/oidc/authorization授权、/api/oidc/token令牌、/api/oidc/userinfo用户信息、/api/oidc/introspection令牌内省。这些路径在仓库测试代码中同样可见例如 handler_oauth2_introspection_test.go 中的testOIDCIntrospectionEndpoint https://login.example.com:8080/api/oidc/introspection。Gravitee 通过tokenIntrospectionEndpoint对 Access Token 进行服务端校验这是其验证 Authelia 签发令牌安全性的关键一环。syncMappings: true启用映射同步使角色/用户映射在每次登录时与 IdP 声明保持同步。scopes必须与 Authelia 侧注册的 scopes 保持一致含groups否则 Gravitee 无法获取组信息。userMapping将 Authelia UserInfo 端点返回的标准 OIDC 声明映射到 Gravitee 用户模型id: sub——使用sub声明作为用户唯一标识Authelia 使用 UUIDv4 主题标识符稳定且不可变email、family_name、given_name分别映射邮箱、姓、名picture: photo——对应 Authelia UserInfo 中的头像声明。roleMapping基于 Gravitee 角色与组映射 语法通过 SpEL 表达式与 JSONPath 判断groups声明当用户属于gravitee-admin组时授予 Gravitee 的ORGANIZATION:ADMIN与ENVIRONMENT:ADMIN角色。你可以按需增加多条条件以映射不同组织/环境角色。方式二通过 Web GUI若使用 Gravitee 的管理界面进行配置步骤如下登录 Gravitee。导航到Settings。导航到OIDC。点击 New Auth Provider。配置以下选项选项值NameAutheliaClient IDgraviteeClient Secretinsecure_secretIssuerhttps://auth.example.comAuthorization Endpointhttps://auth.example.com/api/oidc/authorizationToken Endpointhttps://auth.example.com/api/oidc/tokenUserinfo Endpointhttps://auth.example.com/api/oidc/userinfoJWKS Endpointhttps://auth.example.com/jwks.json点击底部的Submit提交。其中JWKS Endpoint的路径https://auth.example.com/jwks.json对应 Authelia 的 JSON Web Key Set 端点Gravitee 用它获取 Authelia 的公钥以验证令牌签名。若你的 Authelia 开启了 OpenID Connect Discovery/.well-known/openid-configuration这些端点通常也可自动发现但 Gravitee 允许显式指定以便精确控制。集成流程与验证要点完成上述双侧配置后整体的认证流程为用户访问 Gravitee 门户被重定向至 Authelia 的授权端点/api/oidc/authorizationAuthelia 依据authorization_policy: two_factor要求用户完成登录含 2FA用户同意授权后Authelia 携带授权码回调 Gravitee 的redirect_uriGravitee 使用client_secret_basic在/api/oidc/token兑换 Access Token 与 ID TokenGravitee 通过/api/oidc/userinfo获取email、profile、groups等声明并通过/api/oidc/introspection校验 Access Token 有效性依据roleMapping为用户分配组织与环境角色完成 SSO 登录。验证时建议关注Authelia 侧授权日志与 Gravitee 侧认证日志确认groups声明中确实包含gravitee-admin可在 Authelia UserInfo 响应中直接检查以及确认回调 URL 与 Authelia 注册的redirect_uris完全一致含末尾斜杠。参考文档OpenID Connect 1.0 集成总览OpenID Connect 1.0 客户端配置OpenID Connect 1.0 Provider 配置OpenID Connect 常见问题【免费下载链接】autheliaThe Single Sign-On Multi-Factor portal for web apps. OpenID Certified™ and Post-Quantum Cryptography Ready.项目地址: https://gitcode.com/GitHub_Trending/au/authelia创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Authelia 与 Gravitee APIM 集成：使用 OpenID Connect 1.0 实现单点登录与角色映射
Authelia 与 Gravitee APIM 集成使用 OpenID Connect 1.0 实现单点登录与角色映射【免费下载链接】autheliaThe Single Sign-On Multi-Factor portal for web apps. OpenID Certified™ and Post-Quantum Cryptography Ready.项目地址: https://gitcode.com/GitHub_Trending/au/authelia本篇技术指南讲解如何将 Gravitee Provider实现基于 Authelia 的统一身份认证SSO。读完本文你将掌握在 Authelia 中注册 Gravitee 客户端、在 Gravitee 中通过配置文件或 Web GUI 配置 OIDC 认证源以及利用 Authelia 的groups声明在 Gravitee 中实现组织与环境角色自动映射的完整方法。测试版本与适用范围本指南依据 Gravitee 集成文档 编写其集成测试基于以下版本Autheliav4.39.24GraviteeAPIM v4.7该集成由社区维护support level: community并在仓库中标记为已针对上述版本完成测试。由于版本差异可能导致端点或配置项变化实际部署时建议以你使用的具体版本为准。假设条件本示例基于以下假设后续所有配置均围绕这些值展开项目值应用根 URLGraviteehttps://gravitee.example.com/Authelia 根 URLhttps://auth.example.com/Client IDgraviteeClient Secretinsecure_secret本文示例中的域名、Client ID 与 Client Secret 仅用于演示。生产环境务必替换为真实值并使用安全随机数生成凭据。配置前的必读事项在开始配置 OpenID Connect 1.0 注册客户端之前有几个来自 oidc-common 公共片段 的重要约定需要先了解client_id必须是全局唯一值且仅能包含 RFC3986 Unreserved Characters本文中的gravitee仅为可读性演示。client_secret不应在生产中使用明文存储Authelia 配置中的明文 secret 已被标记为弃用未来不保证继续支持。强烈推荐使用 PBKDF2 摘要形式下文示例即采用此方式并参考 Plaintext 与 Tuning the work factors 调整哈希成本避免因成本过高导致客户端请求超时。下文 Authelia 配置示例只包含客户端注册部分你仍然必须配置 OpenID Connect 1.0 Provider 所要求的其余必要配置如 issuer、密钥等。在 Authelia 中注册 Gravitee 客户端以下 YAML 是 Authelia 侧针对 Gravitee 的 客户端配置 示例与上述应用示例配套使用identity_providers: oidc: ## The other portions of the mandatory OpenID Connect 1.0 configuration go here. ## See: https://www.authelia.com/c/oidc clients: - client_id: gravitee client_name: Gravitee client_secret: $pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng # The digest of insecure_secret. public: false authorization_policy: two_factor require_pkce: false pkce_challenge_method: redirect_uris: - https://gravitee.example.com/ scopes: - openid - email - profile - groups response_types: - code grant_types: - authorization_code access_token_signed_response_alg: none userinfo_signed_response_alg: none token_endpoint_auth_method: client_secret_basic关键配置项解析对照 OpenID Connect 1.0 Clients 配置文档逐项说明上述参数的作用client_id/client_name客户端唯一标识与界面显示名。client_name默认与 ID 相同此处显式设置为Gravitee以便在 Authelia 的授权/同意界面中友好展示。client_secretAuthelia 与应用共享的机密必须与 Gravitee 侧配置的 secret 完全一致。示例中存放的是insecure_secret的$pbkdf2-sha512摘要而非明文这是推荐的存储方式。当客户端为 confidential 类型时该字段必填若使用 public 客户端类型或采用密钥型认证方式如private_key_jwt则情况不同。public: false声明为机密confidential客户端。机密客户端可以在 Token 端点使用 secret 进行客户端认证public 客户端则默认使用none认证方式。authorization_policy: two_factor要求该客户端的所有授权必须通过双因素认证。这是 Authelia 对每个客户端可独立配置的安全策略。require_pkce: false/pkce_challenge_method: 不强制要求 PKCE。若希望提升安全性可设置require_pkce: true并推荐pkce_challenge_method: S256前提是 Gravitee 支持。redirect_uris授权完成后 Authelia 允许回调的 URI 白名单此处为 Gravitee 应用根 URLhttps://gravitee.example.com/。scopesopenid、email、profile、groups。其中groups是 Authelia 提供的组声明后续 Gravitee 的角色映射将依赖它openid是 OpenID Connect 强制要求的 scope。response_types: [code]仅使用 Authorization Code Flow授权码流程。grant_types: [authorization_code]仅允许授权码授权类型。Authelia 还支持refresh_token、client_credentials、implicit、设备码等但 Gravitee 场景下此配置最贴合。access_token_signed_response_alg: none/userinfo_signed_response_alg: noneAccess Token 与 UserInfo 响应不进行 JWT 签名。根据 User Information Signing Algorithm 说明none时 UserInfo 端点返回普通 JSONapplication/json这也是多数不支持 JWT 化响应的客户端的通用选择。token_endpoint_auth_method: client_secret_basic在 Token 端点使用 HTTP Basic 认证RFC6749 附录 B 的 URL 编码规则携带客户端凭据。confidential 客户端默认即为此值。在 Gravitee 中配置 Authelia 认证源Gravitee 支持两种配置方式配置文件与Web GUI。官方文档指出仅有 Web GUI 一种官方方法但配置文件方式同样可行配置文件通常命名为gravitee.yaml。方式一通过配置文件gravitee.yamlsecurity: providers: - type: oidc clientId: gravitee clientSecret: insecure_secret tokenIntrospectionEndpoint: https://auth.example.com/api/oidc/introspection tokenEndpoint: https://auth.example.com/api/oidc/token authorizeEndpoint: https://auth.example.com/api/oidc/authorization userInfoEndpoint: https://auth.example.com/api/oidc/userinfo syncMappings: true scopes: - openid - email - profile - groups userMapping: id: sub email: email lastname: family_name firstname: given_name picture: photo roleMapping: - condition: {(#jsonPath(#profile, $.groups) matches gravitee-admin )} roles: - ORGANIZATION:ADMIN - ENVIRONMENT:ADMIN配置项说明端点地址上述/api/oidc/...路径与 Endpoint Implementations 文档 中记录的 Authelia 端点一致——/api/oidc/authorization授权、/api/oidc/token令牌、/api/oidc/userinfo用户信息、/api/oidc/introspection令牌内省。这些路径在仓库测试代码中同样可见例如 handler_oauth2_introspection_test.go 中的testOIDCIntrospectionEndpoint https://login.example.com:8080/api/oidc/introspection。Gravitee 通过tokenIntrospectionEndpoint对 Access Token 进行服务端校验这是其验证 Authelia 签发令牌安全性的关键一环。syncMappings: true启用映射同步使角色/用户映射在每次登录时与 IdP 声明保持同步。scopes必须与 Authelia 侧注册的 scopes 保持一致含groups否则 Gravitee 无法获取组信息。userMapping将 Authelia UserInfo 端点返回的标准 OIDC 声明映射到 Gravitee 用户模型id: sub——使用sub声明作为用户唯一标识Authelia 使用 UUIDv4 主题标识符稳定且不可变email、family_name、given_name分别映射邮箱、姓、名picture: photo——对应 Authelia UserInfo 中的头像声明。roleMapping基于 Gravitee 角色与组映射 语法通过 SpEL 表达式与 JSONPath 判断groups声明当用户属于gravitee-admin组时授予 Gravitee 的ORGANIZATION:ADMIN与ENVIRONMENT:ADMIN角色。你可以按需增加多条条件以映射不同组织/环境角色。方式二通过 Web GUI若使用 Gravitee 的管理界面进行配置步骤如下登录 Gravitee。导航到Settings。导航到OIDC。点击 New Auth Provider。配置以下选项选项值NameAutheliaClient IDgraviteeClient Secretinsecure_secretIssuerhttps://auth.example.comAuthorization Endpointhttps://auth.example.com/api/oidc/authorizationToken Endpointhttps://auth.example.com/api/oidc/tokenUserinfo Endpointhttps://auth.example.com/api/oidc/userinfoJWKS Endpointhttps://auth.example.com/jwks.json点击底部的Submit提交。其中JWKS Endpoint的路径https://auth.example.com/jwks.json对应 Authelia 的 JSON Web Key Set 端点Gravitee 用它获取 Authelia 的公钥以验证令牌签名。若你的 Authelia 开启了 OpenID Connect Discovery/.well-known/openid-configuration这些端点通常也可自动发现但 Gravitee 允许显式指定以便精确控制。集成流程与验证要点完成上述双侧配置后整体的认证流程为用户访问 Gravitee 门户被重定向至 Authelia 的授权端点/api/oidc/authorizationAuthelia 依据authorization_policy: two_factor要求用户完成登录含 2FA用户同意授权后Authelia 携带授权码回调 Gravitee 的redirect_uriGravitee 使用client_secret_basic在/api/oidc/token兑换 Access Token 与 ID TokenGravitee 通过/api/oidc/userinfo获取email、profile、groups等声明并通过/api/oidc/introspection校验 Access Token 有效性依据roleMapping为用户分配组织与环境角色完成 SSO 登录。验证时建议关注Authelia 侧授权日志与 Gravitee 侧认证日志确认groups声明中确实包含gravitee-admin可在 Authelia UserInfo 响应中直接检查以及确认回调 URL 与 Authelia 注册的redirect_uris完全一致含末尾斜杠。参考文档OpenID Connect 1.0 集成总览OpenID Connect 1.0 客户端配置OpenID Connect 1.0 Provider 配置OpenID Connect 常见问题【免费下载链接】autheliaThe Single Sign-On Multi-Factor portal for web apps. OpenID Certified™ and Post-Quantum Cryptography Ready.项目地址: https://gitcode.com/GitHub_Trending/au/authelia创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考