用 Nginx的auth_request 模块集成 LDAP 认证

作者：freedomkk_qfeng

原文：https://www.jianshu.com/p/9f2da3cf5579

作者已授权运维帮转发

前言

很多时候，我们需要给一些本没有身份认证功能的业务增加一个认证模块。

比如免费版的 ELK，Kibana 上是没有身份认证的；

比如 0.1 版的 Open-Falcon，Dashboard 上也是没有认证的；

又或者一些本来对外公开的网站，突然在某些特殊的日子，在某些特殊的时间里，不希望对外公开了。。。

直接修改业务的侵入式方案通常不太容易，非侵入式的方案一般也能实现类似的效果，比如给他增加一个代理然后做 http basic 认证。

这是一个好办法，但是 http basic 认证毕竟太简单了，也不方便集成外部的认证源，比如 LDAP。

所以一个更灵活的方案是通过 Nginx 的 auth_request 模块

Nginx 的 auth_request 模块

auth_request 大抵就是在你访问 Nginx 中受 auth_reuqest 保护的路径时，去请求一个特定的服务。根据这个服务返回的状态码，auth_request 模块再进行下一步的动作，允许访问或者重定向跳走什么的。因此我们可以在上面去定制我们所有个性化的需求。

假定我们的环境是 centos ，yum 安装 nginx 就略了。由于通过 yum 等安装的 nginx 默认没有编译 auth_request 模块。我们需要重新编译一下。

先运行 nginx -V 来获取当前 nginx 的编译参数

一个简单 demo

nginx.inc 给了一个非常简单的 demo，即 nginx-auth-ldap 这个 repo。

整个逻辑就如下图所示

详细的流程图大抵如下所示：

客户端发送 HTTP 请求，以获取 Nginx 上反向代理的受保护资源。

Nginx 的 auth_request 模块 将请求转发给 ldap-auth 这个服务（对应 nginx-ldap-auth-daemon.py），首次肯定会给个 401 .

Nginx 将请求转发给 http：// backend / login，后者对应于这里的后端服务。它将原始请求的 uri 写入X-Target ,以便于后面跳转。

后端服务向客户端发送登录表单（表单在 demo 代码中定义）。根据 error_page 的配置，Nginx 将登录表单的 http 状态码返回 200。

用户填写表单上的用户名和密码字段并单击登录按钮，从向 / login 发起 POST 请求，Nginx 将其转发到后端的服务上。

后端服务把用户名密码以 base64 方式写入 cookie。

客户端重新发送其原始请求（来自步骤1），现在有 cookie 了 。Nginx 将请求转发给 ldap-auth 服务（如步骤2所示）。

ldap-auth 服务解码 cookie，然后做 LDAP 认证。

下一个操作取决于 LDAP 认证是否成功：

如果认证成功，则 ldap-auth 服务给 Nginx 返回状态码 200。Nginx 从后端服务中请求资源。在 demo 里，后端服务返回以下文本：

Hello, world! Requested URL: URL

如果认证失败，ldap-auth 服务会返回 401 。Nginx 再次将请求转发给后端服务的 Login（如步骤3），并重复该过程。

Demo 测试

Nginx 的配置文件如下，做了些精简，加了中文注释。

然后分别执行 ./nginx-ldap-auth-daemon.py 和 ./backend-sample-app.py 即可。

访问 Nginx 的 8081 端口，可以看到他能够重定向到 backend 上去做认证了。

日志

代码分析

整个 demo 除了 python-ldap 外没有其他的依赖。它的 http 服务使用的是 HTTPServer 模块。

先来看 backend-sample-app.py，它是我们这个 demo 里的 backend。

首先是路由：

可以看到，它维护了两个路由。请求 /login 就跳认证页，否则就输出 Hello, world!

然后看看这个表单：

认证表单本身很简单，可以看到它把 http 头中的 X-Target 取了出来以隐藏的方式重新从表单里提交了上来。这个 X-Target 字段后面会用于认证后的重定向回原始请求页面。

看看拿到提交的数据后做了什么：

这里写 cookie 了，把用户名和密码以 ; 号连接后做 base64 写入 cookie。（注意这很不安全！勿在生产环境中这样写）。然后写 Location 里写入 target 的值，来实现重定向跳回。

很粗暴吧，毕竟只是 demo 而已。

然后我们看 nginx-ldap-auth-daemon.py。这里负责对 nginx auth_request 的响应。

没有 cookie 或者 cookie 不对，回 401：

cookie 正确的，base64 解码拆出用户名和密码来：

然后拿着用户名密码，和 http 头里的 ldap 配置信息去做 ldap 认证。这部分代码挺长的，摘取一小段：

基本就是一个 ldap 认证的标准过程。

拿 binddn 和 bindpasswd 先做一次 bind 获得查询权限。

拿用户名和 searchFilter 去查询，拿到用户的 dn 。

拿这个 dn 再于用户密码做一次 bind，进行 ldap 认证校验。

生产环境

这个 demo 的代码肯定没法直接应用在生产环境中，HTTPServer 适不适合做生产环境暂且不提，把用户名和密码直接写进 cookie 单这一条恐怕就没办法接受。即便像注释里所说的共享个密钥做诸如 AES 之类的加密，也感觉不是太很舒服。

其实这种需求，我们平时都是通过 session 来做的嘛。用户认证后记录一个 session，把 session 写到 cookie 里。下次用户再上来查 session 表里 session 没有过期就可以直接放行了。

而且我们还需要叠加一些特殊的策略，比如某些 IP 地址不认证直接放行，根据时间段选择是否需要开启认证。这些都需要 session 来支持。

这部分，我们留到下回再说吧。

参考文献

nginx-ldap-auth

nginx-plus-authenticate-users

转载授权

CC BY-SA (https://creativecommons.org/licenses/by-sa/4.0/deed.zh)