Preliminary knowledge
This article discusses the technical solution of identity authentication and user authorization based on the microservice architecture. It is best to be familiar with and understand the following knowledge points:
- Concepts related to microservice architecture: service registration, service discovery, API gateway
- Identity authentication and authorization technologies: SSO, CAS, OAuth2.0, JWT
The following basic concepts:
- Certification
- authorized
- Authentication
- Permission control
Prerequisite background
As the number of enterprise application systems gradually increases, each system manages its own user data independently and easily becomes an information island. The decentralized user management model hinders the evolution of enterprise applications to a platform. When an enterprise's Internet business develops to a certain scale, it will be essential to build a unified standardized account management system, because it is an important infrastructure of the enterprise Internet cloud platform and can bring unified account management, identity authentication, and user management to the platform. Basic capabilities such as authorization bring basic capabilities such as cross-system single sign-on and third-party authorized login to enterprises, providing necessary conditions for building an open platform and business ecosystem.
Mode introduction
Under the microservice architecture, the enterprise's platform ecology must be reasonably divided into businesses. Each business segment will form its own system. These system businesses are relatively independent and should be split independently. Each system can be segmented according to its own business model, and an appropriate domain model can be established after overall analysis of the business model and user needs to form independent services.
In addition, the customer scope of the enterprise platform is relatively complex, including 2B business, 2C business, and 2G (governance). Therefore, unified identity management at the platform level must involve organizational entities and personal entities. Organizational entities include agencies ( G), enterprise unit (B), group organization (B), etc. This is similar to the concept of multi-tenant architecture, but it is more complicated than traditional multi-tenant architecture.
Login authentication issues in microservice architecture
From the past monolithic application architecture to the distributed application architecture to the current microservice architecture, the security access of applications is constantly being tested. In order to adapt to changes in architecture and requirements, identity authentication and authentication schemes are also constantly updated. In the face of calls between dozens or even hundreds of microservices, how to ensure efficient and secure identity authentication? How to provide a fine-grained authentication scheme for external service access? This article will explain the security authentication and authentication scheme under the microservice architecture.
Unified Identity Manager
Unified Identity Management (UIM) is the basis for account and permission control on the entire platform. The system built from it is called UIMS (Unified Identity Management System). Account management, identity authentication, user authorization, permission control and other behaviors of all systems under the platform are Through UIMS processing, it provides account and password management, basic information management, role permission management and other functions.
UIMS is based on the concept of "unified identity governance" and can be divided into three major modules: a two-level account system, a basic permission module and a basic information module. Among them, the two-level account system divides accounts into two categories: organizational entity accounts and personal entity accounts. Personal entities are subordinate to organizational entities, or they may not be subordinate to any organizational entities, and personal entities can be subordinate to multiple organizational entities at the same time; basic authority module Unified management and authorization of resource permissions of each business system;
The basic information module is used to describe the basic information of organizational entities and individual entities, such as the name, address, legal person of the organizational entity, the name, phone number, gender and other basic information of the individual entity. UIMS provides a unified API to connect with various subsystems. Many systems and many services will depend on UIMS.
This article only covers the two modules of the two-level account system and the basic permission module under UIMS. Based on this, the account management service and the permission management service can be independently provided, or they can be combined into one account permission management service. The account management service includes business system entities, organizational entities and personal entity management, and the authority management service includes three parts: authentication, authorization and authentication.
Single sign-on (SSO)
The enterprise platform involves many subsystems. In order to simplify user management of each subsystem and improve user experience, realizing SSO is an important goal of unified identity authentication: one login, all access.
- For internal enterprise applications, SSO is a necessary option, such as enterprise OA, HR, CRM and other internal systems;
- For external applications, SSO is optional. Which application should be added to the SSO system is determined by the business system.
For example, external service systems such as external malls and property systems. No matter what kind of application adopts SSO or not, UIMS should have the ability of SSO technically.
Authorized login
With the gradual growth of platform business, resources such as those relying on the platform and the manufacturers and customers relying on the platform will greatly enrich the platform. Therefore, an open ecosystem must be built to support the further development of the business. The authorized login function at the platform level can be opened to allow access by third-party applications. Through three-party authorized login, the platform's service capabilities can be developed to third parties, and third-party services and capabilities can be connected to the platform for prosperity, symbiosis, and common development.
Inter-service authentication
The business system is divided into different services. Depending on the granularity and business requirements, the number of services and permission requirements are different. Identity authentication and authorization under microservice architecture can be divided into two types:
- Authentication and authorization of internal services;
- Internal services are in a secure intranet environment, such as product services and order services in the BFF layer (Backend For Frontend Layer). When the security requirements are not high, the authentication process does not need to be performed. Services are mutually exclusive. trust.
- Authentication and authorization for external services.
- Authentication and authorization of external services are usually initiated by external applications, which initiate requests to services within the security boundary through reverse proxies or gateways, so a strict authentication process must be implemented. Various services under external applications such as wireless terminal APP, web terminal, and desktop client are all external services.
Technical solutions
Options
The main requirements for identity authentication and authorization under the Unified Identity Management System (UIMS) are put forward. Currently, there are many technical means to achieve unified identity authentication and authorization, which can be summarized into the following two categories:
- Traditional Cookie + Session solution, stateful session mode;
- Token/ticket based solution, stateless interaction mode.
Specifically:
- Distributed Session
- OAuth2.0
- CAS
Each of the above options has pros and cons:
Distributed Session
Distributed Session is an old and mature solution, but because of its stateful communication characteristics and the API-oriented stateless communication advocated by microservices, it conflicts with each other, and shared storage has security risks, so microservices are generally not used.
Distributed Session
OAuth2.0 is a mature authorization login solution in the industry. However, OAuth2.0 provides 4 authorization modes, which can adapt to a variety of scenarios. As a token-based security framework, it can be widely used in scenarios that require unified identity authentication and authorization.
JWT is generally used as the main standard for tokens: JWT (JSON Web Token) is a concise self-contained JSON declaration specification that is widely used in non-centralized authentication/authorization scenarios because of its decentralized storage and self-decryption characteristics. .
Since JWT information is signed, the authenticity of the sender can be ensured and the information has not been tampered with or forged. However, due to its self-contained client-side signature verification feature, once the token is issued, it cannot be revoked. Therefore, simply using JWT as a unified identity authentication and authorization solution cannot meet the needs of unified account logout and destruction, account banning and lifting. requirements, so it is generally used together with OAuth2.0.
Regarding the introduction of JWT, CAS is the most mature open source single sign-on solution nowadays, including CAS Server and CAS Client.
- CAS Server is a war package that needs to be deployed independently and is responsible for user authentication;
- CAS Client is responsible for processing access requests to the client's protected resources and redirects them to the CAS Server when authentication is required.
It is worth noting that CAS is an authentication framework that defines a flexible and complete authentication process. However, it is compatible with mainstream authentication and authorization protocols such as OAuth2, SAML, OpenID, etc. Therefore, the CAS + OAuth2 solution is generally used to implement SSO. and authorized login.
For an introduction to CAS, please refer to apereo.github.io/cas/ Under the microservice architecture, identity authentication and user authorization are usually separated into independent IDP (Identity Provider) services. When making technology selection, the following points should be considered:
- Meet the technical needs of SSO;
- Meet the needs for simplicity and security;
- Meet the needs of openness and scalability.
- After comprehensive consideration, it is recommended to adopt the stateless API mode, among which the solution based on OAuth2.0 can fully satisfy
Client Token Solution
The token is generated client-side, signed by the authentication service, and must contain sufficient information so that the user's identity can be established across all microservices. The token is attached to every request, providing user authentication for the microservice. The security of this solution is relatively good, but authentication logout is a big problem. Ways to mitigate this can be using short-lived tokens and Frequently check authentication services, etc. For the encoding scheme of client tokens, Borsos prefers to use JSON Web Tokens (JWT), which is simple enough and has relatively good library support.
Client Token combined with API gateway
This scheme means that all requests go through the gateway, effectively hiding the microservices. On request, the gateway converts the original user token into an internal session ID token. In this case, logging out is not an issue because the gateway can revoke the user's token upon logging out.
share resources
To obtain the above resources, please visit the open source project and click to jump.