Vibe了一个nginx认证插件,完成反代的全面自主替代

我们前面已经将nginx反代从手搓nginx.conf升级到了nginx-ui图形版本，那么现在离替代原来老旧的那套反代就差最后一步了：和认证集成。

先说为什么要这个功能，我司内部有很多业务系统属于应当是纯内网访问的状态（系统老旧、漏洞多），这种系统理论上是完全不应该放在互联网上裸奔的，任何一个脚本小子都会把你扫个底朝天。大多数单位的解决方法是，加一个SSLVPN在前面。

但是我看着我们那台十年前买的Sangfor SSLVPN，想着它居然到现在不坏已经是谢天谢地了，更何况用了VPN有个问题，就是用户需要提前知道这个系统能否外网访问，而再去决定是否开VPN，这样体验就很差：他打开系统很可能是“该页无法显示”，这个原因可能是外网隔离造成的，也可能是系统真的崩了，这就会给我们增加很多的解释成本。

于是早几年我们将某品牌的反代改造了一下，利用了它和CAS认证集成的功能实现了一个无感操作。大致意思就是，用户还是访问原始地址，反代会判断你的源IP：

• 如果你是外网，那么先弹一层CAS登录，实际上这个CAS是针对反代自身的。

• 如果你是内网，则直接让你登录。

这样的好处就是，用户无需记住是否需要登录VPN，并且针对已经做过了CAS认证（应用系统自身的认证）的平台，你直接登录就好了，第一次登录（反代认证）和第二次登录（应用认证）由于使用了CAS协议，实现了无感单点，体验会好很多。比如你在门户里登录，直接点击就行，无论你在内网外网都是无感自动登录。但是对于脚本小子、扫描器，由于他没有认证状态，会增加不少工作量。

但是商业平台毕竟需要费用，过了保单位也不给钱买续保，脸皮薄也不好意思老找人帮忙，加上商业产品有些底层是不透明的，出了故障就很被动，于是就想着用开源替代。这事挂在脑子里挂了很久，一直没干完，今年上半年开始Vibe Coding，于是干脆让AI干算了。

上半年先是让AI写了个基于OpenResty的CAS插件，一直都没找到机会部署。然后这几天研究nginx-ui，突然发现有个OAuth2-Proxy的产品，于是干脆一鼓作气，搞完算了。

当前版本的架构如下：

• 首先，nginx-ui正常部署，基于原生的nginx就行了，OAuth2-Proxy基于OIDC协议，很轻松就集成了，只需要nginx启用auth_request插件就行；

• 其次，我们这次没有用CAS协议，因为CAS相对是一个比较老的协议了，去年年底当时我们做计划的时候，我塞进去了一个认证项目，对他的要求就是对于新协议的支持一定要完善，所以现在我们直接可以支持CAS\SAML\OAuth\OIDC等最新协议了。

• 接下来，Vibe了一个插件，虽然看起来代码不少，但实际上在nginx的侵入就一行：直接在server段新增一条：include /opt/nginx-cas-plugin/conf/oauth2_site.conf

• 最后就比较简单了，代码都是AI写的，实现的功能就是对于启用了的站点，首先会校验是否有OAuth状态，如果有，那么直接登录，没有，则弹出统一的登录框让你认证。

• 认证完就一切正常访问，后续如果再次打开类似站点，直接就可以打开了，无需二次认证，因为已经有了认证后的cookie。

• 因为OIDC能传递用户信息，所以后续还可以针对性的做一些反代层面的安全策略，当然，这是后话了。

如果说缺陷的话，现在还是有，最主要的就是这个配置的增加（虽然就一行）暂时只能手工改配置文件，并且当你的站点很多的时候，你也很难去知道哪些站点引用了，哪些没有。这是一个比较大的问题。当然，后续也可以通过Vibe来解决，这个还在思考怎么实现。

题外话，搞IT的，架构设计一定要有前瞻性，如果没有这个持续了大半年好不容易落地的认证项目，今天这事情也干不起来，还困在CAS上纠结。前两天看ustc的认证系统，发现他们都不推荐CAS协议了，直接建议用户上OAuth。

唉，我老是批评别人搞技术的时候自娱自乐，现在想想自己，其实也是自娱自乐，标题我写着完成自主替代，看起来很牛逼，其实也就这么回事，没人上心的。没辙，搞技术的，在咱这，也就这样了，开心就好吧。