分佈式應用程序中的ASP.NET WebAPI客戶端授權

我正在創建一個分佈式應用程序，該應用程序將使用ASP.NET Web API來支持單頁面Web應用程序（SPA）和其他潛在的本地移動應用程序平臺。我目前的體系結構使用Thinktecture Identity Server作爲STS，它將爲我的客戶端提供授權令牌以用於訪問WebAPI。在後端，我將擁有持久性和業務邏輯，這些將由我的WebAPI的獨立應用程序域中的WCF服務公開。 WebAPI將調用服務層來訪問數據並對域執行操作。分佈式應用程序中的ASP.NET WebAPI客戶端授權

我的問題是關於授權。我將使用基於聲明的授權，並且可以從我的WCF公開的業務層中增加有關用戶的域數據的聲明列表。但我應該在哪裏進行授權？在.NET 4.5中，ASP.NET現在有一個可擴展的模型，使我能夠將授權邏輯從我的控制器中分離出來，並使用ClaimsAuthorizationManager作爲單獨的授權模塊。此外，Thinktecture.IdentityModel在我的WebAPI應用程序中提供所有的管道工具來做到這一點非常出色。但是，我不禁認爲授權邏輯應該位於我的業務層中，位於WCF服務之後，並且面向客戶端的WebAPI不應負責執行此任務。如果我需要其他面向客戶端的託管應用程序來使用我的基於WCF的業務層，那麼他們還需要實現安全代碼。不利的一面是，這意味着未經授權的請求會在被拒絕之前進入應用程序。

問題：我應該在ASP.NET中使用基於聲明的授權功能，還是應該在WCF服務背後的業務層中包裝授權？

來源

2013-09-30 jcaddy

如果您只能通過您的asp.net網站訪問您的服務，那麼獲得您的asp.net句柄授權將更容易，以避免服務請求。如果您將通過其他消費者訪問您的服務，我相信隨着您的服務處理授權，它會更加穩固。 – Esteban

如果可能，您應該始終嘗試使用您使用的框架爲您提供的授權工具。在微軟的情況下，這是基於聲明的授權。好處是您可以將自己的授權邏輯隔離在自己的層中，而不是放在業務邏輯中。

基於聲明的授權是許多授權方法之一。另一個將是使用XACML。我最近爲開發人員談論了XACML（儘管是Java開發人員）。你可以閱讀更多有關它here。我還寫了一篇關於.NET和XACML的文章，你可以查看here。

來源

2013-10-01 16:42:39

是的，我絕對同意我應該使用框架工具 - 而使用MVC的.Net 4.5將幫助我隔離邏輯。這很重要，因爲我的授權邏輯將非常細緻。將這種複雜性保持在一個地方將最大限度地降低依賴性並便於維護。我關心的是它應該在哪裏建築。 @Esteban我想已經解決了這個問題 - 這歸結於我希望在未來如何擴展系統 - 如果它只是**將成爲WebAPI，那麼爲什麼不使用WebAPI Authz。我猜XAMCL通過分離問題解決了這個問題 – jcaddy

第一點，下面是一個Microsoft鏈接，解釋瞭如何使用基於聲明的授權：http://msdn.microsoft.com/en-us/library/hh291068.aspx –

分佈式應用程序中的ASP.NET WebAPI客戶端授權

回答

相關問題