Technology architecture based on micro-service API level permissions

In general, a mature system of permissions within an enterprise is a role-based approach to access control (Rbac–role Based access controls), where permissions (Permission) are associated with roles. Users are given permissions to these roles by becoming members of the appropriate role, with permissions that contain resources (or combined with the combination of operations), which ultimately achieve the purpose of permission control. Background

A privilege system is a security rule or security policy set by a system that allows users to access and access only the resources they are authorized to.

In general, a mature system of permissions within an enterprise is a role-based approach to access control (Rbac–role Based access controls), where permissions (Permission) are associated with roles. Users are given permissions to these roles by becoming members of the appropriate role, with permissions that contain resources (or combined with the combination of operations), which ultimately achieve the purpose of permission control.

Word, the access logic expression of the role-based access control method is "what is done by WHO (which)", which is the internal logical structure of the user---a role----a role corresponding to bind multiple permissions, a user corresponding to bind multiple roles, This is also the basic guiding ideology of the Qin Yu Infrastructure Department for the implementation of public rights services.

Diagram of the rights service and other public services in the infrastructure department I. API permissions definition, warehousing and interception

For API permissions, we implement annotation-based (Annotation) scanning warehousing and interception, without the need for business services to input themselves on the interface

1. Permission definition

API permissions are linked to each interface or method in the implementation class as a permission resource, with each permission and the MicroServices name (service name).

We define permissions by adding annotations to the API of the business service. The Infrastructure Department provides a permission component (Permission Component) jar to the Business Services department, which contains custom annotations that are implemented in such a way that the impact on business services is very small, and that adding a permission mechanism only adds several annotations at the code level. The specific use of the following methods

For a common interface class, we can define this:

12345678

@Group (name = "User Permission Group", label = "Users rights group", Description = "User rights group") public Interface userservice { @Permission (name = "Add user", label = "adding users") boolean addUser(@UserId String UserId, user user); @Permission (name = "Delete User" , label = "Remove users", Description = "Delete user") boolean deleteuser(@UserId String UserId, user user); }

For APIs exposed through the swagger approach, we can define:

12345678910111213141516

@Path ("/user") @Consumes (Mediatype.application_json)@Produces (Mediatype.application_json)@Api (value = "User resource Operations") @Group (name = "User Permission Group", label = "Users rights group", Description = "User rights group") public Interface userservice { @GET@Path ("/adduser/{userid}") @Permission (name = "Add user", label = "adding users") boolean addUser(@PathParam ("userId") @UserId String userId, user user); @POST@Path ("/deleteuser/{userid}") @Permission (name = "Delete User" , label = "Remove users", Description = "Delete user") boolean deleteuser(@PathParam ("userId") @UserId String userId, user user); }

In the short code above, we can see that there are three custom annotations, @Group, @Permission, and @userid.

• @Permission, define a permission for each API (interface method), require name (English format), label (Chinese format), and description (permission description)
  • @Group, that is, the defined permissions belong to which permission group, considering that an interface contains many APIs, the number of interfaces is more, then we can all the methods under each interface is grouped into a single group. Business services can define their own permission groups, or they can choose not to define them, and they will be attributed to the default predefined permission group.
• [email protected], that is, business services need to add user ID parameters to their API, when AOP slice interception does permission verification, the user ID is required to pass in the necessary parameters

2, access to storage and interception

When the API permission is defined, we add the algorithm of scanning permission and interception in the permission component. We use the Spring Autoproxy Auto-Proxy framework to implement our scanning algorithms.

2.1 To create the Permissioninterceptor.java inheritance Org.aopalliance.intercept.MethodInterceptor, proceed as follows

• Implement the object Invoke (Methodinvocation invocation) method to get the annotation value
• Different section interception based on different annotations, enabling the @group, @Permission and @userid three annotations to intercept logic

2.2 To create a Org.springframework.aop.framework.autoproxy.AbstractAutoProxyCreator class that inherits spring, follow these steps: Permissionautoproxy.java

The
• sets the Interceptor universal proxy in the constructor (that is, the interceptor class that implements the Methodinterceptor interface Permissioninterceptor.java)
• Shouldproxytargetclass is used to determine whether an interface agent or a class proxy. In the definition of permissions, we also support the annotation on the implementation class, not just on the interface, so flexible use of annotation placement-
• Getadvicesandadvisorsforbean is the most central method to determine which class, Which method of the annotation to be scanned into the library, also determines which class, which method to be proxied. If we do a bit more generic, we can abstract three methods for Getadvicesandadvisorsforbean to call

12345678

//return to intercept class, the interception class must implement meth Odinterceptor interface, i.e. permissioninterceptor protected abstract class<? Extends methodinterceptor> getinterceptorclass ();  //returns the annotation on the interface or method name of the class, if the annotation exists on the method name in the interface or class, it is assumed that the interface or class needs to be proxied abstract class<? extends annotation> Getmethodannotationclass ();  //after scanning to the interface or the annotation on the method name of the class, the processing abstract void methodannotationscanned< Span class= "params" > (class<?> targetclass);

2.3 To create a Permissionscanlistener.java implementation of Spring's Org.springframework.context.ApplicationListener.ApplicationListener interface, proceed as follows

• Implementing the inbound code in the Onapplicationevent (Contextrefreshedevent event) method

• event that the permission data is automatically triggered when the spring container of the microservices is started

  Through the above elaboration, we realized the permission of the scanning storage and interception

(role) Management of API permissions

A role is a summary of the set of API permissions, and each role will be linked to the microservices name. Role groups are designed to summarize and manage a multitude of roles

Role management needs to be manually operated on the interface, role management is divided into role group additions and deletions, as well as the role of each role group additions and deletions to the search

Third, the role of API permissions and users (user) binding

Permissions cannot be directly bound to the user and must be associated with a role as an intermediary bridge. Then we have to achieve

• Binding of roles to permissions, that is, the Association of one role and multiple permissions
• User-to-role binding, which is the association of one user and multiple roles

Binding pages for Roles and permissions

Bindings page for users and Roles </center

Iv. Authorization system authentication Mode 1, API access authentication method

Calls over remote RPC mode

1.1 Scan access to Permission component API Resource

1234567

@Configuration @ComponentScan (basepackages = { "Com.omniprimeinc.service.myservice"}) @Import ({com.omniprimeinc.commonservice.permission.api.config.Config.class, Com.omniprimeinc.commonservice.permission.annotations.config.Config.class})public class config {  }

1.2 Using API resource to invoke RPC interface to get validation results

123456789

@Path ("/authorization") @Consumes (Mediatype.application_json)@Produces (Mediatype.application_json)@Api (value = "Authorization resource Operations") public Interface Authorizationresource { @GET@Path ("/authorize/{userid}/{permissionname}/{servicename}") Boolean Authorize(@PathParam ("userid") String userId, @pathparam("Permissionname ") string permissionname, @pathparam(" ServiceName ") string serviceName); }

2. How to validate rest calls

Http://host:port/authorization/authorize/{userid}/{permissionname}/{servicename}

The return result is true or false with the user ID, Permission name (permission name, mapped to the corresponding method name), Service name (application name)

V. Integration of rights services and user Services

User Services that integrate the users of the LDAP system and the Bridging business user system

After access to the user Service, you can select the appropriate user for permission authorization on the Permission authorization page.

Vi. security control of rights services

Future planning, calls between services add the following mechanisms

• Black/White IP list mechanism. When the a service invokes the B service, the B service implements the maintenance of a black/White IP list, indicating that the B service only allows a service in an IP segment to have permission to invoke B service
• The Secretkey of the Inter-service agreement. When a service invokes the B service, the implementation of the contract API access key between two services is not easily compromised. This avoids the invocation of the B service being simulated rest request (for example, by postman)
• The API signature for the service. When the a service invokes the B service, a service needs to obtain the correct signature of the B service API to have permission to invoke

http://blog.springcloud.cn/sc/mfw-jq/

Technology architecture based on micro-service API level permissions