Authelia 接入 Seafile基于 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/autheliaSeafile 是一个开源的文件同步与共享平台其 Web 端Seahub原生支持 OAuth / OpenID Connect 1.0 认证。本指南以 Authelia 仓库中的官方集成文档为主体演示如何将 Seafile 作为 OpenID Connect 1.0 Relying Party 接入 Authelia 的 OpenID Connect 1.0 Provider实现“一次登录、统一认证”的 SSO 体验。读完本文你将掌握 Authelia 侧identity_providers.oidc.clients的完整注册写法、Seafile 侧seahub_settings.py的全部 OAuth 参数含义以及存量用户迁移与 WebDAV 等不支持 OAuth 客户端的兼容方案。测试版本本指南对应的集成组合已在以下版本上验证通过Autheliav4.38.0Seafile Serverv10.0.1说明本指南属于 Authelia 社区community支持级别的集成其support元数据中versions: true表示上述版本组合经过了实测验证。假设条件本示例基于以下前提应用根地址Application Root URLhttps://seafile.example.com/Authelia 根地址Authelia Root URLhttps://auth.example.com/客户端 IDClient IDseafile客户端密钥Client Secretinsecure_secret其中example.com为文档变量占位域名auth为 Authelia 子域占位。实际部署时应替换为你的真实域名并建议为 Authelia 的 OIDC 配置启用 HTTPS。集成前的通用注意事项在开始配置之前有几个所有 OpenID Connect 1.0 客户端注册都必须遵守的要点出自 Authelia 文档系统通用的oidc-common区块定义于 docs/layouts/_shortcodes/oidc-common.htmlclient_id必须全局唯一每个客户端的client_id都必须是唯一值。指南中的seafile仅为演示用生产环境建议使用 64 位随机字符且只能包含 RFC3986 非保留字符Unreserved Characters长度不超过 100 字符。client_secret建议存储为哈希明文存储虽然仍被支持但已被标记为弃用。Authelia 支持以 PBKDF2-SHA512 格式存储密钥摘要见下文配置示例这强烈推荐。需要注意的是若哈希成本因子过高可能导致客户端请求超时相关调优可参考 Authelia 官方 FAQ 中 “Tuning the work factors” 一节。客户端注册只是配置的一部分下面的 YAML 仅展示了 Seafile 这一个客户端的注册片段你还必须按 OpenID Connect 1.0 Provider 配置指南 完成 Issuer 级的基础配置如hmac_secret、jwks、授权策略等。Authelia 侧注册 Seafile 客户端在 Authelia 的主配置文件configuration.yml中为 Seafile 注册一个机密confidential类型的 OIDC 客户端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: seafile client_name: Seafile 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://seafile.example.com/oauth/callback/ scopes: - openid - profile - email 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关键参数逐一解读以上配置在 Authelia 源码中有对应的 schema 定义见 internal/configuration/schema/identity_providers.go 中的IdentityProvidersOpenIDConnectClient结构体各参数含义如下client_id/client_name客户端唯一标识与展示名称。client_id对应 OIDC 规范中的client_idSeafile 侧必须与之完全一致。client_secret即 Seafile 侧配置的OAUTH_CLIENT_SECRET的 PBKDF2-SHA512 摘要示例中为insecure_secret的摘要。从源码看该字段类型为*PasswordDigest支持明文与哈希两种存储方式。public: false声明为机密客户端confidential client。Seafile 作为服务端应用持有密钥可以通过 token 端点进行客户端认证。schema 中该字段默认值为false。authorization_policy: two_factor该客户端要求用户完成双因素认证后才授权。这也是 schema 中DefaultOpenIDConnectClientConfiguration的默认策略policyTwoFactor。require_pkce: false与pkce_challenge_method: 关闭 PKCE 强制要求。schema 显示require_pkce默认falsepkce_challenge_method可取值、plain、S256。Seafile 的 OAuth 实现不要求 PKCE因此这里显式关闭若你的 Seafile 版本支持 PKCE建议开启并选用S256。redirect_uris授权码回调地址白名单必须与 Seafile 的OAUTH_REDIRECT_URL精确一致末尾/不能省略。scopesopenid、profile、email三个作用域与 Seafile 侧OAUTH_SCOPE列表一一对应。response_types: [code]仅使用授权码流程Authorization Code Flow对应 Seafile 的授权请求方式。grant_types: [authorization_code]仅允许授权码授权类型。access_token_signed_response_alg: none与userinfo_signed_response_alg: noneAccess Token 与 UserInfo 响应均不签名。这也是DefaultOpenIDConnectClientConfiguration中的默认值见 internal/configuration/schema/identity_providers.go。token_endpoint_auth_method: client_secret_basic客户端通过 HTTP Basic Auth 携带密钥访问 token 端点。schema 中该字段可选值为none、client_secret_post、client_secret_basic、private_key_jwt、client_secret_jwt默认即为client_secret_basicSeafile 的requests_oauthlib实现与该方式兼容。Seafile 侧配置seahub_settings.pySeafile 的 Web 端由 SeahubDjango 应用驱动OAuth 配置通常写在seahub_settings.py中。配置前需确认 Seafile 已具备 OAuth 相关依赖如requests_oauthlib必要时需手动安装。ENABLE_OAUTH True OAUTH_ENABLE_INSECURE_TRANSPORT False OAUTH_CLIENT_ID seafile OAUTH_CLIENT_SECRET insecure_secret OAUTH_REDIRECT_URL https://seafile.example.com/oauth/callback/ OAUTH_PROVIDER_DOMAIN auth.example.com OAUTH_AUTHORIZATION_URL https://auth.example.com/api/oidc/authorization OAUTH_TOKEN_URL https://auth.example.com/api/oidc/token OAUTH_USER_INFO_URL https://auth.example.com/api/oidc/userinfo OAUTH_SCOPE [ openid, profile, email, ] OAUTH_ATTRIBUTE_MAP { sub: (True, uid), email: (False, email), name: (False, name), } # Optional #ENABLE_WEBDAV_SECRET True参数说明与端点匹配ENABLE_OAUTH开启 OAuth 登录入口。OAUTH_ENABLE_INSECURE_TRANSPORT设为False禁止通过非 HTTPS 传输 OAuth 凭据仅当在本地 HTTP 环境调试时才应临时置为True。OAUTH_CLIENT_ID/OAUTH_CLIENT_SECRET与 Authelia 客户端注册中的client_id和client_secret明文值一致。OAUTH_REDIRECT_URL回调地址必须与 Authelia 的redirect_uris完全一致。OAUTH_PROVIDER_DOMAINIdP 域名用于 Seafile 拼接与校验。OAUTH_AUTHORIZATION_URL/OAUTH_TOKEN_URL/OAUTH_USER_INFO_URL指向 Authelia 的三个标准端点。这三个路径与 Authelia 实现的端点完全吻合——见 docs/content/integration/openid-connect/introduction.md 中的 “Endpoint Implementations” 章节/api/oidc/authorizationauthorization_endpoint、/api/oidc/tokentoken_endpoint、/api/oidc/userinfouserinfo_endpoint。即便不手动填写客户端也可通过/.well-known/openid-configuration自动发现这些端点。OAUTH_SCOPE申请的作用域列表与 Authelia 客户端scopes保持一致否则授权阶段可能因请求了客户端未授权的作用域而失败。OAUTH_ATTRIBUTE_MAP将 IdP 返回的 claims 映射到 Seahub 用户模型sub: (True, uid)把 OIDCsub声明作为必填属性映射到 Seahub 的uid字段——这是账户绑定的关键sub是 IdP 保证不变且唯一的身份标识email: (False, email)email声明映射到邮箱字段非必填name: (False, name)name声明映射到显示名字段非必填。授权码流程闭环整个登录链路为标准的 Authorization Code Flow用户访问 Seafile 并点击登录Seafile 将用户重定向到 Authelia 的/api/oidc/authorization用户在 Authelia 门户完成认证本示例要求two_factor双因素策略Authelia 将授权码通过回调地址返回给 SeafileSeafile 使用client_secret_basic方式携带凭据在/api/oidc/token换取 Access Token 与 ID TokenSeafile 调用/api/oidc/userinfo获取用户 claims按OAUTH_ATTRIBUTE_MAP建立/匹配本地账户。存量用户迁移如果 Seafile 此前使用本地用户数据库切换到外部 OAuth 认证后存量账户与 IdP 账户之间需要建立映射关系。本指南对应的 Seafile 官方文档中提供了 “Migrating from local user database to external authentication”从本地用户数据库迁移到外部认证的迁移指南已在实践中验证可行建议在正式切换前在测试环境演练迁移流程尤其要核对sub声明与本地uid的绑定关系避免用户登录后生成重复账户。附加步骤为不支持 OAuth 的客户端启用 WebDAV SecretSeafile 的 WebDAV 扩展seafdav在撰写本指南时不支持 OAuth Bearer 认证相关讨论见 seafdav 问题 #76。因此像davfs2这类仅支持 HTTP Basic Auth 的 WebDAV 客户端无法直接使用 OAuth 令牌登录。解决方法是可选地启用 WebDAV Secret在seahub_settings.py中取消注释ENABLE_WEBDAV_SECRET True并在 Seafile 的用户管理选项中配置使这些客户端能够通过 Basic Auth 方式登录从而在统一 SSO 的前提下兼容不支持 OAuth 2.0 的存量工具。参见Seafile OAuth Authentication 官方文档Seafile 的 WebDAV 扩展从本地用户数据库迁移到 OAuth仓库内延伸阅读OpenID Connect 1.0 集成总览含端点实现与支持矩阵OpenID Connect 1.0 客户端配置指南全部客户端选项详解OpenID Connect 1.0 Provider 配置指南OIDC 客户端配置 schema 源码OIDC 集成通用注意事项oidc-common 区块需要提醒的是本文中的insecure_secret与示例域名仅用于演示生产环境请务必使用高强度随机密钥并优先以 PBKDF2 哈希形式写入 Authelia 配置同时确保 Authelia 与 Seafile 均通过 HTTPS 对外提供服务。【免费下载链接】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 接入 Seafile：基于 OpenID Connect 1.0 实现单点登录的完整配置指南
Authelia 接入 Seafile基于 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/autheliaSeafile 是一个开源的文件同步与共享平台其 Web 端Seahub原生支持 OAuth / OpenID Connect 1.0 认证。本指南以 Authelia 仓库中的官方集成文档为主体演示如何将 Seafile 作为 OpenID Connect 1.0 Relying Party 接入 Authelia 的 OpenID Connect 1.0 Provider实现“一次登录、统一认证”的 SSO 体验。读完本文你将掌握 Authelia 侧identity_providers.oidc.clients的完整注册写法、Seafile 侧seahub_settings.py的全部 OAuth 参数含义以及存量用户迁移与 WebDAV 等不支持 OAuth 客户端的兼容方案。测试版本本指南对应的集成组合已在以下版本上验证通过Autheliav4.38.0Seafile Serverv10.0.1说明本指南属于 Authelia 社区community支持级别的集成其support元数据中versions: true表示上述版本组合经过了实测验证。假设条件本示例基于以下前提应用根地址Application Root URLhttps://seafile.example.com/Authelia 根地址Authelia Root URLhttps://auth.example.com/客户端 IDClient IDseafile客户端密钥Client Secretinsecure_secret其中example.com为文档变量占位域名auth为 Authelia 子域占位。实际部署时应替换为你的真实域名并建议为 Authelia 的 OIDC 配置启用 HTTPS。集成前的通用注意事项在开始配置之前有几个所有 OpenID Connect 1.0 客户端注册都必须遵守的要点出自 Authelia 文档系统通用的oidc-common区块定义于 docs/layouts/_shortcodes/oidc-common.htmlclient_id必须全局唯一每个客户端的client_id都必须是唯一值。指南中的seafile仅为演示用生产环境建议使用 64 位随机字符且只能包含 RFC3986 非保留字符Unreserved Characters长度不超过 100 字符。client_secret建议存储为哈希明文存储虽然仍被支持但已被标记为弃用。Authelia 支持以 PBKDF2-SHA512 格式存储密钥摘要见下文配置示例这强烈推荐。需要注意的是若哈希成本因子过高可能导致客户端请求超时相关调优可参考 Authelia 官方 FAQ 中 “Tuning the work factors” 一节。客户端注册只是配置的一部分下面的 YAML 仅展示了 Seafile 这一个客户端的注册片段你还必须按 OpenID Connect 1.0 Provider 配置指南 完成 Issuer 级的基础配置如hmac_secret、jwks、授权策略等。Authelia 侧注册 Seafile 客户端在 Authelia 的主配置文件configuration.yml中为 Seafile 注册一个机密confidential类型的 OIDC 客户端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: seafile client_name: Seafile 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://seafile.example.com/oauth/callback/ scopes: - openid - profile - email 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关键参数逐一解读以上配置在 Authelia 源码中有对应的 schema 定义见 internal/configuration/schema/identity_providers.go 中的IdentityProvidersOpenIDConnectClient结构体各参数含义如下client_id/client_name客户端唯一标识与展示名称。client_id对应 OIDC 规范中的client_idSeafile 侧必须与之完全一致。client_secret即 Seafile 侧配置的OAUTH_CLIENT_SECRET的 PBKDF2-SHA512 摘要示例中为insecure_secret的摘要。从源码看该字段类型为*PasswordDigest支持明文与哈希两种存储方式。public: false声明为机密客户端confidential client。Seafile 作为服务端应用持有密钥可以通过 token 端点进行客户端认证。schema 中该字段默认值为false。authorization_policy: two_factor该客户端要求用户完成双因素认证后才授权。这也是 schema 中DefaultOpenIDConnectClientConfiguration的默认策略policyTwoFactor。require_pkce: false与pkce_challenge_method: 关闭 PKCE 强制要求。schema 显示require_pkce默认falsepkce_challenge_method可取值、plain、S256。Seafile 的 OAuth 实现不要求 PKCE因此这里显式关闭若你的 Seafile 版本支持 PKCE建议开启并选用S256。redirect_uris授权码回调地址白名单必须与 Seafile 的OAUTH_REDIRECT_URL精确一致末尾/不能省略。scopesopenid、profile、email三个作用域与 Seafile 侧OAUTH_SCOPE列表一一对应。response_types: [code]仅使用授权码流程Authorization Code Flow对应 Seafile 的授权请求方式。grant_types: [authorization_code]仅允许授权码授权类型。access_token_signed_response_alg: none与userinfo_signed_response_alg: noneAccess Token 与 UserInfo 响应均不签名。这也是DefaultOpenIDConnectClientConfiguration中的默认值见 internal/configuration/schema/identity_providers.go。token_endpoint_auth_method: client_secret_basic客户端通过 HTTP Basic Auth 携带密钥访问 token 端点。schema 中该字段可选值为none、client_secret_post、client_secret_basic、private_key_jwt、client_secret_jwt默认即为client_secret_basicSeafile 的requests_oauthlib实现与该方式兼容。Seafile 侧配置seahub_settings.pySeafile 的 Web 端由 SeahubDjango 应用驱动OAuth 配置通常写在seahub_settings.py中。配置前需确认 Seafile 已具备 OAuth 相关依赖如requests_oauthlib必要时需手动安装。ENABLE_OAUTH True OAUTH_ENABLE_INSECURE_TRANSPORT False OAUTH_CLIENT_ID seafile OAUTH_CLIENT_SECRET insecure_secret OAUTH_REDIRECT_URL https://seafile.example.com/oauth/callback/ OAUTH_PROVIDER_DOMAIN auth.example.com OAUTH_AUTHORIZATION_URL https://auth.example.com/api/oidc/authorization OAUTH_TOKEN_URL https://auth.example.com/api/oidc/token OAUTH_USER_INFO_URL https://auth.example.com/api/oidc/userinfo OAUTH_SCOPE [ openid, profile, email, ] OAUTH_ATTRIBUTE_MAP { sub: (True, uid), email: (False, email), name: (False, name), } # Optional #ENABLE_WEBDAV_SECRET True参数说明与端点匹配ENABLE_OAUTH开启 OAuth 登录入口。OAUTH_ENABLE_INSECURE_TRANSPORT设为False禁止通过非 HTTPS 传输 OAuth 凭据仅当在本地 HTTP 环境调试时才应临时置为True。OAUTH_CLIENT_ID/OAUTH_CLIENT_SECRET与 Authelia 客户端注册中的client_id和client_secret明文值一致。OAUTH_REDIRECT_URL回调地址必须与 Authelia 的redirect_uris完全一致。OAUTH_PROVIDER_DOMAINIdP 域名用于 Seafile 拼接与校验。OAUTH_AUTHORIZATION_URL/OAUTH_TOKEN_URL/OAUTH_USER_INFO_URL指向 Authelia 的三个标准端点。这三个路径与 Authelia 实现的端点完全吻合——见 docs/content/integration/openid-connect/introduction.md 中的 “Endpoint Implementations” 章节/api/oidc/authorizationauthorization_endpoint、/api/oidc/tokentoken_endpoint、/api/oidc/userinfouserinfo_endpoint。即便不手动填写客户端也可通过/.well-known/openid-configuration自动发现这些端点。OAUTH_SCOPE申请的作用域列表与 Authelia 客户端scopes保持一致否则授权阶段可能因请求了客户端未授权的作用域而失败。OAUTH_ATTRIBUTE_MAP将 IdP 返回的 claims 映射到 Seahub 用户模型sub: (True, uid)把 OIDCsub声明作为必填属性映射到 Seahub 的uid字段——这是账户绑定的关键sub是 IdP 保证不变且唯一的身份标识email: (False, email)email声明映射到邮箱字段非必填name: (False, name)name声明映射到显示名字段非必填。授权码流程闭环整个登录链路为标准的 Authorization Code Flow用户访问 Seafile 并点击登录Seafile 将用户重定向到 Authelia 的/api/oidc/authorization用户在 Authelia 门户完成认证本示例要求two_factor双因素策略Authelia 将授权码通过回调地址返回给 SeafileSeafile 使用client_secret_basic方式携带凭据在/api/oidc/token换取 Access Token 与 ID TokenSeafile 调用/api/oidc/userinfo获取用户 claims按OAUTH_ATTRIBUTE_MAP建立/匹配本地账户。存量用户迁移如果 Seafile 此前使用本地用户数据库切换到外部 OAuth 认证后存量账户与 IdP 账户之间需要建立映射关系。本指南对应的 Seafile 官方文档中提供了 “Migrating from local user database to external authentication”从本地用户数据库迁移到外部认证的迁移指南已在实践中验证可行建议在正式切换前在测试环境演练迁移流程尤其要核对sub声明与本地uid的绑定关系避免用户登录后生成重复账户。附加步骤为不支持 OAuth 的客户端启用 WebDAV SecretSeafile 的 WebDAV 扩展seafdav在撰写本指南时不支持 OAuth Bearer 认证相关讨论见 seafdav 问题 #76。因此像davfs2这类仅支持 HTTP Basic Auth 的 WebDAV 客户端无法直接使用 OAuth 令牌登录。解决方法是可选地启用 WebDAV Secret在seahub_settings.py中取消注释ENABLE_WEBDAV_SECRET True并在 Seafile 的用户管理选项中配置使这些客户端能够通过 Basic Auth 方式登录从而在统一 SSO 的前提下兼容不支持 OAuth 2.0 的存量工具。参见Seafile OAuth Authentication 官方文档Seafile 的 WebDAV 扩展从本地用户数据库迁移到 OAuth仓库内延伸阅读OpenID Connect 1.0 集成总览含端点实现与支持矩阵OpenID Connect 1.0 客户端配置指南全部客户端选项详解OpenID Connect 1.0 Provider 配置指南OIDC 客户端配置 schema 源码OIDC 集成通用注意事项oidc-common 区块需要提醒的是本文中的insecure_secret与示例域名仅用于演示生产环境请务必使用高强度随机密钥并优先以 PBKDF2 哈希形式写入 Authelia 配置同时确保 Authelia 与 Seafile 均通过 HTTPS 对外提供服务。【免费下载链接】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），仅供参考