This is the third day of my participation in Gwen Challenge

background

Currently, I am working on a spring Cloud micro-service project in the company, and I have found many pain points in the permission verification:

  1. Multiple login methods are mixed together and the code is not clear

Our project supports sso login on the Web side, OAUth login on the enterprise side, and key login for third-party machine access. There are many ways to log in, but there is no unified management. At present, there are two filters, one of which is dedicated to key login, and the other filter is used to determine whether it is the Web end or the enterprise micro end according to the header parameter of the request. If else is used, the code structure is not clear, and the levels of various login methods are unreasonable.

  1. Url access chaos

We are a project with separate front and back ends. For urls that do not require validation, we put them in the Apollo configuration and then make a judgment in the filter to determine whether the URL should be authenticated or not. However, our judgment method is simple and crude. We do not use re, just string matching, and our URL is restful request. A URL may have both GET method and POST method.

  1. The design of authorization is not sound

The design of authorization module in our project is relatively simple. First of all, we manage the menu permissions and determine the menus that can be accessed according to the user roles. As for the back-end interface, the role judgment is strongly coupled in the code, which is not flexible enough. In addition, as the scale of a project increases, more and more roles are required. Therefore, more fine-grained permission control is required.

Project research

Based on the above pain points, I began to investigate the Java permission scheme.

The first is shiro, website address: shiro.apache.org/index.html

Apache Shiro is a security framework for Java that provides authentication, authorization, encryption, and session management. Apache Shiro is being used by more and more people because it is fairly simple. It may not be as powerful as Spring Security, but it may not need to be that complicated in practice. So using Shiro, which is small and simple, is enough. As for which one is good in the end, there is no need to tangle. It is good that the project can be solved more simply.

The core functions are as follows:

  • Authentication: Authentication/login to verify whether the user has the corresponding identity.
  • Authorization: Verifies whether an authenticated user has a specific permission. Check whether a user can do something, for example, check whether a user has a role. Or fine-grained verification whether a user has a certain permission on a resource.
  • Session Management: A Session is managed after a user logs in. All information about the Session is stored in the Session before the user logs out. The session can be in a normal JavaSE environment or in a Web environment;
  • Cryptography: the security of data, such as encrypted passwords stored in a database rather than in clear text;

At the same time, I also went to investigate Spring Security, but was persuaded to quit because it was too complicated.

Comparing Shiro and Spring Security, I summarized the following similarities and differences based on online materials:

Similarities:

  • Authentication function
  • Authorization capabilities
  • encryption
  • Session management
  • Cache support
  • RememberMe function…

Difference:

  • Spring Security is developed based on Spring. If the project uses Spring as the basis, it is more convenient to do permissions with Spring Security, while Shiro needs to integrate development with Spring
  • Spring Security has more features than Shiro, such as Security protection
  • The Spring Security community has more resources than Shiro
  • Shiro is simple to configure and use, while Spring Security is complex to get started with
  • Shiro has low dependencies and does not require any framework or container and can run on its own, whereas Spring Security relies on the Spring container

Therefore, I first adopted Shiro to reform the project, but found that shiro and Spring needed a lot of code changes in combination. In the process of testing, I found a lot of holes and very few network resources in this respect. Most of them were Spring MVC projects, not microservices or separated from the front and back ends. As a result, I was not very smooth in the test process. Another point is that Shiro’s authentication is based on the URL, which still does not solve the problem that my restful request may have multiple methods for the same route (such as GET, POST).

I hope to find a permission framework that is less intrusive to the current code, supports restful interface and Spring Cloud, and has low cost to start. After investigation, I found an open source product sureness of Dromara community.

Some people in China have reformed on the basis of Shiro and opened source a authorization authentication framework Sureness, which is a REST-oriented API, without framework dependence, can dynamically modify permissions, multiple authentication policies, faster, easy to use and extensible authentication framework. I set it as a target for the next stage of my research.

Sureness Project Address:

Github.com/dromara/sur…