Configure custom authentication and authorization

Create a custom authentication rule

1. Log on to the API Gateway console.

2. In the left-side navigation pane, click Cloud-native API Gateway > Instance. In the top navigation bar, select a region.

3. On the Instance page, click the name of the target gateway instance.

4. In the left-side navigation pane, click 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	Note: Custom Authentication Service
   Enable	Specifies whether to enable authentication and authorization for the Cloud-native API Gateway.
   Authentication Name	A custom name for the authentication and authorization rule.
   Authentication Type	Select Custom Authentication Service.
   Authentication Service	The backend service used for authentication and authorization. You can add services in service management. For more information, see Add a service. Note Only services that use the HTTP protocol are supported. Services that use 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 a different port, create an additional Kubernetes Service in Container Service for Kubernetes (ACK) that exposes only the target port.
   Authentication API	The path of the API provided by the authentication service. The gateway uses this path for prefix matching. For example, if your authentication service is built on Spring MVC, exposes the authentication API /check, and you want to handle requests for paths starting with /check/, you can configure it as follows: @RequestMapping("/check/") public ResponseEntity<RestResult<String>> check(){}
   Token Location	The location of the token in the request header, typically Authorization or Cookie. You can either Select from a list or Add Manually to set the token location.
   Allowed Headers in Authentication Rrequest	Specifies which headers from the original client request should be forwarded to the authentication service. Note The Host, Method, Path, and Content-Length headers are included by default and do not need to be added manually.
   Allowed Headers in Authentication Response	Specifies which headers from the authentication service's response to add to the request sent to the backend service. Note If a header specified here already exists in the client request, the gateway overwrites its value.
   Allow Body in Authentication Request	Allow Body in Authentication Request: Includes the body of the original client request in the request sent to the authentication service. Maximum Body Size: The maximum size of the request body that can be forwarded, in bytes.
   Timeout Period	The maximum time, in seconds, to wait for a response from the authentication service. Default: 10.
   Mode	Specifies the behavior when the authentication service is unavailable. Loose Mode and Strict Mode are supported. We recommend that you use Loose Mode. Loose Mode: If the authentication service is unavailable (for example, the connection fails or the service returns a 5xx error), the gateway allows the client request to proceed. Strict Mode: If the authentication service is unavailable (for example, the connection fails or the service returns a 5xx error), the gateway rejects the client request.
   Simple Conditions	Next to Authorization, click Simple Conditions. This mode supports Whitelist Mode and Blacklist Mode. Whitelist Mode: Requests that match the hosts and paths in the whitelist can bypass validation. All other hosts and paths require validation. Blacklist Mode: Requests that match the hosts and paths in the blacklist require validation. All other hosts and paths can be accessed directly. Click Rule Condition to set conditions based on the request domain, path, and headers. Domain Name: The requested host domain. Path: The requested API path. Path Match Condition: The path can be matched by using exact match, prefix match, or regular expression match. Exact Match: Enter a full path, for example, /app/v1/order. Prefix Match: Enter a path prefix ending with an asterisk (*). For example, to match all requests starting with /app, enter /app/*. Regular Expression Match: The syntax follows the Google RE2 standard. For more information, see RE2 Syntax. Case sensitive: Makes path matching case-sensitive. Header: The header of the request. Click Request Header to configure multiple headers. A logical AND operation is performed on the headers. HeaderKey: The name of the header field. Condition: The matching condition for the header. Equals To: The value of the specified header is equal to the input value. Does Not Equal To: The value of the specified header is not equal to the input value. Exists: The specified header exists in the request. Does Not Exist: The specified header does not exist in the request. Contains: The value of the specified header contains the input value. Excludes: The value of the specified header does not contain the input value. Prefix: The value of the specified header starts with the input value. Suffix: The value of the specified header ends with the input value. Regular Expression Match: The value of the specified header matches the input regular expression. The syntax follows the Google RE2 standard. For more information, see RE2 Syntax. Value: The value to match against the header field.
   Complex Conditions	Next to Authorization, click Complex Conditions. This mode allows you to define authorization rules by using a YAML configuration of Envoy's permission data structure. You can create rules with combined AND, OR, and NOT logic. The gateway sends requests that match the configured conditions for authentication. Unmatched requests can access resources directly. Note For a complete description of the permission data structure fields, see the official Envoy documentation. For configuration examples, see Complex condition authorization examples.

   Return to the Global Authentication page. If the new rule appears in the list, it was created successfully.

View and manage authentication services

1. Log on to the API Gateway console.

2. In the left-side navigation pane, click Cloud-native API Gateway > Instance. In the top navigation bar, select a region.

3. On the Instance page, click the name of the target gateway instance.

4. In the left-side navigation pane, click Security Management > Global Authentication.

5. On the Authentication page, find the target authentication rule and click Description in the Actions column. You can view the Basic Information and Authentication Configuration, and manage the Authorization Information.

   The Authentication Configuration section includes fields such as Authentication Service, Authentication API, Token Location, Timeout Period, Mode (such as Loose Mode), Allow Body in Authentication Request, Allowed Headers in Authentication Request, and Allowed Headers in Authentication Response. The Authorization Information section displays the current mode (such as Whitelist Mode). Multiple rule conditions have a logical "OR" relationship between them. The authorization rule list includes columns such as Request Domain, Request Path Matchers, case-sensitive, and Request Header Matchers.

   In the Authorization Information section, click Create Authorization. In the dialog box that appears, enter the Request Domain Name and Request Path, select a Match Mode, and then click OK to add the authorization rule.

Related operations

• Enable authentication and authorization: On the Global Authentication page, find the target rule and click Enable in the Actions column to activate it.

• Disable authentication and authorization: On the Global Authentication page, find the target rule and click Close in the Actions column to deactivate it.

• Edit authentication and authorization: On the Global Authentication page, find the target rule and click Edit in the Actions column to modify its configuration.

• Delete authentication and authorization: On the Global Authentication page, find the target rule and click Delete in the Actions column to remove it.

Complex condition authorization examples

permissions:
# and_rules: Triggers authentication if all the following rules are met.
- and_rules:
    rules:
      - url_path:
          # Path prefix matching.
          path:
            prefix: /
      - header:
          # Regular expression matching.
          safe_regex_match:
            regex: "(exampleA\\.com|exampleB\\.com)"
          # The domain name can be obtained from the ":authority" header,
          # according to the HTTP pseudo-header specification.
          name: ":authority"

permissions:
# or_rules: Triggers authentication if any of the following rules are met.
- or_rules:
    rules:
      # and_rules: This rule is met only if all the following sub-rules are met.
      # 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: Matches if the nested rule does not match.
            # 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: Matches if the nested rule does not match.
            # 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"