本章處理的形態是每個客戶帶自己的身分提供者（客戶那一端常稱為「我們的 SSO」）進來，於是「用哪一個身分來源」從一次選型變成一項要做成設定的能力。對接的協定通常是 SAML 或 OIDC。

它在 7.38 外部身分與本地紀錄 的上一層——那一章假設對應關係已經接上，處理接上之後兩條生命週期怎麼走；這一章問的是這個接法要做成幾組設定、誰來填、以及填的內容憑什麼可信。

本章涵蓋與不涵蓋

本章聚焦身分接入這一層的多租戶設計。要不要委派、與自建的取捨在 7.31 認證方式選型。接上之後的停用同步、資料歸屬與多來源對應在 7.38。租戶之間的資料與資源隔離是另一個問題，走 tenant boundary 與 7.2 身分與授權邊界——本章的每一個決定都建立在那條邊界已經成立的前提上，而它自己不負責建立它。機器對機器的跨組織信任走 7.10 Workload Identity 與聯邦信任邊界。

判讀軸：租戶歸屬由誰主張、由誰驗證

單一身分提供者的系統只有一組設定，於是「這個人該去哪裡驗證」沒有分歧。每個客戶各帶一組之後，登入流程多出一個前置步驟：先決定這次要用哪一組設定，才有辦法開始驗證。

這個前置步驟就是本章的判讀軸，而它要拆成兩問。由誰主張——是使用者提供線索（輸入信箱、輸入公司代碼、從專屬的登入網址進來），還是租戶事先登記過什麼規則。由誰驗證——那個主張憑什麼可信。

兩問分開才看得到風險的位置。路由本身只是把請求送到某個身分提供者，它不做安全判斷；**安全判斷落在「這條路由規則當初憑什麼被建立」上。**規則建立時沒有驗證，缺口的大小在那一刻就固定了，之後每一次路由執行只是把它兌現——而每一次執行看起來都完全正常。

網域宣稱要驗證

最常見的路由依據是使用者信箱的網域：填了 someone@example.com 就去找登記了 example.com 的那個租戶。這個做法本身沒有問題，問題在於 example.com 這條登記是怎麼建立的。

租戶在設定頁填一個網域就生效時，這是一個未經驗證的宣稱。填的人不需要擁有那個網域，也不需要與它有任何關係。而這條規則一旦生效，所有使用該網域信箱的人在登入時都會被送到這個租戶的身分提供者——那個身分提供者由填設定的人控制，他可以替該網域下的任何一個身分簽發憑證。

驗證的做法是要求證明網域控制權，與簽發網站憑證時的做法同型：在該網域的 DNS 放一筆指定的記錄，或在網域根目錄放一個指定的檔案，平台去查。這一步把「宣稱」變成「證明」。選網域當路由依據時，後面的每一個決定都建立在它成立的前提上；換成專屬登入網址或租戶代碼時這個前提就不存在，而「主張 vs 驗證」這個問題只是移到另一個欄位上——誰能替某個組織申請那個網址、租戶代碼猜不猜得到、猜中之後會不會導向錯誤的租戶。同型的機制與它各自的失效形態見 ACME 自動化——網站憑證簽發用的網域驗證挑戰（DNS 記錄、網域根目錄的檔案）解的是同一個問題。

公用信箱網域要單獨處理。 一般消費者信箱服務的網域不代表任何組織歸屬——同一個網域下的使用者彼此沒有關係，也沒有任何人擁有它。這一類網域一律不開放登記，做法是一份拒絕清單，在登記那一步擋掉。這條規則要與控制權驗證並存而不是二選一：驗證處理的是「你有沒有這個網域」，拒絕清單處理的是「這個網域根本不該被任何人拿來當租戶依據」。

清單這個做法有它自己的性質要一起接受：它永遠落後於新出現的信箱服務，而落後不產生訊號；對允許自訂網域的信箱服務它判不出來；用公開清單就繼承那份清單的更新節奏與誤判，自己維護則落後得更多。被清單擋住的正當客戶也要有退路——一人公司、顧問與外包用消費者信箱是真實形態，他們走的是租戶代碼或專屬登入網址，這條路要事先備好而不是等客訴才想。

驗證通過之後這個事實會過期：網域到期、易主、被轉出，而登記是永久有效的。前任持有者的登記留著，新持有者的使用者就被路由到舊租戶。所以要定期重驗，並定義重驗失敗時的行為——停用該筆登記而不是靜默放行。

還有一個殘留問題：**同一個網域被兩個租戶主張。**集團旗下的多家公司、併購之後尚未合併的組織都會產生這個形態。處置是把它做成明確的衝突狀態並要求人工介入，而不是讓後登記的覆蓋先登記的——覆蓋是安靜的，而它把整批使用者的登入路徑換掉。

自助設定的範圍怎麼切

自助的價值在導入速度，而它的風險在於客戶填的內容有一部分會移動安全邊界。切的方法是把設定按「填錯會不會改變誰進得來」分成兩類。

不影響邊界的可以完全自助：登入頁的識別標誌、按鈕文字、成功之後導向哪裡。填錯的後果是外觀不對，客戶自己會發現。

影響邊界的要有額外的關卡：允許的網域清單、身分提供者的簽章憑證與端點位址、要不要保留密碼 fallback、哪些使用者算管理者。這一類的處置有三個層次可選，按客戶規模與平台的人力決定——要求控制權證明（網域這一項的最低門檻）、要求變更由該租戶既有的管理者確認、或由平台的人審核。

密碼 fallback 這一項值得單獨看。單一組織的內部系統刻意不留 fallback，理由是留了就等於在對方的紀律之外開一道門（見 7.31 使用者的身分從哪裡來）。多租戶的形態把這個決定變成每個租戶各自的選項，於是它要做成設定，而預設值要選在關閉那一邊——預設開啟時，多數客戶不會去看那個開關，而平台這一側等於替他們決定了留著一道門。

設定的變更要進稽核紀錄，而且要通知該租戶的管理者。 這一層的變更改變的是「誰進得來」，重要性與登入事件不同量級，判讀見 7.7 稽核追蹤與責任邊界。

N 份設定就是 N 份生命週期

單一身分提供者的系統只有一個到期日要顧。每租戶一組之後，身分提供者的簽章憑證、端點位址與中繼資料各有各的更新節奏，而它們不會一起到期。

這一項的失效形態很具體：某個租戶的身分提供者換了簽章憑證，平台這一側還存著舊的，於是那個租戶的全體使用者同時登不進來。這件事在平台的整體指標上幾乎看不見——一個租戶的登入失敗淹沒在總量裡，而受影響的那一端感受到的是服務全面中斷。

處置有兩層。自動更新：多數身分提供者發布中繼資料端點，平台定期抓取就能跟上憑證輪替，這是最省事的一層。到期監控：抓不到中繼資料的租戶要把憑證到期日記下來並排告警，而告警的收件者要包含平台這一側，因為客戶那一端多半不知道這條依賴存在。

這與 7.5 的憑證輪替覆蓋不足 是同一個問題在身分層的形態，判別方式也相同：問「這個到期日清單的分母是從哪裡數出來的」。分母來自自動更新那套機制時，它衡量的是自動化管得到的那些，與實際租戶數無關。

判讀流程

  1. 先確定路由依據是什麼：信箱網域、公司代碼、專屬登入網址，或組合。每一種各自對應不同的驗證需求。
  2. 依據含網域時，把控制權驗證做成登記的必要條件，並準備一份公用信箱網域的拒絕清單。兩者並存。
  3. 定義同一網域被多個租戶主張時的行為，做成明確的衝突狀態而不是後者覆蓋前者。
  4. 把設定按「填錯會不會改變誰進得來」分兩類，只有不影響邊界的那一類完全自助。
  5. 密碼 fallback 做成每租戶的設定，預設關閉。
  6. 設定變更進稽核紀錄並通知該租戶的管理者。
  7. 建立到期日清單，分母要獨立於自動更新機制，並排告警給平台這一側。

這個決定失敗時長什麼樣

最不直觀的形態是未經驗證的網域宣稱。

平台做了自助接入，客戶在後台填自己的信箱網域就能接上身分提供者。要求控制權驗證的提案被拿掉了，理由是它會增加導入摩擦，而當時的優先事項是縮短客戶從簽約到上線的時間。

某個帳號（可能只是一個試用帳號）登記了一個他不擁有的網域。從那一刻起，任何使用該網域信箱的人在這個平台登入時都被路由到他控制的身分提供者，而他可以替該網域下的任何身分簽發憑證，於是他以那些人的身分進入平台，看到他們的租戶資料。

沒有人發現的原因是整個流程的每一步都成功：路由規則命中、身分提供者回傳有效簽章、平台驗證通過、會話建立。日誌裡是一次合法的單一登入，與其他幾萬次沒有差別。要看見它得從另一個方向問：這條路由規則當初是憑什麼建立的——而那個問題在登入流程的任何一個環節都不會被問到，因為規則建立與規則使用是兩個時間點。

常見風險邊界

  • 網域登記不要求控制權證明時，任何租戶都能把別人的使用者路由到自己控制的身分提供者，而每一次登入看起來都合法。
  • 只做控制權證明而沒有公用信箱網域的拒絕清單時，缺口留在「沒有人擁有、因此也證明不了、但驗證邏輯可能放行」的那一類網域上。
  • 同一網域被多個租戶主張而由後者覆蓋時，一整批使用者的登入路徑會安靜地換掉。
  • 自助設定的範圍按「客戶想不想自己改」切而不是按「會不會改變誰進得來」切時，邊界類設定會落進完全自助的那一邊。
  • 密碼 fallback 的預設值是開啟時，平台等於替沒去看那個開關的客戶決定了留著一道門。
  • 身分提供者憑證的到期日清單由自動更新機制列舉時，抓不到中繼資料的那些租戶不在分母裡，而它們正是會出事的那些。

接下來讀什麼