RESTful API Permission Design – A Preliminary Study

In today’s mainstream backend separation systems, or systems that focus on providing API services, how to protect the RESTful APIs that are provided on the back end becomes very important. There are many aspects of API protection, flow limit, brush prevention, verification can be said to be protection, today to talk about the very important API authentication authentication protection, the general idea. Two things are required: authentication — we can configure which APIs require user authentication to access and which can be accessed directly, and authentication — we can configure management of which APIs can be called and which can’t be called by a given user.

Exceptional – some will say that the page button or page display permissions, personally think that buttons, pages such as display is not displayed, is the front end of the authority management responsibility division, so this time will not discuss it.

certification

The mainstream authentication methods include Token-JWT, Basic Auth, Digest Auth, etc. Users bring authentication information to access the RESTful API, and there will be a pre-filter interceptor (filter,interceptor, AOP can be implemented) on the back end to intercept the request. Obtainment of the authentication information in the request information, through the algorithm verification or with the system user data sources (can come from the database, text, etc.) comparison and judgment, verification will allow the user request process to continue.

This is a general authentication process, there are many details to be considered, such as some APIs need to be accessed without authentication, what is the design of the data source, how to judge the user carrying multiple authentication information and so on.

authentication

After the user authentication process is passed, it is necessary to authenticate the user’s access to the API to determine whether the user can access the API. The mainstream easy-to-use permission model is RBAC – role-based permission model. What we mean by RESTful APIs here is that the API gives the user access to the RESTful API by empowering the role that the user owns. User-Role-Resource.

We will have a restful API request as a resource, resource format for: requestUri = = = httpMethod way as the path of the request and the request (post, get, put, delete, patch) as a whole is seen as a resource eg: / API /v2/book=== =get/API /v2/book Role resource mapping: the role the user belongs to — the role owns the resource — the user owns the resource (the user can access the API)

The above process abstracts configuration data like this:

For RESTful APIs, it is
/api/v2/host===post===[role2,role3,role4]to
/api/v2/hostThe REST API that makes the POST request is delegated to roles Role2, Role3, Role4.

-appid: root, credential: 23456, role: [role1,role2] -appid: root, credential: 23456, role1,role2

/ API /v2/host=== POST: / API /v2/host== POST: / API /v2/host== POST: / API /v2/host== POST: / API /v2/host== POST

It’s OK to abstract data, but it’s also a question of where the data comes from. We can abstract it into data source, general data source we can be database -5 table structure, user table – role table – resource table and two relational associated table. If the system does not have a database, it can be in the form of configuration text or code annotations.

Dynamic permission modification

For permission configuration data, we would certainly like it to be dynamically modified rather than written into the code. If you want to make dynamic changes, then using a facets like Spring AOP for authentication is not appropriate. The data source should come from the database or the configuration text. When the data source is changed through the interface, the in-memory value of the permission configuration information should also be changed synchronously.

URL path matching

Another important point before authentication is path matching. That is, we need to know that the RESTful API that the user accesses matches the API or rules in the configuration data we get from the data source. Only when the match is successful can we know who the API is authorized to, whether the API is login free, etc. Of course, you could also use facets like Spring AOP to authenticate the permissions before calling the method, which eliminates the need for path matching, but this would require you to write a lot of code to dynamically modify the permissions. The main API URL path matching is Ant matching. Look at Spring Security or Apache Shiro, Ant matching rules are used to match the requested URL and configured chain one by one. Is there a more efficient way to do this?


The above is a rough discussion of RESTful API permission design. Later articles will discuss the specific implementation details, such as table design when configuring data source to database, implementation of various authentication methods such as JWT, token refresh, path filtering chain matching and more optimized solutions.


additional

This article introduces a simple and efficient JVM authentication framework for RESTful APIs, Shiro, a third alternative to Spring Security.

Sureness making homepage – https://su.usthe.com/ – https://github.com/tomsun28/s…

RBAC based is primarily focused on securing RESTful APIs


No specific frame dependence (essence filter interception, existing springboot, quarkus, javalin, ktor demo etc.)


Support for dynamic modification of permission configuration (dynamically modify which APIs need to be authenticated and who can access them)


Support for major HTTP container servlets and JAX-RS


Support for multiple authentication policies,
jwt, basic auth, digest auth. Extensible custom supported authentication methods


High performance based on improved dictionary matching tree


Good extension interface, demo and documentation