分布式应用程序中的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客户端授权

回答

相关问题