Preliminary knowledge

This article discusses the technical solution of identity authentication and user authorization based on microservices architecture. It is best to be familiar with and understand the following points:

  • Concepts related to microservices architecture: service registry, service discovery, API gateway

  • Authentication and authorization technologies: SSO, CAS, OAuth2.0, JWT

The following basic concepts:

  • certification
  • authorization
  • authentication
  • Access control

If the background

As the number of enterprise application systems increases, each system can easily manage its own user data into information islands, and the decentralized user management mode hinders the evolution of enterprise applications to platforms. When the Internet business development of the enterprise to a certain scale, the construction of a unified standardized account management system is essential, because it is an important infrastructure, enterprise Internet cloud platform can bring unity for platform account management, identity authentication and user authorization ability, bring enterprises such as single sign-on (sso) across the system, the third party authorization login ability, It provides necessary conditions for building open platform and business ecosystem.

Model is introduced

Under the micro-service architecture, the platform ecosystem of the enterprise must be reasonably divided into businesses. Each business segment will become its own system, and these systems are relatively independent and should be separated independently. Each system can also be divided 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 an independent service.

In addition, the enterprise platform of customer range is more complex, there are 2 B business, there are also 2 c, there were 2 G (goverment), therefore the platform level of unified identity management must involve two types of organizational entities and individual entities, organizational entities including authority (B) (G), enterprise units, groups (B), etc., this is similar to the concept of a multi-tenant architecture, However, it is more complex than traditional multi-tenant architectures.

Login authentication issues for microservices architecture

From single application architecture in the past to distributed application architecture and now microservice architecture, application security access has been constantly tested. In order to adapt to the changes of architecture and requirements, identity authentication and authentication schemes are constantly updated and reformed. How to ensure efficient and secure identity authentication in the face of calls between tens or even hundreds of microservices? How to provide a fine-grained authentication scheme for external service access? This paper will explain the security authentication and authentication scheme under the micro-service architecture.

Unified Identity Manager

Unified Identity Management (UIM) is the basis of account and permission Management of the entire platform. The Unified Identity Management System (UIMS) constructed from this is called UIMS. Accounts Management, Identity authentication, user authorization, and permission control of all systems on the platform are handled by UIMS. Provides functions such as account and password management, basic information management, and role rights management.

Based on the concept of unified identity governance, UIMS can be divided into three modules: two-level account system, basic authority module and basic information module. In the two-level account system, accounts are divided into organizational entity accounts and individual entity accounts. The individual entity may be subordinate to the organizational entity or not to any organizational entity, and the individual entity may be subordinate to multiple organizational entities at the same time. The basic permission module manages and authorizes the resource permissions of all business systems.

The basic information module is used to describe the basic information of the organization entity and individual entity, such as the name, address, legal person, name, telephone number, gender and other basic information of the organization entity. UIMS provides a unified API for connecting subsystems. Many systems and many services will depend on UIMS.

This paper only deals with the two-level account system under UIMS and the basic permission module, according to which account management service and permission management service can be independent or combined into one account permission management service. Account management service includes business system entity, organization entity and individual entity management, and authority management service includes authentication, authorization and authentication.

Single sign-on (SSO)

Enterprise platforms involve many subsystems. In order to simplify user management of each subsystem and improve user experience, SSO is an important goal of unified identity authentication: one login, all access.

  • SSO is a mandatory option for enterprise internal applications, such as enterprise OA, HR, and CRM.
  • SSO is optional for external applications. It is up to the business system to decide which application should join the SSO system.

For example, external mall, property system and other external service system. Regardless of whether or not the application adopts SSO, UIMS should technically have SSO capabilities.

Authorized to log in

With the gradual growth of the platform business, the platform will be greatly enriched by the resources based on the platform, manufacturers and customers, so an open ecosystem must be built to support the further development of the business. You can open the platform-level authorization login function to allow third-party applications to access. Through the authorized login of the three parties, the service capabilities of the platform will be developed to the third party, and the services and capabilities of the third party will be connected to the platform for prosperity and common development.

Inter-service authentication

Service systems are divided into different services. The number of services and permission requirements vary according to the granularity and service requirements. There are two types of identity authentication and authorization in the microservices architecture:

  • Authentication and authorization of internal services;

    • Internal services, such as goods and orders in Backend For Frontend Layer (BFF), are in a secure Intranet environment. If security requirements are not high, authentication is not performed and services trust each other.

  • Authentication and authorization of external services.

    • The authentication and authorization of external services are usually initiated by external applications, which send requests to services within security boundaries through reverse proxies or gateways. Therefore, strict authentication procedures must be implemented. Services in external applications such as wireless apps, Web servers, and desktop clients are external services.

Technical solution

An alternative to

The main requirements of identity authentication and authorization under THE unified Identity Management System (UIMS) are put forward. At present, there are many technical means to realize unified identity authentication and authorization, which can be generally classified into the following two categories:

  1. Traditional Cookie + Session solution, stateful Session mode;
  2. Token/ticket based solution, stateless interaction mode.

Specific have

  • Distributed Session
  • OAuth2.0
  • CAS

Each of the above schemes has advantages and disadvantages:

Distributed Session

Distributed Session is an old and mature solution, but it is generally not adopted by microservices because of its station-oriented communication characteristics and apI-oriented stateless communication advocated by microservices, and shared storage has security risks.

Distributed Session

OAuth2.0 is a mature authorized login solution in the industry. However, OAuth2.0 provides four authorization modes, which can adapt to a variety of scenarios. As a token-based security framework, OAuth2.0 can be widely used in scenarios requiring unified identity authentication and authorization.

JWT is generally adopted as the main Token standard: JWT (JSON Web Token) is a concise self-contained JSON declaration specification that is widely used in non-centralized authentication/authorization scenarios due to its decentralized storage and self-unsigned features.

Because JWT information is signed, it ensures the authenticity of the sender and that the information has not been tampered with or forged. However, due to its self-contained client verification feature, once issued, the token cannot be revoked. Therefore, JWT alone as a unified identity authentication and authorization scheme cannot meet the requirements of unified account logout and destruction, account closure and cancellation, so it is generally used together with OAuth2.0.

About THE introduction of JWT, CAS is the most mature open source single sign-on scheme, including CAS Server and CAS Client.

  • The CAS Server is a WAR package that needs to be deployed independently and is responsible for user authentication.
  • The CAS Client processes the access requests to protected resources on the Client and redirects the access requests to the CAS Server for authentication.

It is worth noting that CAS is an authentication framework, which itself defines a flexible and complete authentication process, but it is compatible with mainstream authentication and authorization protocols such as OAuth2, SAML, OpenID, etc. Therefore, CAS + OAuth2 scheme is generally adopted to realize SSO and authorized login.

For details about the CAS service, see apereo.github. IO/CAS/In the microservice architecture, Identity authentication and user authorization are usually separated into independent Identity Provider (IDP) services. In the selection of technology, the following points should be considered:

  • Meet SSO’s technical requirements;
  • Meet the need for simplicity and security;
  • Meet the requirements of openness and expansibility.
  • Overall consideration, it is recommended to adopt stateless API mode, which can be fully satisfied with the scheme based on OAuth2.0
Client Token scheme

The token is generated on the client side, signed by the authentication service, and must contain enough information to establish user identity across all microservices. Tokens are attached to each request to provide user authentication for microservices. This solution is relatively secure, but authentication logoff is a big problem and can be mitigated using short-term tokens and frequent checking of authentication services. For encoding client-side Tokens, Borsos prefers JSON Web Tokens (JWT), which is simple enough and has good library support.

Client Token is combined with API gateway

This scenario means that all requests go through the gateway, effectively hiding the microservices. On request, the gateway converts the original user token to an internal session ID token. In this case, logout is not an issue because the gateway can revoke the user’s token upon logout.

The resources

www.jianshu.com/p/2571f6a4e…