Azure ACS - 最佳實踐實施

Question

嗨，大家好，我們正在Windows Azure上運行從頭構建ASP.NET MCV 3應用程序。 關於認證和授權層，我們正在考慮使用訪問控制服務。 我經歷了一些關於ACS的文章，在那裏我得到了基本的想法，但我仍然對它有一些疑問。

我的理解是，使用ACS我們將認證過程外包給一個或多個身份提供商（IP），基本上我們相信另一個系統（即Microsoft Live ID）來認證我們的用戶。 基本過程非常簡單：在身份驗證階段，我們將用戶重定向到ACS（我們稱之爲「可信」IP），將用戶（通過有效令牌）重定向到ACS並最終重定向到我們的應用程序。 這裏有很多問題......

由於我們不希望所有擁有Live ID帳戶的用戶都可以訪問我們的應用程序，我認爲應該有另一個流程來驗證該用戶並檢查他是否已註冊在我們的應用中。 問題在哪裏？ 在ACS或我們的應用程序中。？

我對此有一個想法，但我不知道它是否是正確的方式： 在註冊階段，系統（我們的Web應用程序）詢問用戶哪個IP（即Live ID，Google， Facebook和我們的應用程序），他想用它在應用程序中對自己進行身份驗證。 然後用戶通過IP系統上的認證過程，當他回來時，我們將他的用戶名（IP用戶名）存儲在我們的數據庫中。 因此，下一次，在驗證階段，我們可以檢查用戶是否在我們的系統中註冊。

如果上述理論是正確的，那意味着在我們的應用程序。我們需要建立我們的會員供應商來存儲來自IP和選擇我們的應用的用戶的用戶名。作爲IP。 我正確嗎？ 設計上述過程的最佳做法是什麼？

現在我們來談談授權和「角色」。 它如何與ACS協同工作？ ACS是否爲每個用戶管理多個角色？

我的理解是，我可以通過ACS創建許多與IP相關的「規則組」，而不是一個用戶。 如果這是正確的，我們如何管理用戶在我們的應用程序角色？ 比方說，我們有多個角色，我們的用戶可以與這些角色相關聯，我們可以使用ASC來管理它嗎？

所以最後的問題是： ACS本身是否覆蓋了整個認證和授權流程？ 我們是否仍需要使用.net會員供應商？ 爲了滿足我們的要求，最佳做法是什麼？

非常感謝您的貢獻。

Answer 1

用戶驗證過程是通過聲明完成的。

在您爲ACS設置IP後，當用戶進行身份驗證時，ACS將從IP獲取有關經過身份驗證的用戶的聲明。您需要在ACS中配置規則，以說明您希望將哪些聲明轉發給您的應用程序。您還可以將聲明轉換爲不同類型，以將收到的聲明標準化爲您的應用程序所期望的內容。

如果要使用ACS實現基於角色的訪問，則可以。在這種情況下，角色就是ACS將發出的另一個聲明，並且您將根據從ACS收到的角色聲明來實現您的應用程序以授予用戶特權。

您可以配置將某些IP輸入聲明映射到角色輸出聲明的ACS規則。 ACS還有一個可以更改這些規則的管理服務，以便您可以實施用戶註冊過程。

ACS中的個人索賠規則與發出索賠的身份提供者有關，但規則組沒有。規則組與RP關聯（您的應用程序）。規則組只是一組索賠轉換規則，告訴ACS：「對於此應用程序，在發出令牌時應用此規則組策略」。

的ACS文檔有很多說關於ACS要求的規則配置，均通過門戶網站，並通過管理服務::

https://msdn.microsoft.com/library/azure/hh147631.aspx

擴展響應：

比方說，你'正在使用ACS對使用WIF的ASP.NET應用程序進行身份驗證。您可以將ACS配置爲使用電子郵件「jdoe@gmail.com」爲谷歌用戶發佈「經理」角色聲明。

現在在您的ASP.NET應用程序中，WIF將會看到這個角色聲明，它將允許您使用HttpContext.Current.User.IsInRole（「Manager」）或web.config等效項來控制訪問。

您可以使用Web UI手動管理這些ACS規則，也可以使用ACS管理服務以編程方式實現將這些規則添加到ACS的註冊過程。在acs.codeplex.com上有一些ACS管理服務樣本。

此外，身份開發培訓教材，對WIF基於角色的訪問一些例子：

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=14347

Answer 2

有關注冊階段問題的一部分，最好的辦法用來識別用戶是NameIdentifier索賠類型

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier。

這對於每個身份提供者都應該是唯一的，並且也是固定的。如果您使用電子郵件地址聲明，它可能會更改爲同一用戶。從技術上講它可能有兩個身份提供商可以使用相同的NameIdentifier（無外的現成的那些與ACS的那樣），所以你可以在的NameIdentifier要求與IdentityProvider聲明類型

http://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider

結合

以保證唯一性。

對於關於角色的部分，我想說使用ACS來發布來自像谷歌這樣的通用身份的角色聲明在每個用戶的基礎上使用ACS中的聲明轉換規則很難管理。您必須爲每個註冊用戶添加一條規則 - 可能不可行。我認爲ACS規則組更適合轉換角色聲明（例如由聯邦ADFS發佈）。你的想法在你的應用程序中做是一個更好的恕我直言。在代碼中，使用WIF執行此操作的位置在自定義ClaimsAuthenticationManager中。您可以覆蓋其Authenticate方法並根據傳入原則中的NameIdentifier聲明，查找成員資格數據存儲區，並根據成員資格數據庫中的角色創建新的IClaimsPrinciple（即，爲每個角色添加角色聲明用戶在）。

然後，您在自定義ClaimsAuthorizationManager中作出您的授權決定。網上有很多關於這方面的很好的樣本和信息。您可以從

http://msdn.microsoft.com/en-us/library/ee748497.aspx