產品筆記
不保管密碼的整合
密碼已經保存在企業的 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。目前測試版修改設定後需要重新啟動程序。
複製憑證或開放入站連接，
並非僅有的選擇。
在目錄附近驗證，並由內部建立出站連接，就能在不複製密碼雜湊、不公開內部入站端點的情況下接入現代登入。
最終希望走向的是通行金鑰遷移。目錄連接提供了基礎，讓遷移可以在不打斷使用者登入的情況下進行。