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

後續步驟

• AD FS 疑難排解