composer客户端不支持ldap认证，仅处理http basic auth或bearer token；ldap集成必须由私有镜像服务（如private packagist、artifactory、satis+nginx）在http层实现，客户端只传递凭据，不参与ldap协议交互。
Composer 客户端本身不支持 LDAP 认证，也不参与账号绑定逻辑——这是设计上就决定的，不是配置不到位的问题。
所有试图在 composer.json 或 auth.json 里填 ldap_server、ldap_bind_dn 的做法，都会被忽略，甚至导致 composer validate 报错。真正要做的，是让 Composer 请求发往的那个私有镜像服务（比如 Private Packagist、Artifactory、Satis + nginx）支持 LDAP 登录，并把认证压力转移到 HTTP 层。
Composer 客户端只认 HTTP Basic Auth 和 Bearer Token
当你执行 composer install 时，如果镜像地址返回 401 Unauthorized，Composer 会自动读取 auth.json 中对应域名下的 username 和 password 字段，重新发起带 Authorization: Basic ... 头的请求；如果是 token 模式，则用 Authorization: Bearer ...。
它完全不解析 LDAP 协议、不连接 LDAP 服务器、不执行 bind/search 操作。所谓“绑定账号”，其实是镜像后端服务拿到这组凭据后，在自己的认证流程里去查 LDAP —— 这个过程对 Composer 来说是黑盒。
-
auth.json里只能写username/password或token，不能出现任何 LDAP 相关字段 - 用户名格式取决于 LDAP 中定义的登录属性（常见是
uid、sAMAccountName或mail），必须和镜像服务配置的 filter 一致 - 密码明文存储在
auth.json中，生产环境建议配合COMPOSER_AUTH环境变量或 CI secret 注入，避免提交到代码库
Private Packagist / Artifactory 的 LDAP 绑定实操要点
这类商业或企业级镜像服务原生支持 LDAP 集成，但账号映射方式差异很大：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- Private Packagist：通过后台设置
LDAP_SERVER、LDAP_BIND_DN、LDAP_BASE_DN，并指定LDAP_GROUP_ATTRIBUTE控制用户组同步；它会将 LDAP 用户自动创建为平台账号，且权限继承自 LDAP 组 - Artifactory：需启用内置 LDAP 插件，配置
ldap.url、ldap.managerDn、ldap.userBase；注意 Nexus 3+ 默认禁用匿名绑定，Artifactory 同样要求显式提供 service account，否则搜索用户失败 - 关键点：这些系统不会把 LDAP 密码存下来，而是每次认证都实时 bind 查询；所以用户改密后无需同步，但镜像服务自身必须能稳定连通 LDAP 服务器
Satis + nginx 反向代理实现 LDAP 认证的典型陷阱
Satis 本身无认证能力，必须靠前置 nginx 做 auth 拦截。最容易踩的坑不是配置错，而是权限漏掉：
- nginx 编译时未启用
--with-http_auth_ldap_module，导致auth_ldap指令无法识别 - filter 写成
(uid=${remote_user})，但实际 LDAP 中用户登录名是sAMAccountName，造成匹配失败 - 没配
auth_ldap_cache，高并发下 LDAP 服务器被打满，响应延迟飙升 - 静态资源（如
packages.json）被缓存后绕过 auth，需在 location 块中强制auth_request并禁用 proxy_cache
为什么不能用 laminas/laminas-ldap 替代镜像服务的 LDAP 集成
有人想在 Composer 插件里用 Laminas\Ldap\Ldap 手动拉取用户信息再生成 token，这条路走不通：
-
composer install不加载插件中的认证逻辑，所有插件只能响应事件（如pre-install-cmd），无法拦截 HTTP 请求 - 即使强行 hook，也无法在每次包下载前动态插入 Authorization 头，因为 Composer 的 HTTP client 是封装好的，不暴露中间件机制
- 安全风险极高：在客户端做 bind 操作，等于把 service account 凭据暴露在每台开发机上，违背最小权限原则
真正的账号绑定发生在镜像服务端，不是 Composer 客户端。这个边界划得非常清楚，越界操作只会增加维护成本和安全隐患。
