ADFS如何在B2B同盟中啟用SSO

在 B2B情況下一個企業需要存取另一個企業的應用程式或服務可以管理自己的使用者帳戶並定義自己的身份驗證機制, 另一個企業可以定義向組織外部的使用者公開哪些應用程式和服務以及它將接受哪些聲明來提供對應用程式的存取, 為了允許在這種情況下共享應用程式或服務, 企業必須建立同盟信任然後定義它們之間交換宣告的規則w-studio.idv.tw

1. 公司A的外部使用者使用 Web瀏覽器與公司B的 Web伺服器建立 HTTPS連線

2. Web應用程式接收請求並驗證使用者沒有由 Web瀏覽器儲存在 cookie中的有效權杖, 由於使用者未經身份驗證因此 Web應用程式使用 HTTP 302 重導向訊息將用戶端重導向到公司B的同盟伺服器w-studio.idv.tw

3. 用戶端電腦向公司B的同盟伺服器發送 HTTPS請求, 同盟伺服器確定使用者的主網域, 在本例中主網域是公司A

4. Web伺服器再次將用戶端電腦重新導向至使用者主網域(即公司A)中的同盟伺服器

5. 用戶端電腦向公司A同盟伺服器發送 HTTPS請求

6. 如果使用者已登入網域, 同盟伺服器可以取得使用者的 Kerberos票證並使用 IWA代表使用者向 ADDS請求身份驗證, 如果使用者未登入網域, 系統會提示使用者輸入憑證

7. ADDS網域控制站對使用者進行身份驗證, 並將成功訊息以及有關使用者的其他資訊傳回同盟伺服器, 同盟伺服器可使用這些資訊產生使用者的宣告

8. 同盟伺服器根據為同盟夥伴定義的規則為使用者建立宣告, 同盟伺服器將宣告資料放入數位簽署的安全權杖中, 然後將其發送到用戶端電腦, 用戶端電腦將其發送回公司B的同盟伺服器

9. 公司B的同盟伺服器驗證安全權杖是否來自受信任的同盟合作夥伴

10. 公司B的同盟伺服器建立並簽署一個新權杖, 並將其傳送至用戶端電腦, 然後用戶端電腦將權杖發送回所請求的原始 URLw-studio.idv.tw

11. Web伺服器上的應用程式接收請求並驗證簽署的權杖, Web伺服器向用戶端發出 session cookie, 表示身份驗證成功, 同盟伺服器發出基於檔案的持久性 cookie, 預設有效期為 30天, 它消除了 cookie生命週期中的主網域發現步驟, 然後伺服器根據用戶提供的宣告提供對應用程式的存取