是否存在 WsFederationAuthenticationOptions WReply 和 CallbackPath 值可能不匹配的情況？

Question

當使用 ASP.Net OWIN/Katana 使用 WSFederation 設置單點登錄時，存在WReply和CallbackPath屬性。

在示例項目中，這些在Startup.Auth中配置時似乎具有非常相似的值，例如：

new WsFederationAuthenticationOptions() {
   CallbackPath = "/WsFed-Foo", 
   Wreply = "https://example.com/WsFed-Foo"

查看文檔，我看到了這個：

CallbackPath 必須設置為匹配或清除，以便可以動態生成。 此字段是可選的。 如果未設置，則將從當前請求和 CallbackPath 生成。

我很欣賞CallbackPath是可選的，但如果它需要匹配WReply ，那么當它被省略時，為什么 Katana 會自動計算它呢？ 是否存在與 WReply 不同的情況？

Answer 1

也許 Tratcher 在 Github ( https://github.com/aspnet/Security/issues/1645 ) 中發布的內容回答了您的問題？

如果確實如此，他對“Wreply 和 CallbackPath #1645 之間的 WsFed 混淆”問題的回復是：

當 WsFed 從 Katana 移植時，它是經過適度更新的翻譯，大部分原始設計和選項都被保留了下來。 Justin 在測試中注意到，CallbackPath 和 Wreply 之間的修改關系令人困惑，可能會導致我們的客戶無限登錄循環。 Wreply 設置身份提供者返回的地址。 CallbackPath 設置中間件監聽回復的路徑。

在 Katana 中，用戶可以選擇設置 Wreply，而 CallbackPath 將由此派生。 兩者都沒有默認值，如果未設置，則中間件將讀取所有表單發布請求。

在 Core CallbackPath 中，像我們的其他處理程序一樣默認為 /signin-wsfed，而 Wreply 沒有任何價值。 挑戰會從 CallbackPath 生成一個 wreply。 如果有人在沒有更新或清除 CallbackPath 的情況下設置 wreply，就會出現混亂。 服務器將回復處理程序未偵聽的路徑，可能導致無限的身份驗證循環或 404。

將 wreply 設為 WsFed 上的公共選項而不是像其他提供商那樣生成重定向的動機是，眾所周知，WsFed 身份服務器在匹配值方面非常嚴格，以至於需要精確的大小寫等。從用戶生成 url輸入可能不足以進行此檢查。 目前還不清楚有多少客戶遇到了這種不匹配，而那些設置為 wreply 的客戶，因為他們在樣本中看到了它。

不確定這里的最佳前進道路是什么。 我們將看到有多少用戶遇到它。

我在我認為可能會回答您的第一個問題的內容中添加了 emphasys。 關於您的第二個問題，Wreply 和 CallbackPath 不兼容似乎沒有任何意義。 （從技術上講，它們總是不同的，因為 CallbackPath - 與 Wreply 不同 - 不是完整的 URL。）