授权逻辑在基于api的应用程序中应该放在哪里？ [英] Where should the authorization logic go in an api based application?

问题描述

我有一个全新的基于Rails api的应用程序，我需要在其中实现授权。

总体架构：

反应前端-> Rails API层-> Rails模型/服务器层

在探索不同方法时，我感到困惑。

1. 我们应该将授权逻辑放在API层还是服务层？


2. API层方法：位于前端和API层之间的中间件以及我们所有的api调用将通过授权中间件进行路由，以检查是否允许用户调用该parituclar api。


3. 服务层：所有授权检查都将进入服务层，如果允许用户这样做，我们将在每个数据库操作之前进行检查。 （使用 cancancan / pundit ），如果不允许用户将错误消息抛出到API层。

如果有人可以根据他们的经验提出建议，那将是一个很大的帮助。

解决方案

tl; dr

在应用程序外部-始终外部化授权。将授权逻辑与业务逻辑脱钩。

更长的答案

自从SOA开始以来（面向服务架构，API架构以及现在的微服务，这种趋势一直在打破应用程序孤岛，并以可以重用常见功能的方式设计系统。例如，您使用中央身份验证服务（我希望不会实现自己的身份验证方案）和中央日志记录机制。

授权同样如此。有一种叫做

ABAC实现：XACML& ALFA

通用方法

当今有两种实现ABAC的标准。 XACML提供语言和体系结构（请参见上文）。 ALFA提供了语言。

Ruby中的ABAC

检查此项目： CanCanCan 。

I have a brand new Rails api based application, where i need to implement authorization.

Overall Architecture:

React frontend -> Rails API layer -> Rails model/server layer

While exploring different approaches, I have got a confusion.

1. Should we put the authorization logic in API layer or Service layer?
2. API Layer Approach: We will build some authorization middleware that will sit between our front end and API layer and all our api calls will be routed thorough the authorization middleware to check if the user is allowed to call that parituclar api.
3. Service Layer: All the authorization check will go to service layer and we will have check before every db operation if the user is allowed to do so. (Using cancancan / pundit) and if the user is not allowed throw the error message to API layer.

It would be a great help, if someone could suggest based on their experience.

解决方案

tl;dr

Outside the app - always externalize authorization. Decouple your authorization logic from your business logic.

Longer answer

Since the beginning of SOA (service-oriented architecture), API architectures and now microservices, the trend has been towards breaking down application silos and designing systems in such a way you can reuse common functionality. For instance, you use a central authentication service (you wouldn't, I hope, implement your own authentication scheme) and a central logging mechanism.

The same applies to authorization. There is something called externalized authorization which promotes:

• decoupling authorization logic from the application. Many dev frameworks already do that (Spring Security, Microsoft Claims, Ruby CanCanCan...)
• centralizing authorization logic into a single point of management.
• expressing authorization logic as human-readable policies. This means you can write policies such as
  • Doctors can view the medical records of patients they have a relationship with
• using attributes to define these policies: this is called attribute-based access control (ABAC). It is the de factor authorization model for new app developments (such as API). NIST published an excellent report on the topic in 2013.

Architecture

ABAC promotes the following architecture and flow (more details here)

• Policy Enforcement Point
• Policy Decision Point
• Policy Information Point
• Policy Administration Point

ABAC Implementation: XACML & ALFA

Generic approaches

There are 2 standards that implement ABAC today. XACML provides both a language and an architecture (see above). ALFA provides a language.

ABAC in Ruby

Check out this project: CanCanCan.

这篇关于授权逻辑在基于api的应用程序中应该放在哪里？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！