Configure OIDC authentication for identity authentication and access control - Microservices Engine

The integration between the OpenID Connect (OIDC) protocol and an enterprise authentication system can help implement unified authentication and authorization management of internal services. This reduces repeated coordination operations and simplifies the authentication process. Cloud-native gateways provide unified authentication, strengthen the system security, and provide a more flexible security policy configuration. Single sign-on (SSO) is also supported based on the integration with the OIDC protocol. You can access multiple services by using SSO.

Prerequisites

A unified authentication service that supports the standard OIDC protocol is created.

Background information

To control external access to internal services, gateways authenticate external requests to ensure service security. Typically, an enterprise has a self-managed unified authentication system. Cloud-native gateways can be connected to the self-managed authentication system based on the OIDC protocol and provide unified authentication for the connected internal services. This way, you do not need to separately connect each service to the authentication system.

OIDC authentication

OIDC is an authentication protocol. Based on this protocol, third-party applications can connect to identity providers to obtain user information, and then identity providers send responses securely to the applications. OIDC extends the OAuth2.0 protocol to provide basic user identity information by using the extended ID Token field. ID Token is encapsulated in JSON Web Token (JWT) format to provide a self-contained and tamper-proof mechanism. This ensures that ID Token can be securely transmitted to third-party applications and easily verified.

The following roles are formalized in OIDC:

Client: provides services directly to end users.
Authorization server: the OpenID provider, typically an OpenID authorization server. The authorization server issues ID tokens to third parties. The ID tokens are used for authentication.
Business server: provides business services.
End user: the resource owner.

Process:

The client sends an authentication request to the authorization server.
The end user logs on to the authorization page by using the username and password and confirms the authentication request.
The authorization server validates the authentication request and sends an authorization code to the client.
The client sends a callback request that contains the authorization code to the business server.
The business server sends a request to the authorization server. The request contains the authorization code, client ID, and client secret.
The authorization server validates the request and returns an ID token.
If the authentication is successful, the business server sends the ID token to the client.
The client constructs a business request that includes the ID token and sends the business request to the business server.
The business server validates the ID token and returns a business response to the client.

OIDC authentication in cloud-native gateways

In the preceding OIDC authentication process, if multiple business servers such as user and order servers exist, authentication must be implemented separately for each business server. For example, requests must be separately validated, and each business server must be connected to the authorization server. You can use the OIDC authentication feature of cloud-native gateways to implement unified authentication.

Process:

The client sends an authentication request to the gateway.
The gateway forwards the request to the authorization server.
The authorization server reads the authentication information, such as the username and password, in the authentication request to validate the request. After the request is validated, the authorization server returns an authorization code to the gateway.
The gateway sends a response that contains the authorization code to the client.
The client sends a callback request that contains the authorization code to the gateway.
The gateway sends a request to the authorization server. The request contains the authorization code, client ID, and client secret.
The authorization server validates the request and returns an ID token.
If the authentication is successful, the gateway sends the ID token to the client.
The client constructs a business request that includes the ID token and sends the business request to the gateway.
The gateway validates the business request and passes through the request to the business server.
The business server processes the business request and sends a business response to the gateway.
The gateway forwards the business response to the client.

In the entire authentication process, the cloud-native gateway checks whether all the received requests are valid. If a request is invalid, the gateway redirects to the user logon page and sends a request to the authorization server for user logon. This way, the authorization server is transparent to the business server.

Create an authentication rule

Log on to the MSE console.
In the left-side navigation pane, choose Cloud-native Gateway > Gateways. In the top navigation bar, select a region.
On the Gateways page, click the name of the gateway.
In the left-side navigation pane, choose Security Management > Global Authentication.

In the upper-left corner of the page that appears, click Create Authentication. In the Create Authentication panel, configure the parameters and click OK.

The following table describes the parameters.

Parameter	Description
Authentication Name	Enter a name of the authentication rule.
Authentication Type	Select OIDC.
Issuer	Enter a name of the issuer.
Redirect URL	Enter the redirect URL that is used after the authorization is complete. The value must be the same as the redirect URL that is configured in OIDC. Important The parameter value is in the `http(s)://yourdomain/path` format. In this format, path must be set to `/oauth2/callback`.
Client-ID	Enter the ID of the application in the service registration information.
Client-Secret	Enter the application secret in the service registration information.
Cookie-Domain	Enter the domain name of the cookie. After the user passes authentication, the cookie is sent to the specified domain name to maintain the logon status of the user. For example, if you set `Cookie-Domain` to a.example.com, the cookie is sent to the domain name a.example.com. If you set `Cookie-Domain` to .example.com, the cookie is sent to all subdomain names of example.com.
Scope	Enter the OIDC scope. Separate multiple values with semicolons (;).
Authorization	Select the authorization method. Valid values: Whitelist and Blacklist. Whitelist: Only requests with the hostnames and paths that you specify in the whitelist can access the cloud-native gateway without authentication. Blacklist: Only requests with the hostnames and paths that you specify in the blacklist require authentication. Click + Rule Condition to add domain names and paths. Domain Name: the domain names that require access to the cloud-native gateway. Path: the paths that require access to the cloud-native gateway.

Create an authentication route

After the authentication rule is created, create an authentication route. For more information, see Create a routing rule.

Specify the following parameters:

Domain Name: Select the domain name of the Redirect URL of the authentication rule. If no domain name is configured, select *.
Important
For HTTPS requests, you must configure a domain name and associate it with the route.
Path: Select Prefix from the drop-down list and enter /oauth2 in the field.
Destination Service: Set the value to oauth2-proxy.

View the details of an OIDC authentication rule

Log on to the MSE console.
In the left-side navigation pane, choose Cloud-native Gateway > Gateways. In the top navigation bar, select a region.
On the Gateways page, click the name of the gateway.
In the left-side navigation pane, choose Security Management > Global Authentication.
On the Global Authentication page, click the name of an authentication rule or click Details in the Actions column to view the current authentication configuration and authorization information.

In the Authorization Information section, click Add Authorization Information. In the Add Authorization Information dialog box, specify Request Domain Name and Request Path, select a matching mode, and then click OK.

Verify the result

Return to the Global Authentication page to view the authentication information. If the new gateway authentication rule is displayed, the gateway authentication rule is successfully created.

What to do next

You can perform the following operations on the authentication rules of a cloud-native gateway:

Enable an authentication rule: On the Global Authentication page, find the authentication rule that you want to manage and click Enable in the Actions column.
Disable an authentication rule: On the Global Authentication page, find the authentication rule that you want to manage and click Disable in the Actions column.
Modify an authentication rule: On the Global Authentication page, find the authentication rule that you want to manage and click Edit in the Actions column.
Delete an authentication rule: On the Global Authentication page, find the authentication rule that you want to manage and click Delete in the Actions column.

Note

You can delete an authentication rule only if the authentication rule is disabled.

References

For more information about other authentication mechanisms, see Gateway authentication overview.