API Gateway:Configure self-managed authentication

Create self-hosted authentication

1. Log on to the AI Gateway console.

2. In the navigation pane on the left, choose Instance. In the top menu bar, select a region.

3. On the Instance page, click the target instance ID.

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

5. On the Global Authentication page, click Create Authentication, and configure the gateway authentication parameters. Click OK.

   Parameter	Description
   Enable	Specifies whether to enable AI Gateway authentication.
   Authentication Name	Set the custom name of the AI Gateway authentication.
   Authentication Type	Select Self-managed Authentication Service.
   Authentication Service	The backend service used to verify tokens and permissions. You can add it in service management. For more information, see Add a service. Note Only HTTP protocol services are supported. 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, please create another Kubernetes service in a Container Service for Kubernetes (ACK) cluster and use the target port only.
   Authentication API	Set API Path from authentication, within prefix match mode. For example, if your authentication service is built based on SpringMVC and the exposed authentication API is /check, the configuration for handling requests to /check/** is: @RequestMapping("/check/**") public ResponseEntity<RestResult<String>> check(){}
   Token Position	Set the header position of the Token in the request message. Common positions include Authorization and Cookie. You can select or Input to set the token position.
   Headers Allowed In Authentication Request	If you want the authentication request to contain other headers in addition to the Host, Method, Path, and Content-Length headers, you must configure the headers that you want to add. Note By default, the Host, Method, Path, and Content-Length headers are contained in an authentication request.
   Headers Allowed In Authentication Response	Configure the headers if you need to add headers in the authentication response to the business request from a client. Note If the headers you configure already exist in the request, the values will be overwritten.
   Body Allowed In Authentication Request	If you select Allow Body In Authentication Request, the authentication request will include the body of the original request. Maximum Body Size indicates the maximum size of the body that can be carried in the request. Unit: bytes.
   Timeout	Set the maximum waiting time for the authentication service to return results. Unit: seconds. Default value: 10 seconds.
   Mode	Supports Loose Mode and Strict Mode. We recommend you to select Loose Mode. Loose Mode: When the authentication service is unavailable (connection to the authentication service fails or the service returns a 5xx response), the gateway accepts the client request. Strict Mode: When the authentication service is unavailable (connection to the authentication service fails or the service returns a 5xx response), the gateway rejects the client request.
   Simple Condition	Click Simple Condition on the right of Authorization. Simple condition authorization mode supports Whitelist Mode and Blacklist Mode. Whitelist Mode: Hosts and Paths in the whitelist require verification. All other Hosts and Paths require verification. Blacklist Mode: Hosts and Paths in the blacklist require verification. All other Hosts and Paths can be accessed directly. Click + Rule Condition to set the request domain name, path, and request header. Domain Name: The domain name accessed by the request, which is Hosts. Path: The interface path accessed by the request, which is Paths. Path Match Condition: Path supports exact match, prefix match, and regular expression match. Exact Match: Enter the complete path, such as /app/v1/order. Prefix Match: Enter the prefix of the path and add an asterisk (*) at the end. For example, for all requests that start with /app, you must specify /app/*. Match Regular Expression: The syntax of regular expression matching follows the Google Re2 specification. For more information, see Re2 Syntax. Case Sensitive: If selected, the path match value will be case-sensitive. Request Header: The header information of the request. Click + Request Header to configure. Supports multiple headers. The relationship between headers is AND. HeaderKey: The name of the header field. Condition: The matching conditions supported by the header. Equal: The value of the specified key in the request header collection equals the input value. Not Equal: The value of the specified key in the request header collection does not equal the input value. Exists: The input key exists in the request header collection. Not Exists: The input key does not exist in the request header collection. Contains: The value of the specified key in the request header collection contains the input value. Not Contains: The value of the specified key in the request header collection does not contain the input value. Prefix: The value of the specified key in the request header collection has the input value as a prefix. Suffix: The value of the specified key in the request header collection has the input value as a suffix. Regular Expression: The value of the specified key in the request header collection matches the input regular expression. The syntax of regular expression matching follows the Google Re2 specification. For more information, see Re2 Syntax. Value: The value of the header field.
   Complex Condition	Click Complex Condition on the right of Authorization. Complex condition authorization supports configuring authorization rules based on AND/OR/NOT combined conditional logic, by configuring Envoy's permission data structure through YAML. Authentication logic will be executed when the conditions are met. Requests that do not meet the conditions can be accessed without authentication. Note For a complete description of the permission data structure fields, see Envoy Official Documentation. For configuration examples, see Complex condition authorization examples.

   Return to the Global Authentication page to view the authentication information. If you can see the created gateway authentication information, the gateway self-hosted authentication creation is successful.

View and manage authentication services

1. Log on to the AI Gateway console.

2. In the navigation pane on the left, choose Instance. In the top menu bar, select a region.

3. On the Instance page, click the target instance ID.

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

5. On the Authentication page, click the name of the target authentication rule to view the Basic Information and Authentication Configuration of the current service. You can also view and manage Authorization Information.

   

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

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 condition authorization

permissions:
# and_rules indicates that authentication is executed when all rules below are met
- and_rules:
    rules:
      - url_path:
          # prefix match path
          path:
            prefix: /
      - header:
          # regular expression match
          safe_regex_match:
            regex: "(exampleA\\.com|exampleB\\.com)"
          # supports HTTP Pseudo-Header specification, domain name can be obtained through the ":authority" header
          name: ":authority"

AND/OR/NOT combination example

This example meets the following conditions:

1. Requests starting with exampleA.com/api prefix need authentication, but:

   1. exampleA.com/api/appa/bbb does not need authentication.

   2. exampleA.com/api/appb/ccc does not need authentication.

2. All requests under exampleB.com need authentication, but:

   1. exampleB.com/api/appa/bbb does not need authentication.

   2. exampleB.com/api/appb/ccc does not need authentication.

   3. Requests starting with exampleB.com/api/appc prefix do not need authentication, except:

      1. exampleB.com/api/appc/bbb/ccc needs authentication.

      2. exampleB.com/api/appc/ccc/ddd needs authentication.

The logic is organized as:

The corresponding YAML configuration is as follows:

permissions:
# or_rules indicates that authentication is executed when any of the rules below is met
- or_rules:
    rules:
      # and_rules indicates that this rule condition is met only when all rules below are met simultaneously
      # Rule One
      - and_rules:
          rules:
            - url_path:
                path:
                  exact: /api/appc/bbb/ccc
            - header:
                exact_match: "exampleB.com"
                name: ":authority"
      # Rule Two                
      - and_rules:
          rules:
            - url_path:
                path:
                  exact: /api/appc/ccc/ddd
            - header:
                exact_match: "exampleB.com"
                name: ":authority"
      - and_rules:
          rules:
            # Rule Three
            - url_path:
                path:
                  prefix: /api/
            # not_rule indicates that this rule condition is met only when the configuration below is not met
            # Rule Four
            - not_rule:
                url_path:
                  path:
                    exact: /api/appa/bbb
            # Rule Five
            - not_rule:
                url_path:
                  path:
                    exact: /api/appb/ccc                                
            - header:
                exact_match: "exampleA.com"
                name: ":authority"                                
      - and_rules:
          rules:
            # Rule Six
            - url_path:
                path:
                  prefix: /
            # not_rule indicates that this rule condition is met only when the configuration below is not met
            # Rule Seven
            - not_rule:
                url_path:
                  path:
                    exact: /api/appa/bbb
            # Rule Eight
            - not_rule:
                url_path:
                  path:
                    exact: /api/appb/ccc
            # Rule Nine
            - not_rule:
                url_path:
                  path:
                    prefix: /api/appc/                                         
            - header:
                exact_match: "exampleB.com"
                name: ":authority"