2011-10-28 103 views
3

我們的應用程序體系結構如下: 1)WCF服務充當外觀層並位於服務,業務邏輯和數據訪問層之上2)每個客戶端,無論是MVC/ASP .NET或任何其他類型的應用程序具有首先需要進行身份驗證併發出「訪問令牌」的ClientTag。此令牌,然後由客戶端與每一個消息到該系統將在Windows Azure上託管的門面層 3)通過Windows Azure上的WCF會話

這本來是很容易與WCF會話像這樣實現: 1)客戶端發起呼叫到WCF獲取令牌(客戶端到WCF會話建立,因此每個後續通信都是同一個「對話」的一部分)。2)WCF對ClientTag進行身份驗證,發佈令牌並將其存儲爲本地變量。 3)客戶端將令牌存儲在它自己的會話中,並將它傳遞給WCF並提供每個請求

如果發生故障,事實上Azure(由於其高可用性/負載平衡性質)doe不支持WCF會話。所以,問題是我們如何實現這一點。

一個解決方案是使用AppFabric緩存來模仿WCF層中的會話狀態。我們會將訪問令牌存儲在那裏,然後根據客戶端傳入的內容對其進行驗證。問題在於客戶端和WCF之間沒有併發性。所以,我們不得不提前來自同一客戶端的每個請求的WCF會話超時,但我們希望避免在每個請求(它可能是數百/秒)上更新緩存。

有什麼建議嗎?有沒有人在Azure上實現過類似的功能。任何反饋將不勝感激。

P.S.這不僅會在服務器上發生身份驗證,還會爲每個客戶端定製授權。 (某些客戶端可能有權訪問某些功能,而其他客戶端則可能無法訪問)。

謝謝!

回答

0

我正在實施與此類似的東西,但使用OAuth 2.0作爲通過ACS的身份驗證體系結構。

我遵循的模型是無恥 被盜 從這裏複製MSDN示例:https://connect.microsoft.com/site1168/Downloads/DownloadDetails.aspx?DownloadID=35417。這假設客戶端具有用戶界面,因此用戶可以直接或通過某些第三方身份提供商提供某種用戶名和密碼。

這種方法的優點是WCF層不需要使用任何類型的會話狀態,所以沒有冗長乏味的機器鍵或什麼東西。不過,你仍然可以得到一些可以映射到IPrincipal的東西,所以如果你想要的話,你可以創建一個自定義的RoleProvider並以通常的方式使用聲明式角色。

請注意,該示例使用了老派的ASP.NET,並且依賴於不透明的(可能更具馬車)程序集Microsoft.IdentityModel.Protocols.Oauth。而且,除非我錯過了一些東西,否則我還沒有看到其他任何地方發佈過的東西(例如,作爲Windows Identity Foundation的一部分),所以我懷疑它是相當新的。

另一種方法可能再次是使用ACS,這次再次遵循OAuth 2.0協議來驗證SAML令牌。詳情和示例代碼在這裏:http://msdn.microsoft.com/en-us/library/windowsazure/hh127795.aspx。這可能更適合於沒有UI的系統。