Wcf 分布式应用程序中的ASP.NET WebAPI客户端授权

我正在创建一个分布式应用程序，它将使用ASP.NET Web API来支持单页Web应用程序（SPA）和其他潜在的本地移动应用程序平台。我当前的体系结构将用作STS，它将为我的客户端提供授权令牌，以用于访问WebAPI。在后端，我将拥有持久性和业务逻辑，它们将由一个WCF服务在我的WebAPI的一个单独的应用程序域中公开。WebAPI将调用服务层来访问数据并在域上执行操作

我的问题是关于授权的。我将使用基于声明的授权，并可以从我的WCF公开业务层中保存的关于用户的域数据中增加声明列表。但我应该在哪里执行授权？在.NET 4.5中，ASP.NET现在有了一个可扩展的模型，使我能够使用ClaimsAuthorizationManager将授权逻辑从控制器分离到一个单独的授权模块中。此外，在我的WebAPI应用程序中提供了实现这一点的所有管道，这一点做得非常好。然而，我不禁想到授权逻辑应该位于我的业务层，WCF服务的后面，而面向客户机的WebAPI不应该负责执行这一点。如果我要求其他面向客户端的托管应用程序使用我基于WCF的业务层，那么它们还需要实现安全代码。缺点是，它确实意味着未经授权的请求在被拒绝之前会深入应用程序

---

问题：我应该在ASP.NET中使用基于声明的授权功能，还是应该在WCF服务后面围绕我的业务层使用授权？

如果可能，您应该始终尝试使用框架提供的授权工具。在微软的案例中，它是基于声明的授权。好处是，您将授权逻辑隔离在其自身的一层中，而不是在业务逻辑中

---

基于声明的授权是众多授权方法之一。另一种方法是使用XACML。我最近为开发人员（尽管是Java开发人员）做了一次关于XACML的演讲。你可以阅读更多关于它的内容。我还写了一篇关于.NET和XACML的文章，您可以查看。

如果您只通过asp.NET web访问您的服务，那么让您的asp.NET处理授权将更容易，以避免服务请求。如果您将由其他消费者访问您的服务，我相信随着您的服务处理授权，您的服务将更加可靠。是的，我完全同意我应该使用框架工具，而带有MVC的.Net 4.5将帮助我隔离逻辑。这很重要，因为我的授权逻辑将非常精细。将这种复杂性保持在一个地方将最大限度地减少依赖性并便于维护。我关心的是它在建筑中的位置@我想Esteban已经提炼出了这个问题——它归结到我希望在未来如何扩展系统——如果它只是一个WebAPI，那么为什么不使用WebAPI Authz呢。我想XAMCL通过将关注点分开来解决这个问题。首先，这里有一个Microsoft链接，解释如何使用基于声明的授权：