基於

Question

目前我們在每個單獨的成員不同領域的一些.Net應用程序是Azure的訪問控制和WIF適合當一些依賴方可能不被.NET。我們正在通過單一登錄（希望單點登錄）和Azure託管的集中式成員身份轉向聯合登錄。

我們的自然選擇似乎是爲Azure的訪問控制創建自己的身份提供商，我們所有的網站都將使用WIF進行身份驗證，但未來可能有非.Net網站需要進行身份驗證。

這仍然是採取一種可接受的途徑？

Answer 1

ACS是「聯邦提供者」。它基本上允許您的「依賴方」（您的應用程序）將身份驗證委派給它。

ACS本身可以信任很多「身份提供者」，包括如果你想你的。目前（ACS V2）支持WS-Federation & OpenID（針對網站），WS-Trust & OAuth（針對Web服務）。這些是「協議」。 ACS支持2種令牌格式：SAML（1.1 & 2.0）和SWT。它還預先配置了Google，Yahoo！，Facebook和LiveID。

如果您的應用程序信任ACS，那麼你就可以接受任何這些服務的帳戶的用戶。 ACS可以使用支持任何這些協議的「任何」IdP。

WIF是「索賠啓用」您的應用程序基於.NET框架和應用堆棧無縫像ASP.NET（和ASP.NET MVC）和WCF。它可以在其他應用程序堆棧上工作，但它需要互操作。但是，每個平臺通常都具有WIF等效功能，只要它符合標準（例如WS-Fed，SAML令牌等）的功能。

互操作也是雙向的。例如：依賴於非MSFT身份提供者的依賴ACS/ACS的非.NET應用程序。

如果您想保留您的會員資格數據庫以進行身份​​驗證（這意味着您仍然有用戶名/密碼），則可以使用STS（使用WIF構建）將其包裝並將其添加到身份提供商列表中。然後任何應用程序（。NET與否）可以根據它使用的身份驗證：

當然，你可以結合兩種：有你的應用程序的信任ACS，然後ACS信任您的IDP（除其他國內流離失所者）。這給你額外的靈活性。

一般來說，如果您在基於.NET的網站上使用WIF，則無需編寫大量代碼（如果有）。一切正常。這一切

例子都可以在這裏：基於

• 身份的培訓工具包
• 索賠身份指南（http://claimsid.codeplex.com）

對於一個非常快速的介紹，檢查斯科特的最新網絡直播：http://scottdensmore.typepad.com/blog/talks.html

Answer 2

OUCH我被帶走了，並注意到依賴方部分後我寫了答案！最後一部分雖然成立。 ACS使用REST併發布SAML or SWT tokens，因此理解它們的任何應用程序都可以使用ACS。

WIF和ACS不需要在客戶現場.NET。事實上，最簡單的使用方法是通過AD Federation Services來驗證用戶的AD域並將SAML令牌傳遞給ACS。

事實上，ACS SDK包含有關配置ACS使用Google,Facebook和Yahoo作爲標識提供程序的文章。

如果您需要針對不同系統（例如內部SSO系統，數據庫等）進行身份驗證，您可以編寫自己的身份提供程序來驗證用戶身份並將適當的令牌發送給ACS。由於ACS使用REST API，因此您可以使用任何您喜歡的平臺或語言來創建提供商。

Answer 3

如果通過「非基於.NET」，你的意思是類似Java應用程序，你可以聯合Java（例如使用OpenSSO或PingFederate）和ADFS。

ADFS可以與ACS聯合。

有許多的ADFS 2.0 Step-by-Step Guides to interoperability

我不知道，如果你能刪除ADFS並簡單地用這些其他產品在其位聯合ACS？任何意見？