AD FS 疑難排解 - Fiddler - WS-同盟
步驟 1 和 2
這是我們追蹤的初始步驟。 在此畫面中，我們看到下列內容：
要求：
- HTTP GET 至我們的信賴憑證者 (https://sql1.contoso.com/SampApp)
回應：
- 回應是 HTTP 302 (重新導向)。 回應標頭中的傳輸資料會顯示重新導向至 (https://sts.contoso.com/adfs/ls) 的位置
- 重新導向 URL 包含 wa=wsignin 1.0，告知我們 RP 應用程式已為我們建置 WS-同盟登入要求，並將此要求傳送至 AD FS 的 /adfs/ls/ 端點。 此稱為重新導向繫結。
步驟 3 和 4
要求：
- HTTP GET 至我們的 AD FS 伺服器 (sts.contoso.com)
回應：
- 回應是認證提示。 這表示我們使用表單驗證
- 按一下回應的 WebView，您可以看到認證提示。
步驟 5 和 6
要求：
- HTTP POST 使用我們的使用者名稱和密碼。
- 我們提供認證。 藉由查看要求中的未經處理資料，我們可以看到認證
回應：
- 回應為 Found，而且會建立並傳回 MSIAuth 加密的 Cookie。 這是用來驗證用戶端所產生的 SAML 判斷提示。 這也稱為「驗證 Cookie」，只有在 AD FS 是 Idp 時才會存在。
步驟 7 和 8
要求：
- 既然我們已經通過驗證，我們會對 AD FS 伺服器執行另一個 HTTP GET，並顯示我們的驗證權杖
回應：
- 回應是 HTTP OK，這表示 AD FS 已根據提供的認證來驗證使用者
- 此外，我們會將 3 個 Cookie 設定回用戶端
- MSISAuthenticated 包含用戶端驗證時的 base64 編碼時間戳記值。
- AD FS 無限迴圈偵測機制會使用 MSISLoopDetectionCookie 來停止最終在同盟伺服器無限重新導向迴圈中結束的用戶端。 Cookie 資料是 base64 編碼的時間戳記。
- MSISSignout 可用來追蹤針對 SSO 工作階段造訪的 IdP 和所有 RP。 叫用 WS-同盟登出時，會使用此 Cookie。 您可以使用 base64 解碼器來查看此 Cookie 的內容。
步驟 9 和 10
要求：
- HTTP POST
回應：
- 回應是 Found
步驟 11 和 12
要求：
- HTTP GET
回應：
- 回應是 OK