background
After increasing enterprise application system, each system separate management of the respective user data is easy to form the information isolated island, dispersion of user management evolution model applied to the platform of the enterprise, to reduce the enterprise cost of system design, development, integration, through technology perfect closed-loop system design implementation process, optimization of enhance the overall experience of the system design, High expansion, easy integration, easy maintenance of each business system is particularly important, through efficient, unified, standardized, low code, easy operation, visualization pull self-service permission control configuration function easily realize the integration of each business system.
Definitions and descriptions of terms
RBAC: role-base Access Control.
Permission predicates: Expressions used to describe or determine the nature, characteristics, or relationships between permissions.
An overview of the
The main characteristics
The main features can be summarized as non-intrusive, easy to configure, easy to maintain, loose coupling, fine granularity, easy to expand, and so on.
- Non-invasive, resources are authenticated by unified permission verification services and filters.
- Easy to configure. You can use the configuration file to configure easy-to-understand permission expressions.
- Easy maintenance. You can easily manage new service components or resource rights by updating the content of the permission expression configuration file.
- Loose coupling, decoupled from business services, enables easy integration of external system functions.
- Fine-grained, permission expression support data permission control, easy to achieve fine-grained permission control.
- Easy to expand, easy to integrate between business systems, without modifying too much source code.
Permissions architecture
The main body adopts RBAC(Role-base Access Control) model, which is a many-to-many user Role relationship model implemented by the association of users with roles and permissions.
The technical architecture
The system adopts microservice architecture, security module adopts OAuth2 open authorization standard, Token adopts JWT standard, and technical framework adopts SpringCloud+SpringGateway+SpringSecurity+ custom permission expression.
Json Web Token (JWT) is an open jSON-based standard (RFC 7519) implemented for the transfer of declarations between network application environments. The token is designed to be compact and secure, especially suitable for single sign-on (SSO) scenarios in distributed sites. The JWT declaration is generally used to pass authenticated user identity information between the identity provider and the service provider to obtain resources from the resource server, and to add some additional declaration information necessary for other business logic. The token can also be used directly for authentication or can be encrypted.
Access configuration
The key configuration
The system follows the OAuth2 open authorization standard protocol. The Token is encrypted by RSA asymmetric encryption algorithm, and the user password is encrypted by MD5.
Permission expression configuration
Authentication is to verify whether a user has the right to access the system. Authentication configuration is to configure which resources require which permissions to access and the relationship between resources and permissions.
The permission profile is located in resources/security.yml
Before introducing the configuration of permission expression, you need to understand the concepts of permission expression, URL path, and permission predicate. Permission expression describes the logical relationship of resource permissions, including the request mode, URL path, and permission predicate. The request mode is HTTP request method, for example: For example, GET, POST, PUT, and DELETE, the URL path is the URL path to be authenticated. It supports wildcard matching. The permission predicate is used to describe or determine the permission nature, feature, or relationship between permissions.
Format syntax
Currently, two types of permission expression syntax are supported: functional permission expression and data permission expression.
Function permission expression
HTTP request method URL path = permission predicate expression
Yellow: space placeholders
Green: URL expression that supports multiple wildcards. For example: /app/*/users, app/**
Orange: equal sign placeholder that describes the right rights required for matching resources on the left.
Blue: permission to predicate, for example: (view && export) | | need to view and edit said export permissions, or edit permissions.
Data permission expression
HTTP request method URL path parameter = permission predicate expression parameter
URL path expression
URL path expression, which is used to configure the path address of the resource to be authenticated. There are three wildcard matching methods for paths, which can be combined to create a variety of flexible path patterns
| The wildcard | describe |
|---|---|
| ? | Matches any single character |
| * | Matches 0 or any number of characters |
| ** | Matches 0 or more directories |
| Example: |
| Path | describe |
|---|---|
| /app/*.x | Matches all.x files in the app path |
| /app/p? ttern | Matches /app/pattern and /app/pXttern, but not /app/pttern |
| /**/example | Matches /app/example, /app/foo/example, and /example |
| /app/**/dir/file | Matching/app/dir/file. The JSP/app/foo/dir/file. The HTML/app/foo/bar/dir/file. PDF/app/dir/file. Java |
| / */ .jsp | Matches any.jsp file |
| Data permission expression URL wildcards add parameter placeholder control |
| The wildcard | describe |
|---|---|
| ? | Matches any single character |
| * | Matches 0 or any number of characters |
| ** | Matches 0 or more directories |
| {parameter name} | Match a single piece of data, for example, parameter value 1 |
| [Parameter name] | Match parameters and batch data, for example: parameter values 1,2,3,100 |
Example:
| Path | describe |
|---|---|
| /app/*.x | Matches all.x files in the app path |
| /app/p? ttern | Matches /app/pattern and /app/pXttern, but not /app/pttern |
| /**/example | Matches /app/example, /app/foo/example, and /example |
| /app/**/dir/file | Matching/app/dir/file. The JSP/app/foo/dir/file. The HTML/app/foo/bar/dir/file. PDF/app/dir/file. Java |
| / */ .jsp | Matches any.jsp file |
| /app/{id}/app/[id] | Matches all paths in app path, equivalent to /app/*, {id}, [id] as parameter placeholders |
| /app/{type}/[id] | Matches two levels of directories under the app path, equivalent to /app//, {type}, [id] are parameter placeholders APP/furniture / 1APP/computer /100 |
| /*/example{type}[id] | Equivalent to /*/example, {type}, [id] for parameter placeholders match /app/example, /app/foo/example, and /example |
Permissions on the predicate
Support and or logic operations, such as: a & b, a | | b, (a & b) | | (c & d), a && b | | c,! a, ! (a & b), for example: the view && export) | | check whether have to view and edit said export permission, or edit permissions.
parameter
For data permission control, row data is uniquely identified to verify whether users have permission to operate the data. Parameter placeholders are parameter names of data locators. Single parameter, compound parameter, single data location authentication ({parameter name} curly braces), and batch data location authentication ([Parameter name] curly braces) are supported. For example, single-parameter userId userId, productId productId, compound parameter type type, productId productId, batch data permission authentication userIds user code set. It is important to point out that each expression is calculated by each piece of data.
Example:
| The parameter types | The data type | describe |
|---|---|---|
| The path parameter | A single | /user/{id}=view |
| /user/{id}/*=edit | ||
| /user/{id}/**=view&&edit | ||
| batch | /user/[id]=view | |
| /user/[id]/*=edit | ||
| /user/[id]/**=view&&edit | ||
| /products/{type}/[id]=view{type}&&download[id] | ||
| Physical parameters | A single | /user{id}=view |
| /user{id}=edit | ||
| /user{id}=view&&edit | ||
| /products{type}{id}=view{type}&&download{id} | ||
| batch | /user[id]=view | |
| /user[id]=edit | ||
| /user[id]=view&&edit | ||
| /products{type}[id]=view{type}&&edit[id] | ||
| /productstype=view[type]&&edit[id] | ||
| Entity-level parameters | A single | / *} {t1, t2: id = edit, said authentication parameters for {” t1 “: {” t2″ : {” id “:” 2 “, “info”, “info”}}} |
| batch | / * t1, t2: ids = edit, said authentication parameters for {” t1 “: {” t2″ : {” ids “:” 1, 2, 3, “” info”, “info”}}} |
/user/{ID}=view&&eidt equals /user/{ID}= View {ID}&&eidt{id} path parameter
| Authentication configuration | GET /user/{id}=view |
|---|---|
| Matching path | GET /user/* |
| Request use case | GET /user/1 |
| describe | Verify that the current user has the permission to view and obtain the data of user 1 |
| Authentication configuration | GET /sales/{productId}/[ids]=view{productId}&&export[ids] |
|---|---|
| Matching road | GET/sales/ / |
| Request use | GET/sales / 1001/1, 2, 3 |
| describe | Verify that the current user has permission to view data of product type 1001 and has permission to export three data of order code IDS 1,2, and 3 (commas will escape) |
Physical parameters
| Authentication configuration | GET /user{id}=view |
|---|---|
| Matching path | GET /user |
| Request use case | GET /user |
| Request parameters | {” id “:” 1 “… } |
| describe | Verify that the current user has the permission to view and obtain the data of user 1 |
| Authentication configuration | GET /user*{id}=view |
|---|---|
| Matching path | GET /user* |
| Request use case | GET /user? id=1 |
| describe | Verify that the current user has the permission to view and obtain the data of user 1 |
| Authentication configuration | GET /user[id]=view |
|---|---|
| Matching path | GET /user |
| Request use case | GET /user? Id = 1, 2, 3 |
| describe | Verify that the current user has permission to view and delete user ids 1,2, and 3 (commas are escaped) |
| Authentication configuration | GET /user[id]=view |
|---|---|
| Matching path | GET /user |
| Request use case | GET /user |
| Request parameters | {” id “:” 1, 2, 3…” } |
| [{” id “:” 1 “…}, {” id “:” 2 “…}, {” id “:” 3 “…}] | |
| describe | Verify that the current user has the right to view and delete user ids 1,2, and 3 |
Composite parameters
| Authentication configuration | GET /sales{productId}{saleId}=view{productId}&&(export{saleId}||edit{saleId}) |
|---|---|
| Matching path | GET /sales |
| Request use case | GET /sales |
| Request parameters | {” productId “:” 1001 “, “saleId” : “1”… } |
| describe | Verify that the current user has the permission to view data of product type 1001 and to export or edit data of order number 1 |
| Authentication configuration | GET /sales{productId}[saleId]=view{productId}&&(export[saleId]||edit[saleId]) |
|---|---|
| Matching path | GET /sales |
| Request use case | GET /sales |
| Request parameters | {” productId “:” 1001 “, “saleId” : “1, 2, 3…” } |
| [{” productId “:” 1001 “, “saleId” : “1”…}, {” productId “:” 1001 “, “saleId” : “2”…}, {” productId “:” 1001 “, “saleId” : “3”…}] | |
| describe | Verify that the current user has the permission to view data of product type 1001 and export orders or edit data of order code 1, 2, and 3 |
| Authentication configuration | GET /sales{productId}[t1:saleId]=view{productId}&&(export[t1:saleId]||edit[t1:saleId]) |
|---|---|
| Matching path | GET /sales |
| Request use case | GET /sales |
| Request parameters | {” productId “:” 1001 “, “t1″ : {” saleId “:” 1, 2, 3…” }} |
| {” productId “:” 1001 “, “t1″ : [{” saleId “:” 1 “…}, {” saleId “:” 2 “…}, {” saleId “:” 3 “…}]} | |
| describe | Verify that the current user has the permission to view data of product type 1001 and export orders or edit data of order code 1, 2, and 3 |
| Authentication configuration | GET /salesproductId= |
|---|---|
| View[productId]&&(export[saleId] | |
| Matching path | GET /sales |
| Request parameters | [{” productId “:” 1001 “, “saleId” : “1”…}, |
| {” productId “:” 1001 “, “saleId” : “2”… }, | |
| {” productId “:” 1001 “, “saleId” : “3”… }, | |
| {” productId “:” 1002 “, “saleId” : “4”… }, | |
| {” productId “:” 1002 “, “saleId” : “5”… }] | |
| describe | Verify that the current user has the permission to view data of product type 1001 and export orders or edit data of order code 1, 2, and 3 |
| Verify that the current user has the permission to view data of product type 1002 and to export orders or edit data of order code 4 and 5 |
Element configuration
Permission configuration consists of permit-Paths whitelist, Jwt-Users guest user, and resource resource permissions. The resource element includes authrities and data-Authrities.
Permit – paths white list
Request path that does not need permission filtering. If some resources in the system do not need permission filtering, configure this element. The following figure shows the configuration syntax.
The resource permission configuration element is the core element of the permission module, including authrities function permission and data-Authrities data permission. The difference between the two is that the function permission controls the URL matching path, and the data permission adds data authentication control on the basis of the URL matching path.
Authrities Function permissions
Function permission control refers to the permission control of service function interfaces, such as the interface for obtaining user list data and adding, deleting, and updating user information.
For example, users can only view and operate data created by themselves, and administrators can authorize specified users or roles to view and operate certain data.
Micro front-end
Microfront-end architecture is a pluggable architecture similar to microservices. It applies the concept of microservices to the browser side, that is, the Web application is changed from a single single application to several small applications that can run, develop and deploy independently.
conclusion
Based on the realization of rights expression system can be easily integrated by integration, the business system as a subsystem, security permissions management into a treatment by the host, the complex, and the access control of high coupling spin off from the business services, business subsystem can focus on business logic to handle, truly seamless integration, reduces the complexity and the difficulty of system integration, This improves the overall performance and maintainability of the system.
System permissions module only implements the basic access control requirements, there are many need to improve, such as the front page function button on the access control, large amount of data access data maintenance trival, one needs to add maintenance menu, functional authority, access data, operation manual configuration authentication data error-prone, and so on.
Maybe there’s something we can optimize in the future.
- Automatic identification of function permission data
Integrating new service maintenance function permission data Requires a comprehensive understanding of service interfaces and maintenance of functional interfaces one by one. URL addresses and permission identifiers are prone to spelling errors. It may be possible to obtain all public resource interfaces of registered services through automatic scanning in certain scenarios. Administrators can automatically view and search for resource interfaces in the system and dynamically import interface data (function permission data).
- Automatically initializes operation rights
General function operations include add, delete, modify, and search. The operation function can be initialized automatically after menu data is added. Users can also add and modify operation function data separately.
- Basic data permissions are configurable
You can select service modules for data permission control as required and automatically import basic data for data permission control.
- Self-service authentication configuration
Users can easily configure data such as whitelists, guest user rights, and resource rights on the visual interface. Authentication configuration data can be imported and exported, for example, automatically lists all function interfaces. You can search for and select resources to be authenticated, and configure permission predicate expressions in a wizard-guided manner.