Previous articles have introduced the essence of single sign-on, including the basic concepts of cookie, session, and redirection, the basic interaction flow of single sign-on, the importance of cookies, and security issues. Single sign-on ensures that you must be authenticated to access a site and that you only need to log in once to access multiple systems.

A complete writing program for the series, see: Series Overview

Index of part I of the series:

  1. Session and cookie introduction
  2. HTTP redirection
  3. Introduction to single sign-on
  4. Cookie Security
  5. Rights Management

Generally, a system has multiple roles that can access different system functions. You can assign different roles to users to determine the system functions that can be accessed by users.

Continuing the first part of the “Single sign-on and Permission Management” series: The nature of single sign-on and Permission Management, this article describes permission management, mainly from the following aspects:

  • A general model for permission management
  • Permission Verification scope
  • Shiro basic architecture and extension points
  • Part 1 of the series

A general model for permission management

The permission verification process is simple and is described as follows:

  1. After a successful login, users will save their personal information and permission information to the session, which can be stored in memory or redis.
  2. When a user accesses another page, the system matches the user permission data based on the access path to verify whether the user has permission to access the page.
  3. If yes, the access page is displayed. If no, a message is displayed indicating that the user has no access.

How to manage and assign user permissions generally abstracts the following entity concepts:

  1. User: a subject that accesses the system;
  2. Role: The smallest unit for assigning rights to users.
  3. Permission menu: The smallest unit of permission. One role is configured with multiple permission menus.

In addition, to facilitate permission management, a service “User center” will be extracted to centrally manage users, roles, and permission menus of each system. The permission menu is synchronized from each subsystem to the user center or provides the function of batch import. The rules for the identification of the permission menu should be agreed in advance. Consistent menu identification is helpful for the judgment of permission interception.

Take a quick snapshot of a few pages from our project to deepen your understanding:

  1. When adding a user, you need to select a role

  2. To add a role, select the permission menu

  3. The permissions menu is synchronized from subsystem to subsystem

Permission Verification scope

Users have the permission to access and operate some data, but not all data. They can only access and operate their own data or data in a group. This is more fine-grained permission control.

The location of permission verification may be in the front end or the back end. The front end displays different menu items and operation buttons according to the current user’s permissions. The back end verifies the validity of the operation and returns accessible data sets according to the current user’s permissions. The location of permission verification should also be considered comprehensively.

Control of particle size

Consider a scenario where there is a query order interface that is externally invoked to return order details based on the order number.

If the order number has rules to find, and the back end does not determine who the order belongs to, the information about other orders can be viewed. Therefore, more fine-grained judgment is required to verify who the order belongs to.

In addition, permissions can be verified by role and menu permissions:

<shiro:hasPermission name="permission1">
    <h2>With permission1 you can see it here</h2>
</shiro:hasPermission>
<shiro:hasRole name="role">
    <h2>Have roles roles you can see here</h2>
</shiro:hasRole>
Copy the code
Verify the location

In order to make the user experience good enough, the menu items and action buttons that cannot be operated by the user need not be displayed any more, and need to be verified in the front end, such as adding user operations:

<shiro:hasPermission name="user:add">
    <a href='user/add'>Add user</a>
</shiro:hasPermission>
Copy the code

Front-end authentication alone is not enough. You can bypass front-end access by emulating HTTP requests. The backend also requires authentication, and Shiro provides an interceptor for uniform processing.

Shiro basic architecture and extensions

Shiro is open source software under Apache, a security framework that manages and authenticates user identities and permissions.

Apache Shiro™ is a powerful and easy-to-use Java security framework that performs authentication, authorization, cryptography, and session management

This article does not cover the details of Shiro, but rather introduces the basic components of Shiro that correspond to a general model of permission management.

Shiro’s basic architecture is as follows:

  1. Subject: the entity currently interacting with the user, including the user, third-party service, corn task, etc. The user only needs to use a series of methods provided by the object to interact with the back-end security management module in a unified manner, corresponding to the “user” in the model.
  2. Authenticator: Is responsible for authenticating the user’s identity. When a user tries to log in, it calls its method for authentication. It calls one or more realms for username and password verification according to the configuration, corresponding to “User login operation” in the model.
  3. Authorizer: Authorizer is responsible for verifying user permissions. When a user accesses a page, it provides methods to verify user permissions. Authorizer also calls one or more realms to obtain user permissions.
  4. SessionManager: provides a robust way to manage user sessions. This is a unique feature of Shiro. If it is a Web/Servlet application, Shiro will use the existing SessionManager by default. If it is not a Web application, Shiro will use the built-in SessionManager. It will call SessionDAO for Session persistence, corresponding to “Session management” in the model;
  5. CacheManager: Shiro in Authenticator, Authorizer, SessionManager module, can access the back-end storage system, using cache management can improve the performance of data access, can be easily integrated with the third-party cache framework, such as Ehcache, Redis, etc.
  6. Realms: Is a bridge between program and user data and permission data, providing extensions in the form of plug-ins that can be configured to support data for Authenticator and Authorizer modules;
  7. Cryptography: provides data encryption and decryption support, it encapsulates the relevant interface, easy to understand and use;

Shiro implements user authentication, permission authentication, session management, cache management, encryption and decryption encapsulation to improve performance and security, and supports extensions via Realm plugins. A custom implementation class obtains user and permission data.

Take user identity authentication as an example to illustrate the interaction process of several components:

Part 1 of the series

By now, the first part of the series “single sign-on and the nature of authority management” is introduced. Through 5 articles, the essence of what I want to say is finished. The basic concepts will certainly be omitted.

Restore the essence of technology, abstract the complex technology and framework, form a relatively simple and easy to understand view, can better understand, expand, apply it.

For single sign-on (SSO), cookies and HTTP redirection are used to automatically redirect and authenticate users, enabling users to access multiple subsystems once logged in.

For permission management, an understanding of its general model and validation process, coupled with a mature implementation framework, can quickly, comprehensively and stably implement it, and expand on this basis.

In addition, cookie, user account permission information is very important, to continue to accumulate security knowledge, improve its security.

The second part is mainly practice. We will make a DEMO imitating our system, and use CAS and Shiro framework to realize single sign-on and permission management. In addition, a “user center” is abstracted to manage users, roles, and permission menus. Each subsystem synchronizes its own permission menus through synchronization.

Series index:

  1. Session and cookie introduction
  2. HTTP redirection
  3. Introduction to single sign-on
  4. Cookie Security
  5. Rights Management