Shiro’s unified authentication and authorization

Shiro is a simple and easy-to-use Java permissions framework under Apache. For individual applications, Shiro is able to meet the requirements of permissions extremely well and quickly, so generally when doing projects, Shiro will become the developer’s first choice.

However, if you need a second, third, or NTH application that requires the same authentication and authorization, you may need to extend Shiro or integrate with other frameworks to meet your needs.

How does Shiro authenticate and authorize

Shiro itself does not help you implement authentication and authorization, but Shiro does a good job of defining the concept of permission and letting you implement it

  • Authentication In Shiro, authentication is usually done by subject-.login (token), subject represents a user, token represents the authorization information submitted by a user when requesting authorization, Through AuthenticatingRealm. DoGetAuthenticationInfo () to get some information about the current Subject, such as Principals and Credentials, to verify the token of the submitted, if the login is successful, save the current logged in user
  • Authorization in Shiro, access control is such a @ RequiresPermissions commonly, when a user access to a protected resource, Shiro will pass AuthorizingRealm. DoGetAuthorizationInfo (), Check whether users can access the resource from the Principals currently authenticated by Subject

Shiro does both of these things by implementing a Realm, making it very easy to authenticate and authorize your application when it’s a standalone application.

But what do you do when you have multiple applications that need to reuse the same set of user and permission information? You can reuse Realm, and the user permissions are in the same DB, which is fine, but the coupling is so high that different applications have to access the same data source; Alternatively, the DAO related to user permissions can be separated out as RPC or Rest calls, which can also be implemented. But a better approach would be to spin off the entire authentication and authorization service as a separate authentication and authorization service

Unified authentication and authorization based on Shiro

In order to realize unified authentication and authorization, Shiro has CasFilter, which can integrate CAS. However, CAS is another set of framework, which is heavier and has a separate learning cost. Therefore, here we introduce a simpler, lightweight and easy-to-use authentication and authorization service based on Shiro, Shiro-UAA

Authentication and Authorization Process

  1. The user requests the protected Resource Resource Server
  2. Resource Server determines whether the user has logged in
  3. If not, the Resource Server directs the user to the UAA Server for login
  4. The user logs in to the UAA Server. If the login succeeds, the UAA Server returns the code to the user and directs the user to the Resource Server
  5. Resource Server Uses code to obtain the Access-token from UAA Server. The token contains user authorization information
  6. The Resource Server verifies that accessToken is valid, and if so, saves the user information in the Resource Server

The diagram below:

use

  • auth-server
    1. Reference maven
    2. Implement your own login
  • resource-server
    1. Reference maven
    2. As with Shiro, permissions are controlled using relevant annotations

Basically out of the box, auth-Server is currently only available as a JAR package that requires you to implement your own login logic, with deployable services coming later

For details about Shiro-UAA, you can view the project address