使用帶有Kerberos令牌的SAML 2.0 SSO的.NET桌面（非Web）應用程序

Question

我已經閱讀了很多有關此內容的內容，以便為客戶實施。 我100％肯定我誤會了某件事，因為眼下這些事在我眼里根本就沒有意義。

我們的客戶希望在我們正在開發的應用程序中添加SSO功能。 其想法是，在啟動時，將程序安裝在其客戶之一上時，該應用程序將使用SSO驗證用戶的身份，以確定是否允許他們運行該程序。

客戶在Intranet上有一個終結點，該終結點應使用用戶具有的角色列表來響應我們的SAML請求，我們將對照授權角色的靜態列表進行檢查，以了解此人是否具有正確的權限。

我們應該使用Kerberos令牌。 現在，我在線檢查的每個頁面似乎都在說那部分。 最初，我認為我必須以某種方式獲取該令牌並將其添加到SAML POST請求中的某個位置。

然后，在谷歌搜索如何獲取令牌時，我得到了越來越 多的結果，我不必這樣做，它是自動完成的，並且端點知道“誰”正在呼叫。

此外， 大多數 網站都假設調用者（我的應用程序）是Web應用程序，並且教程中有很多步驟都在使用Web.Config和服務器，而我都沒有。

由於我嘗試的所有操作似乎都失敗了，並且由於我無法控制端點以檢查其工作方式或出了什么問題（我只會得到錯誤代碼），因此我完全迷失了。

因此，這個問題是關於如何保持記錄的連續性。

我的應用程序不是基於Web的，我沒有創建或看到響應我的請求的端點。

該應用程序在Citrix環境中運行，並且必須與Intranet上的終結點通信。 我本人不在此Intranet上，我們從遠程位置登錄Citrix以進行測試。

我是否必須在代碼中明確獲取Kerberos令牌，如果需要，如何獲取（我見過的每種方法都不適用於我）。

我是否必須在SAML 2.0 POST請求中發送令牌，如果是的話，它在SAML結構中適合什么地方？

Answer 1

這個問題無法回答。 我們無法查看您的應用程序，其Intranet或通過網絡發送的任何流量。

許多應用程序都依賴Windows進行Kerberos身份驗證（更具體地說是協商），Windows通常透明地執行此操作。 在基於瀏覽器的被動方案中，Web服務器將提示輸入401錯誤代碼和“ WWW-Authenticate：Negotiate”標頭，瀏覽器可以理解標頭，並自動以令牌響應。

在基於應用程序的活動情況下，Web服務可能會以相同的錯誤代碼響應，但是通常會提前進行協商，並且應用程序知道可以從Windows手動請求票證。 在某些情況下，.NET之類的某些開發框架也可以為您自動執行此操作。

這些都與SAML沒有任何關系，但是令牌的流程基本上是相同的，但需要注意的是，還有一個額外的躍點，其中Kerberos票證交換了SAML令牌。 這個額外的躍點是不確定的，並且取決於開發人員，但是在執行SAMLRequest時，可以肯定只是一個請求標頭。