Composer镜像本身不参与LDAP认证，它只负责包管理；LDAP认证由镜像服务后端（如Nginx、Private Packagist或Artifactory）在HTTP层实现，Composer客户端仅通过auth.json传递HTTP凭据，不解析任何LDAP配置。
Composer镜像本身不参与LDAP认证
这是最容易混淆的点：Composer 是 PHP 的依赖管理工具，它下载包、解析版本、写入 vendor/，但**完全不处理用户登录、身份校验或权限控制**。所谓“Composer 镜像与 LDAP 集成”，其实是两套系统在企业内网中并行协作——LDAP 管理人，Composer 镜像只管包。镜像服务（如 Satis、Private Packagist、Artifactory）若需登录才能访问，那认证环节发生在 HTTP 层（比如 nginx Basic Auth、OAuth2 代理），而非 Composer 客户端内部。
私有镜像服务启用 LDAP 认证的常见方式
真正需要对接 LDAP 的，是托管 Composer 静态文件或提供 v2 协议接口的后端服务。以主流方案为例：
-
Satis：本身无认证模块，必须前置反向代理（如 nginx）。在 proxy_pass 前加
auth_request指向一个支持 LDAP 校验的 auth 服务（如 nginx-auth-ldap 或自研 PHP 脚本），或直接用 nginx 的auth_basic+ LDAP 模块（需编译支持） -
Private Packagist：原生支持 SAML 和 LDAP 直连，后台配置
LDAP_SERVER、LDAP_BIND_DN、LDAP_BASE_DN等即可，用户组映射靠LDAP_GROUP_ATTRIBUTE控制访问权限 -
Nexus / Artifactory：通过内置 LDAP 插件绑定 AD 或 OpenLDAP，配置项包括
ldap.url、ldap.managerDn、ldap.userBase；注意 Nexus 3+ 默认禁用匿名绑定，需显式开启或配 service account
无论哪种，composer install 调用时只传 HTTP 凭据（token 或 Basic Auth），不感知 LDAP 协议细节。
为什么不能在 composer.json 里填 LDAP 参数
因为 Composer 客户端根本不解析 LDAP 配置。你在 composer.json 的 repositories 里写的只是 URL：
{
"repositories": [
{
"type": "composer",
"url": "https://packages.internal.company.com"
}
]
}
这个 URL 后面是否走 LDAP 认证，取决于该地址背后的服务如何拦截请求。如果镜像服务返回 401，Composer 会尝试读取 auth.json 中对应域名的 username/password 或 token 字段再重发——它只认 HTTP 认证头，不认 ldap_bind_dn 这种字段。
常见错误：
- 把
ldap_server、ldap_base_dn写进composer.json→ Composer 忽略，且可能因 JSON 格式错导致composer validate失败 - 误以为配置了镜像源就能自动同步 LDAP 用户 → 实际上用户账号和 Composer 包权限是两套体系，需在镜像服务后台手动关联或通过 group sync 机制打通
auth.json 是凭据传递的唯一安全通道
企业内网中，auth.json 文件必须存在且路径正确（默认在 COMPOSER_HOME，通常是 ~/.composer/auth.json），内容格式严格：
{
"http-basic": {
"packages.internal.company.com": {
"username": "svc-composer-ro",
"password": "xxx"
}
},
"github-oauth": {
"github.com": "xxx"
}
}
关键点：
- 域名必须与
composer.json中仓库url的 host 部分完全一致（不含协议、路径） - 密码不能明文提交到 Git；CI 环境应通过 secret 注入，本地开发建议用
composer config --auth http-basic.packages.internal.company.com ...生成 - 若镜像服务用 Bearer Token（如 Private Packagist），要写成
"bearer": "xxx"，不是http-basic
漏掉 auth.json 或域名不匹配，就会卡在 Could not fetch https://.../packages.json，报 401 或 403，而不是 LDAP 相关错误。
真正难的不是配置本身，而是厘清边界：LDAP 解决“谁可以看这个页面”，Composer 解决“这个页面里有哪些 ZIP 包可下载”。两者交汇点只在 HTTP 认证层，其他任何试图让 Composer “理解 LDAP”的做法，都是在绕远路。
