BunkerWeb集成Authelia实现SSO：构建企业级统一认证网关

原创

于 2026-07-04 11:50:13 发布 · 806 阅读

1. 项目概述：为什么需要为BunkerWeb集成单点登录？

如果你和我一样，在运维岗位上摸爬滚打多年，肯定遇到过这样的场景：公司内部或对外服务部署了一大堆Web应用，每个应用都有自己的登录入口和一套独立的用户密码。开发用GitLab，运维用Jenkins，监控用Grafana，文档用Wiki……每次切换都要重新登录，不仅麻烦，密码管理也是个噩梦。更关键的是，安全策略难以统一，一个弱密码就可能成为整个内网的突破口。

这就是单点登录（Single Sign-On, SSO）要解决的问题。而当我们把BunkerWeb——这个功能强大的反向代理和安全防护工具——作为所有Web服务的统一入口时，为其集成一个独立的认证系统就成了刚需。BunkerWeb本身专注于Web安全和流量管理，其认证功能相对基础，通常只支持简单的HTTP Basic Auth或与特定后端（如LDAP）的集成。对于需要复杂认证流程、多因素认证（MFA）、细粒度权限控制的现代企业环境，就显得力不从心了。

因此，我们需要一个专业的、独立的认证授权系统作为“中央认证门户”，所有流量先经过BunkerWeb，再由BunkerWeb将认证请求代理到这个中央门户。用户只需登录一次，即可访问所有挂载在BunkerWeb后端的、已加入信任域的应用。Authelia正是这样一个轻量级、开源、功能全面的SSO和双因素认证解决方案。它支持Web UI登录、TOTP、U2F、推送通知等多种认证方式，并能与LDAP、数据库等多种后端用户存储对接。

本次实战的目标，就是打通BunkerWeb与Authelia，构建一个“BunkerWeb（网关/安全层） + Authelia（认证层） + 后端应用（业务层）”的三层架构。用户访问任何受保护的应用，都会被BunkerWeb拦截，重定向到Authelia的统一登录页面；登录成功后，Authelia会颁发一个可信的会话凭证，BunkerWeb验证该凭证后，再将请求转发给真正的后端应用。整个过程对后端应用透明，应用本身无需任何改造，极大地提升了安全性和管理效率。

2. 架构设计与核心组件解析

在动手敲命令之前，我们必须把整个架构的脉络和组件间的交互逻辑理清楚。一个模糊的方案只会带来无尽的调试痛苦。这套架构的核心思想是“网关前置认证”，即认证动作发生在请求到达业务应用之前。

2.1 核心组件角色定位

BunkerWeb ：扮演“智能门卫”和“交通警察”的角色。它是所有外部流量的唯一入口。其核心职责包括：

路由与代理 ：根据域名、路径等规则，将请求转发到对应的后端服务（如Jenkins、GitLab、内部Wiki等）。
认证中介 ：对于需要认证的路径，它不自己处理登录逻辑，而是将用户重定向到Authelia，并负责验证Authelia返回的认证结果。
安全加固 ：提供WAF（Web应用防火墙）、DDoS防护、速率限制、SSL/TLS终结等安全功能，这是它的老本行。

Authelia ：扮演“中央认证大厅”的角色。它是专门的认证授权服务器，核心职责包括：

统一认证 ：提供标准的登录页面，支持用户名/密码、双因素认证。
会话管理 ：用户成功登录后，Authelia为其创建安全的会话，并生成一个 Authelia-Session-Id 或通过Cookie/JWT来维持登录状态。
身份验证 ：当BunkerWeb带着用户请求来询问“这个人是谁？有权限吗？”时，Authelia负责验证会话的有效性并返回用户身份信息。

后端应用 ：如Jenkins、Nextcloud、Gitea等。它们对认证过程无感知，只接收来自BunkerWeb的、已经过认证的请求。BunkerWeb会在转发请求时，将Authelia验证得到的用户名等信息通过HTTP头（如 Remote-User , X-Forwarded-User ）传递给后端应用，实现“信任代理”模式。

2.2 认证流程与数据流

理解数据流是配置成功的关键。我们以一个用户首次访问 https://jenkins.yourcompany.com 为例：

用户请求 ：用户在浏览器输入 https://jenkins.yourcompany.com 。
BunkerWeb拦截 ：BunkerWeb监听该域名。检查配置发现 / 路径受保护，需要SSO认证。
重定向至Authelia ：BunkerWeb返回 302 Redirect ，将用户浏览器重定向到Authelia的登录页面URL，例如 https://auth.yourcompany.com/?rd=https://jenkins.yourcompany.com 。其中 rd (redirect) 参数非常重要，它告诉Authelia登录成功后要跳转回哪里。
用户登录 ：用户在Authelia的页面上输入凭证完成登录（可能包括密码和TOTP）。
Authelia建立会话 ：登录成功，Authelia在浏览器设置一个安全的会话Cookie（通常作用域为 .yourcompany.com ），并将用户重定向回最初请求的URL（即 https://jenkins.yourcompany.com ）。
BunkerWeb验证会话 ：用户的请求再次到达BunkerWeb，这次请求中包含了Authelia的会话Cookie。BunkerWeb会向Authelia的一个特定验证端点（通常是 /api/verify ）发起一个内部请求，携带这个Cookie。
Authelia验证并响应 ：Authelia验证Cookie有效性，并返回一个JSON响应，包含认证结果（ authentication: success ）和用户名等信息。
BunkerWeb转发请求 ：BunkerWeb确认认证成功，于是将原始请求（可能附加了 X-Forwarded-User: username 这样的头）转发给后端的Jenkins服务器。
用户访问应用 ：Jenkins接收到请求，看到了 X-Forwarded-User 头，便知道用户已经由