产品笔记
不托管密码的连接
密码已经保存在企业的 Active Directory 中。如何在不复制密码哈希、不新设入站连接端点的前提下添加现代登录方式？Authrim Relay 正是为此而设计的。
从无法改变的前提出发
员工账户保存在Active Directory中。密码策略、有效期和离职停用，也一直由它管理。这套系统已经运行多年。
现在想加入通行密钥、整理多因素认证、为更多SaaS提供SSO。目标明确，但第一步总会遇到同一个问题：在哪里验证密码？
有些方案把密码哈希同步到云端，有些则请内部目录验证。选择时需要确认凭据放在哪里、由哪一侧建立连接，以及谁负责维护这条路径。
WordWarden让LDAP/AD继续负责验证，同时提供连接路径选择。对于不想公开新入站端点的组织，Authrim Relay使用出站连接。
WordWarden负责什么
Authrim WordWarden是一个目录连接器。它是部署在LDAP/AD附近的小服务，接收用户名和密码，向目录查询，再返回验证结果。
登录界面、会话、通行密钥、邮箱验证码、面向应用的联合身份认证、审计关联和身份映射由Authrim管理。WordWarden只在目录附近执行验证。
连接方向不同，需要配置和维护的网络组件也不同。
谁向谁建立连接
WordWarden有三种连接方式，区别在于组织网络是否需要公开入站端点。
哪一种适合自己的环境
如果新部署不希望增加入站访问，可以先考虑Relay。已有的公开基础设施或隧道也有利用价值。以下是选择方案的例子，并非实际客户部署案例。
Authrim Relay：保留内部AD，不增加外部入站访问
例如，总部运行AD、公开新服务器需要额外审批的企业；或者不允许外部连接校园LDAP网络的大学。WordWarden主动连接Authrim，无需在内部网络新增公开入站端口。
不需要新公开端点，也不需要独立隧道进程。前提是允许WebSocket出站通信，并继续监控WordWarden及其连接。如果网络禁止一切外部通信，Relay也无法使用。
Cloudflare Tunnel：沿用已有隧道运维
如果组织已经通过Cloudflare Tunnel发布内部工具，并有团队负责cloudflared更新和路由，可以把WordWarden纳入同样的流程，无需新增入站端口。
需要配置让Authrim请求到达连接器的主机名与路径，并维护隧道。内部主机不直接接收入站连接，但请求会经由Cloudflare的路径到达。
Direct HTTPS：沿用现有API公开基础设施
企业、大学或研究机构可能已有负责DMZ和反向代理的团队。为Authrim提供可访问的HTTPS端点，就能沿用现有证书管理、访问日志和监控流程。
无需维持额外的隧道或Relay连接。相应地，组织需要允许入站路径，并负责公开端点的保护与维护。公开的是连接器的HTTPS接口，不是把LDAP/AD端口直接暴露到互联网。
无论哪种方式，都要在能够访问LDAP/AD的位置运行WordWarden。并不是学术机构就必须选某一种，而是根据现有基础设施和网络策略来选择。
Authrim Relay：从内部发起的连接
Relay模式下，WordWarden从组织内部通过WebSocket连接Authrim。WebSocket会保持通信路径，让双方都能通过它发送消息。
WordWarden保持连接并等待。有人登录时，Authrim通过同一路径发出“请验证这个用户”的请求，WordWarden查询内部目录，再返回结果。
这就像从组织内部拨出电话后保持通话，对方也可以开口说话。每次请求都不需要从外部重新连接内部网络。
这样，目录所在网络不必为此公开URL，也减少了新公开主机名、证书和WAF的管理。仍需允许出站连接、维护WordWarden并监控连接状态。
技术补充：WebSocket与公开入站端口有什么不同
区别在于由谁首先建立连接。Direct HTTPS需要组织提供Authrim可访问的端点；Relay则由内部WordWarden向Authrim建立加密WebSocket连接（wss）。
常见的有状态防火墙或NAT会跟踪内部发起的连接，并允许该连接的返回流量。因此，WordWarden无需公开接收外部新连接的端口，也无需配置端口转发，就能收到验证请求。
这并不意味着通信不使用端口。通常wss使用目标端的TCP 443端口。防火墙或代理需要允许到Relay的出站访问和持续WebSocket连接。断线期间无法通过该路径接收请求，因此也需要监控。
减少外部新连接入口，不代表已建立的路径不会收到验证请求。仍然需要认证通信方，并验证收到的请求。
出站连接也需要认证对方。Relay同时检查连接器身份与配置的目标。
技术补充：通过HMAC认证连接方
WordWarden对短期挑战返回HMAC响应，对包含挑战ID和nonce的字符串签名，并检查目标URL中的租户ID和连接器ID是否与自身配置一致。
三种连接方式都必须使用HMAC。Relay减少的是入站暴露面，并不能省略连接器认证或秘密信息管理。
究竟有哪些信息跨越边界
这一点需要说清楚：并不是“密码不会离开内部网络”。
用户在登录界面输入密码后，密码会经过Authrim。准确的表述是“Authrim与WordWarden不保存密码”，而不是“密码不会离开组织”。
返回的信息也有限制
验证成功后，Authrim得到结果，以及请求属性中连接器本地允许列表准许的部分。不是请求方决定能取什么，而是目录一侧决定传出什么。
因此，仅修改Authrim一侧的配置，无法扩大从内部网络获取的属性范围。
密码是过渡的桥梁
这种连接是为了逐步迁移。
LDAP/AD继续作为密码权威来源，用户仍使用原有账户登录，同时逐步注册通行密钥。邮箱验证码作为恢复路径保留，让认证方式转换时登录仍可继续。
文档也明确禁止把LDAP/AD密码哈希导出到Authrim。那样做会把迁移桥梁变成凭据副本。
正在准备公开测试版。首个目标版本是v0.1.0-beta.1。
适合试点使用，面向能够在LDAP/AD附近运行小服务，并理解目录、网络、TLS和秘密管理边界的组织。这不是托管目录服务。
需要Authrim 0.3.2或更高版本，并启用Directory Authentication与Relay。当前测试版修改配置后需要重启进程。
复制凭据或开放入站连接，
并非仅有的选择。
在目录附近验证，并由内部建立出站连接，就能在不复制密码哈希、不公开内部入站端点的情况下接入现代登录。
最终希望走向的是通行密钥迁移。目录连接提供了基础，让迁移可以在不打断用户登录的情况下进行。