本地ADFS流的正確身份驗證設置是什么？

Question

我一直在閱讀Vittorio Bertocci的博客，以嘗試快速使用ADFS在MVC應用程序或WebApi服務中管理身份驗證和聲明。 看起來它變得非常平易近人。

我現在正在嘗試使用ADFS構建POC，以對企業內部站點/服務進行共同的索賠解決。 我們的用戶將與我們的端點一起位於內部網絡上。 現在，默認情況下，我們現在默認使用Windows Integrated auth，並且每個站點都在執行以下工作：查找用戶名，電子郵件和其他AD詳細信息，並通過IsInRole檢查聲明主體的角色。 我們通過集成身份驗證獲得的聲明僅包括SamIdentifier和一堆組SID。 我希望ADFS可以為我們完成這項工作，但仍然可以為我們的用戶提供無挑戰的體驗。 從長遠來看，我們可能會在某些站點/服務上增加對非域加入設備的支持，因此這是探索ADFS的另一動機。

因此，我在VS2013中使用組織帳戶（內部部署）設置了一個簡單的示例應用程序，該應用程序將轉儲當前用戶的聲明，配置元數據端點和受眾uri，將該信息與我想映射到我的聲明一起傳達ADFS管理員（2012年，順便說一句），並將我的網站部署到開發服務器上。 因此，我的主機仍然是IIS，盡管我希望使用Owin中間件來設置身份驗證，而不是使用web.config（WIF樣式）。

鑒於IIS是我的主機，我如何為我的站點配置身份驗證：匿名？ 而且我的web.config應該為身份驗證模式指定“無”，並且deny =“？” 授權，對嗎？

Vittorio在他的帖子中沒有涉及到本地adfs的另一個問題是，承載令牌的性質以及我們是否需要顯式配置中間件以使用cookie。 我的啟動配置現在看起來像這樣：

    public void ConfigureAuth(IAppBuilder app)
    {
        app.UseActiveDirectoryFederationServicesBearerAuthentication(
            new ActiveDirectoryFederationServicesBearerAuthenticationOptions
            {
                MetadataEndpoint = ConfigurationManager.AppSettings["ida:AdfsMetadataEndpoint"],
                TokenValidationParameters = new TokenValidationParameters() { ValidAudience = ConfigurationManager.AppSettings["ida:Audience"] }
            });
    }

看起來這個中間件期望使用JWT令牌（假設該類上有JwtSecurityTokenHandler）。 我們需要在ADFS端進行任何配置以頒發JWT令牌嗎？ 我的理解是，默認情況下，我將收到SAML令牌。

我們是否應該期望使用CookieAuthentication中間件來管理令牌，還是瀏覽器將在會話的整個生命周期內繼續包含令牌？

謝謝大家！

更新：因此，基於以下Vittorio的幫助和進一步的研究，我現在有了一個簡單的網站，只有一個頁面受[Authorize]屬性保護。 我的啟動類的ConfigureAuth方法現在看起來像這樣：

    public void ConfigureAuth(IAppBuilder app)
    {
        app.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType);

        app.UseCookieAuthentication(new CookieAuthenticationOptions());

        app.UseActiveDirectoryFederationServicesBearerAuthentication(
            new ActiveDirectoryFederationServicesBearerAuthenticationOptions
            {
                MetadataEndpoint = ConfigurationManager.AppSettings["ida:AdfsMetadataEndpoint"],
                TokenValidationParameters = new TokenValidationParameters() { ValidAudience = ConfigurationManager.AppSettings["ida:Audience"] }
            });
    }

我們已經將我的網站添加為對ADFS的依賴方信任，並創建了六個索賠規則。 到目前為止，一切似乎都正確，但我仍在努力。 我點擊了受保護的“聲明”頁面，並收到帶有WWW-Authenticate：Bearer標頭的401響應。 到現在為止還挺好。

就是這樣。 瀏覽器如何知道在哪里進行身份驗證和接收令牌？ 如果我要證明單獨的客戶端方案，則將為我的客戶端配置令牌頒發機構的位置，但是在這種簡單的網站方案中，我顯然缺少了一些東西。

更新2：我想知道本地ADFS的實現是否還沒有准備好？ 或者也許文檔還不存在-或兩者都...

我取出了所有Owin軟件包，並恢復使用WSFederationAuthenticationModule和SessionAuthenticationModule以及已經存在了一段時間的system.identityModel和system-identityModel.services中的所有web.config設置。 基本上，我選擇了“組織帳戶->內部部署”時，使解決方案看起來像是從VS2013獲得的解決方案。 一切正常，我所有配置的聲明都來自ADFS。 我看到最初的302重定向到ADFS（質詢-響應），最終將SAML令牌序列化為安全會話cookie。 在網站上，我這樣回應聲明：

var user = User as ClaimsPrincipal;
ViewBag.Claims = user.Claims;
return View();

這就是為什么我懷疑中間件不完整的原因：當您在VS2013中使用該新模板時，向導轉到您指定的聯合元數據終結點，並通過讀取xml構建所有web.config設置，此外，還設置了一些智能默認值。 這就是我期望在Owin中間件中發生的事情-自從我傳遞相同的元數據端點以來，它應該具有它需要知道的所有內容。 我希望使用FAM / SAM模塊和所有隨附的配置替代“魔術”。

Answer 1

1）如果您正在配置Web UX應用，這是通過瀏覽器重定向來使用的，則您要使用http://www.cloudidentity.com/blog/2014/04/29/use-the-owin-安全組件在ASP網絡中與ADFS /一起實現Web登錄 。 在這種情況下，您會看到cookie中間件確實起作用。

2）如果您正在配置Web API（例如，由胖客戶端或另一台服務器消耗的東西，或者通常不是瀏覽器往返訪問的東西），請參閱http://www.cloudidentity.com/blog/2013/ 10/25 / secure-a-web-api-with-adfs-on-ws2012-r2-got-even-easier / 。 在這種情況下，由於沒有會話，因此您不需要Cookie，每個調用都必須帶有令牌。

HTHV。

Answer 2

正如Vittorio所說，如果僅使用web api或web api創建網頁，則需要區分。 跟隨他的博客文章，他們很棒！

如果您在IIS中托管僅webapi項目，則需要將身份驗證設置為“表單身份驗證”。 如果您的Web API在Web應用程序代理的后面，則此方法也適用。 確保您將端點（已發布的Web應用程序）配置為不進行預身份驗證。 “ preauthenticate”的值應為“ pass through”。

bg Andrej