MongoDB GridFS集成LDAP实现数据库外部认证授权

### LDAP 的“主战场”在 mongod，而非驱动层 我见过很多朋友，一开始就走入了误区。他们试图在 PHP 的 `mongodb/mongodb`、Python 的 `pymongo`，或 Laravel 的 Flysystem GridFS 适配器等驱动层面去“对接”LDAP，结果发现根本行不通。 请记住一条核心原则：LDAP 认证是由 `mongod` 进程负责处理的。它是在 `mongod` 启动时，通过 `security.ldap` 配置项来开启的。你的 GridFS 驱动在发起读写连接请求时，首先必须通过 `mongod` 的 LDAP 认证关卡。 以下是两个非常典型的“翻车”场景： * 你使用类似 `mongo --username uid=user,ou=people,dc=example,dc=com --authenticationMechanism PLAIN ...` 的命令成功连接上了数据库，心里想着“成了”，但一执行 `db.getSiblingDB('myapp').fs.files.find()`，立马报 `not authorized`。 * LDAP 用户成功登录了，却始终无法读取 GridFS 文件的元数据（`fs.files` 集合）或文件内容块（`fs.chunks` 集合）。 原因其实很简单：LDAP 只负责验证“你是谁”，至于“你能做什么”，它并不插手。**权限的最终落脚点，仍然在 `admin` 数据库里那些显式绑定的角色上**。下面是一个标准的配置流程：

use admin

db.createRole({
  role: "gridfs_reader",
  privileges: [
    { resource: { db: "myapp", collection: "fs.files" }, actions: ["find"] },
    { resource: { db: "myapp", collection: "fs.chunks" }, actions: ["find"] }
  ],
  roles: []
})

db.grantRolesToRole("gridfs_reader", [{ role: "read", db: "myapp" }])

db.createUser({
  user: "uid=user,ou=people,dc=example,dc=com",
  roles: [{ role: "gridfs_reader", db: "admin" }],
  authenticationRestrictions: [{ clientSource: ["192.168.10.0/24"] }]
})

注意代码中的 `authenticationRestrictions` 字段，它不是必需的，但我**强烈建议**加上。它能限制该 LDAP 用户只能在指定网段（例如 `192.168.10.0/24`）内使用凭据，有效防止凭证被滥用。 ### 授权阶段的“对暗号”：queryTemplate 与角色名的精准匹配 在 MongoDB 的 LDAP 授权（authz）阶段，有一个非常关键的环节。它会根据 `security.ldap.authz.queryTemplate` 配置的模板，向 LDAP 服务器查询当前登录用户所属的群组。然后，它会将这些返回的群组名，当作角色名，去 `admin` 数据库中寻找对应的角色定义。 因此，这里的匹配逻辑必须做到严丝合缝： * 如果你的 LDAP 服务器返回了 `cn=gridfs-readers,ou=groups,dc=example,dc=com`，那么你在 MongoDB `admin` 库里创建的角色名，必须是 `gridfs-readers`，而不是前面那一长串完整的 DN。 * `queryTemplate` 中的 `{USER}` 变量，替换的是用户名部分。在标准配置中，它只取 `uid=` 后面的值。这意味着，LDAP 条目中的 `memberUid` 字段，应该直接填写 `user`，而不是完整的 DN。 * 如果你使用的是 Active Directory 环境，习惯用 `memberOf` 属性，那么查询模板需要写成类似这样：`dc=example,dc=com?cn?sub?(memberOf=cn=gridfs-readers,ou=groups,dc=example,dc=com)`。请注意，这不是标准的 OpenLDAP 用法，需要先确认你的 LDAP 服务器是否支持这种查询。 下面是一个经典的“踩坑”配置示例：

security:
  ldap:
    servers: "ldap.example.com:389"
    authz:
      queryTemplate: "dc=example,dc=com?cn?sub?(objectClass=groupOfNames)(member=uid={USER},ou=people,dc=example,dc=com)"

这个模板的语法是错误的。LDAP 过滤器不能这样嵌套括号。正确的写法应为：`(&(objectClass=groupOfNames)(member=uid={USER},ou=people,dc=example,dc=com))`。 ### Laravel / Flysystem 适配器：凭据不会自动传递 许多框架的适配器，比如 `league/flysystem-gridfs`，默认使用 PHP 的 `MongoDB\Driver\Manager` 来建立连接。这个驱动并不会自动解析 `mongodb://` URI 中的 `$external` 数据库或 `PLAIN` 机制字段。因此，你不能指望在 URI 中带上认证参数，它就能自动搞定。 错误示例（驱动会忽略 URI 中的 `$external`）：

'mongodb://uid=user,ou=people,dc=example,dc=com:pass@192.168.10.5:27017/?authSource=$external&authMechanism=PLAIN'

正确的做法，是在 Laravel 的 `config/filesystems.php` 配置中，将认证参数明确写出，如下所示：

'gridfs' => [
  'driver' => 'gridfs',
  'connection' => 'mongodb',
  'bucket' => 'fs',
  'options' => [
    'authMechanism' => 'PLAIN',
    'authSource' => '$external',
    'username' => 'uid=user,ou=people,dc=example,dc=com',
    'password' => 'xxx',
  ],
],

同时，务必确保 `config/database.php` 中的 `mongodb` 连接也启用了相同的认证参数。否则，Flysystem 在初始化 Bucket 时，会因为未认证而直接失败。 ### 权限控制的关键落点：文件元数据 `files` 集合 最后，分享一个实战经验。很多人把精力花在控制 `chunks` 集合上，认为那是文件块，需要重点保护。其实，`chunks` 集合只是原始的二进制块，并无业务语义，真正的关键落点在于 `files` 集合。 `files` 集合中的文档包含了 `filename`、`metadata`、`uploadDate` 等业务相关字段。我们可以在 `metadata` 中自定义权限字段，从而灵活控制访问：

{
  "_id": ObjectId("..."),
  "filename": "report.pdf",
  "metadata": {
    "owner_id": "user123",
    "allowed_roles": ["editor", "manager"],
    "is_public": false
  }
}

然后，在应用层通过 `find()` 查询进行运行时检查。例如，在 Laravel 中：

$bucket->find([
  'filename' => 'report.pdf',
  'metadata.owner_id' => 'user123',
  'metadata.allowed_roles' => ['$in' => ['editor']]
])

这种方案的好处在于，它不直接依赖 LDAP 来做细粒度过滤，而是与 LDAP 的用户角色联动。应用层先从 LDAP 获取当前用户的角色列表，然后将其拼装进查询条件。这是目前看来最灵活、也最容易审计的细粒度控制方式。 不过，需要注意一个陷阱：MongoDB 的 `read` 角色，默认允许对 `files` 和 `chunks` 集合执行 `find`，它并不会自动过滤文档内容。换句话说，只要用户拥有 `read` 权限，他就能看到所有文件的元数据。因此，**业务层必须自己做好 `metadata` 字段级的过滤**，这个责任千万不要推给数据库角色。