API Gateway:Configure custom authentication

Create a custom authentication service

1. Log on to the Cloud-native API Gateway console.

2. In the left-side navigation pane, click Instance. In the top navigation bar, select a region.

3. On the Instance page, click the name of the Cloud-native API Gateway instance that you want to manage.

4. In the left-side navigation tree, choose Security Management > Global Authentication.

5. On the Global Authentication page, click Create Authentication. In the Create Authentication panel, configure the parameters and click OK.

   Parameter	Description
   Enable	Enable or disable authentication.
   Authentication Name	Enter a name for the custom authentication service.
   Authentication Type	Select Custom Authentication Service.
   Authentication Service	The backend service that is used to verify tokens and permissions. You can add the service on the Service Management page. For more information about how to add a service, see Add a service. Note Only HTTP services are supported. Services of other protocols such as Dubbo are not supported. If a Kubernetes Service has multiple ports, the first port is used by default. If you want to use another port, you need to create an additional Kubernetes Service in a Container Service for Kubernetes (ACK) cluster and use only the desired port.
   Authentication API	The path of the authentication API provided by the authentication service. The path supports the prefix match method. For example, if your authentication service is built based on Spring MVC and the path of the authentication API is /check, you must use the following configuration to process the request that contains the /check/** path. @RequestMapping("/check/**") public ResponseEntity<RestResult<String>> check(){}
   Token Location	The request header that contains the token. The Authorization or Cookie header can be used as the request header. You can select Select or Add Manually to specify the token location.
   Allowed Headers in Authentication Request	If you want the authentication request to contain headers other than Host, Method, Path, and Content-Length from the business request sent by the client, you must configure this parameter. Note By default, the Host, Method, Path, and Content-Length headers are contained in the authentication request. You do not need to manually add them.
   Allow Headers in Authentication Response	If you need to add headers in the authentication response to the business request from a client, you must specify this parameter. Note If the headers you configure already exist in the business request, the header values are overwritten.
   Allow Body in Authentication Request	If you select Allow Body in Authentication Request, the authentication request contains the body of the business request. Set the Maximum Body Size parameter to the maximum length of the business request body that can be contained in an authentication request. Unit: bytes.
   Timeout Period	The maximum wait time for the authentication service to return results. Unit: seconds. Default value: 10.
   Mode	Valid values: Loose Mode and Strict Mode. We recommend that you select Loose Mode. Loose Mode: If the authentication service is unavailable when a connection to the authentication service fails to be established or a 5xx error code is returned, the Cloud-native API Gateway instance still accepts requests from the client. Strict Mode: If the authentication service is unavailable when a connection to the authentication service fails to be established or a 5xx error code is returned, the Cloud-native API Gateway instance rejects requests from the client.
   Simple Conditions	Click Simple Conditions on the right side of Authorization. Simple rule-based authorization supports the Whitelist Mode and Blacklist Mode. Whitelist Mode: Requests with the hostnames and paths that you specify in the whitelist do not require authentication. Other requests require authentication. Blacklist Mode: Only requests with the hostnames and paths that you specify in the blacklist require authentication. Other requests do not require authentication. Click + Rule Condition to configure domain names, paths, and request headers. Domain Name: the domain names that require access to the Cloud-native API Gateway instance. Path: the paths that require access to the Cloud-native API Gateway instance. Path Match Condition: You can select Exact Match, Prefix Match, or Match Regular Expression. Exact Match: enter a complete path. Example: /app/v1/order. Prefix Match: enter the prefix of a path. You must add an asterisk (*) in the end as the wildcard character. For example, to match all requests that start with /app, you must specify /app/*. Match Regular Expression: Enter an expression that complies with the Google RE2 syntax. For more information, visit RE2 syntax. Case sensitive: If you select this option, path values are case-sensitive. Header: the request header. Click +Request Header to add multiple headers. The AND logic operator is applied to the request headers. HeaderKey: the key of the header field. Condition: the condition that is used to match requests that contain the specified header. Equals To: If the value of a specific key in the header set is the same as the specified value, requests with the header set are matched. Does Not Equal To: If the value of a specific key in the header set differs from the specified value, requests with the header set are matched. Exists: If the specified value exists in the header set, requests with the header set are matched. Does Not Exist: If the specified value does not exist in the header set, requests with the header set are matched. Contains: If the value of a specific key in the header set contains the specified value, requests with the header set are matched. Excludes: If the value of a specific key in the header set does not contain the specified value, requests with the header set are matched. Prefix: If the value of a specific key in the header set uses the specified value as the prefix, requests with the header set are matched. Suffix: If the value of a specific key in the header set uses the specified value as the suffix, requests with the header set are matched. Regular Expression: If the value of a specific key in the header set matches the specified regular expression, requests with the header set are matched. The regular expression complies with the Google RE2 syntax. For more information, see RE2 syntax. Value: the value of the header field.
   Complex Conditions	Click Complex Conditions on the right side of Authorization. Complex rule-based authorization allows you to configure the permission data structure of Envoy in the YAML format. This way, you can configure authorization rules based on a combination of AND, OR, and NOT conditions. Authentication is performed for requests that meet the configured authorization rules. For requests that do not meet the rules, the requested backend resources can be accessed without authentication. Note For more information about the fields of the permission data structure, see Envoy documentation. For more information about how to configure complex rules, see the "Example of complex rule-based authorization" section of this topic.

   Return to the Global Authentication page to view the authentication information. If the configured authentication information about the Cloud-native API Gateway instance is displayed, the custom authentication rule is created for the Cloud-native API Gateway instance.

View and manage custom authentication services

1. Log on to the Cloud-native API Gateway console.

2. In the left-side navigation pane, click Instance. In the top navigation bar, select a region.

3. On the Instance page, click the name of the Cloud-native API Gateway instance that you want to manage.

4. In the left-side navigation tree, choose Security Management > Global Authentication.

5. On the Global Authentication page, find the authentication rule that you want to query and click Details in the Actions column. On the page that appears, view information in the Basic Information and Authentication Configuration sections and view and manage information in the Authorization Information section.

   

   To create an authorization rule, click Create Authorization in the Authorization Information section. In the Create Authorization panel, configure the Request Domain Name, Request Path, and Match Mode parameters and click OK.

What to do next

You can perform the following operations on the authentication rules of a gateway instance:

• 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.

Example of complex rule-based authorization

permissions:
# and_rules indicates that authentication is performed when all the following rules are met at the same time.
- and_rules:
    rules:
      - url_path:
          # The path prefix.
          path:
            prefix: /
      - header:
          # The regular expression.
          safe_regex_match:
            regex: "(exampleA\\.com|exampleB\\.com)"
          # You can use the ":authority" header to obtain the domain name based on the HTTP pseudo-header specifications.
          name: ":authority"

permissions:
# or_rules indicates that authentication is performed if any of the following rules is met.
- or_rules:
    rules:
      # and_rules indicates that the authentication rule is valid if all the following rules are met at the same time.
      # Rule 1
      - and_rules:
          rules:
            - url_path:
                path:
                  exact: /api/appc/bbb/ccc
            - header:
                exact_match: "exampleB.com"
                name: ":authority"
      # Rule 2                
      - and_rules:
          rules:
            - url_path:
                path:
                  exact: /api/appc/ccc/ddd
            - header:
                exact_match: "exampleB.com"
                name: ":authority"
      - and_rules:
          rules:
            # Rule 3
            - url_path:
                path:
                  prefix: /api/
            # not_rule indicates that the authentication rule is valid only when the following configuration is not met.
            # Rule 4
            - not_rule:
                url_path:
                  path:
                    exact: /api/appa/bbb
            # Rule 5
            - not_rule:
                url_path:
                  path:
                    exact: /api/appb/ccc                                
            - header:
                exact_match: "exampleA.com"
                name: ":authority"                                
      - and_rules:
          rules:
            # Rule 6
            - url_path:
                path:
                  prefix: /
            # not_rule indicates that the authentication rule is valid only when the following configuration is not met.
            # Rule 7
            - not_rule:
                url_path:
                  path:
                    exact: /api/appa/bbb
            # Rule 8
            - not_rule:
                url_path:
                  path:
                    exact: /api/appb/ccc
            # Rule 9
            - not_rule:
                url_path:
                  path:
                    prefix: /api/appc/                                         
            - header:
                exact_match: "exampleB.com"
                name: ":authority"