Microservices Engine:Configurar autenticación y autorización personalizadas

Contexto

Por lo general, los servidores protegen las API mediante la validación de credenciales, conocidas como tokens, que se envían en las solicitudes del cliente. El formato de un token no está estrictamente definido y suele depender de los requisitos específicos del negocio.

• Si el token es un JSON Web Token (JWT), su firma se puede verificar con una clave pública sin necesidad de contactar a un servicio de autenticación centralizado.

• Si el token utiliza un formato personalizado, el servidor debe llamar a un servicio de autenticación centralizado para validarlo.

El siguiente ejemplo muestra el flujo de solicitud cuando una puerta de enlace nativa de la nube se conecta a un servicio de autenticación creado por el usuario.

1. Un cliente envía una solicitud de autenticación, como un intento de inicio de sesión, a la puerta de enlace.

2. La puerta de enlace reenvía la solicitud de autenticación directamente al servicio de autenticación.

3. El servicio de autenticación valida las credenciales, como nombre de usuario y contraseña, de la solicitud. Si las credenciales son válidas, el servicio devuelve un token a la puerta de enlace, que luego lo reenvía al cliente.

4. El cliente envía una solicitud de negocio a la puerta de enlace, como realizar un pedido en /order. La solicitud incluye el token del paso anterior.

5. La puerta de enlace extrae la ruta (incluidos los parámetros de consulta), el método HTTP y el token de la solicitud de negocio original para construir una nueva solicitud de autorización, la cual envía al servicio de autenticación creado por el usuario. Debe configurar el encabezado HTTP que contiene el token en la consola MSE. También puede habilitar la opción para incluir el cuerpo de la solicitud original en la solicitud de autorización.

   Por ejemplo, si la API de autenticación de su servicio de autenticación creado por el usuario es /validateToken, la puerta de enlace combina la ruta de la API de autenticación y la ruta de la solicitud de negocio original para formar la nueva ruta de autorización: /validateToken/order.

6. Cuando el servicio de autenticación recibe la solicitud de autorización, valida el token y también puede realizar la autorización basándose en la ruta de la solicitud original.

   • Su servicio de autenticación puede usar diferentes códigos de estado HTTP para indicar el resultado de la autenticación y autorización.

     • Un código de estado HTTP 200 indica que el token es válido y está autorizado. La puerta de enlace entonces reenvía la solicitud de negocio original al servicio de backend protegido. Después de recibir la respuesta de negocio, la puerta de enlace la transmite al cliente.

     • Si el servicio de autenticación devuelve un código de estado HTTP 401 o 403, indica que el token no es válido o no está autorizado. La puerta de enlace devuelve inmediatamente la respuesta del servicio de autenticación al cliente y la solicitud original falla.

   • Si su servicio de autenticación siempre devuelve un código de estado HTTP 200, utilice el encabezado HTTP integrado x-mse-external-authz-check-result.

     • Si el valor del encabezado x-mse-external-authz-check-result en la respuesta del servicio de autenticación es true, indica que el token es válido y está autorizado. La puerta de enlace entonces reenvía la solicitud de negocio original al servicio de backend protegido y transmite la respuesta del servicio de backend al cliente.

     • Si el valor del encabezado x-mse-external-authz-check-result es false, indica que el token no es válido o no está autorizado. La puerta de enlace devuelve inmediatamente la respuesta del servicio de autenticación al cliente y la solicitud original falla.

Crear una regla de autenticación personalizada

1. Inicie sesión en la consola MSE.

2. En el panel de navegación izquierdo, seleccione Cloud-native Gateway > Gateways. En la barra de navegación superior, seleccione una región.

3. En la página Gateways, haga clic en el nombre de la puerta de enlace destino.

4. En el panel de navegación izquierdo, seleccione Security Management > Global Authentication.

5. En la página global authentication, haga clic en create authentication. En el panel Create authentication, configure los parámetros de autenticación de la puerta de enlace y luego haga clic en OK.

   Parámetro	Descripción
   Authentication name	Introduzca un nombre personalizado para la regla de autenticación.
   Authentication type	Seleccione user-created authentication.
   Authentication service	Seleccione el servicio de backend para la autenticación. Puede agregar servicios en la sección de gestión de servicios. Para más información, consulte Add a service. Nota Solo se admiten servicios que utilizan el protocolo HTTP. Otros protocolos como Dubbo no son compatibles. De forma predeterminada, la puerta de enlace utiliza el primer puerto de un servicio de Kubernetes. Para usar un puerto diferente, cree otro servicio de Kubernetes en Container Service for Kubernetes (ACK) que exponga únicamente el puerto deseado.
   Authentication API	Especifique la ruta de la API del servicio de autenticación. La ruta de la API debe ser compatible con la coincidencia de prefijos. Por ejemplo, si su servicio de autenticación está construido sobre Spring MVC y la API de autenticación es /check, configúrelo para manejar solicitudes de /check/ y sus subrutas: @RequestMapping("/check/") public ResponseEntity<RestResult<String>> check(){}
   Token location	Especifique el encabezado de solicitud que contiene el token. Los encabezados comunes incluyen Authorization y Cookie. Puede seleccionar un encabezado de la lista desplegable o usar la entrada manual para especificar el nombre del encabezado.
   Allowed headers in authentication request	Especifique los nombres de cualquier encabezado de solicitud del cliente que deba pasarse al servicio de autenticación. Nota Los encabezados Host, Method, Path y Content-Length se incluyen de forma predeterminada y no necesitan agregarse manualmente.
   Allowed headers from authentication response	Especifique los nombres de cualquier encabezado de respuesta de autenticación que deba agregarse a la solicitud original antes de enviarse al servicio de backend. Nota Si la solicitud del cliente ya contiene un encabezado con el mismo nombre, su valor se sobrescribe.
   Allow body in authentication request	Seleccione esta opción para incluir el cuerpo de la solicitud original en la solicitud de autenticación. Maximum body bytes especifica el tamaño máximo del cuerpo de la solicitud, en bytes, que se puede enviar en la solicitud de autenticación.
   Timeout	El tiempo máximo, en segundos, para esperar una respuesta del servicio de autenticación. Valor predeterminado: 10.
   Mode	Especifica el modo de manejo de fallos. Se admiten loose mode y strict mode. Se recomienda utilizar loose mode. loose mode: La puerta de enlace permite las solicitudes del cliente si el servicio de autenticación no está disponible (falla la conexión o devuelve un error 5xx). strict mode: La puerta de enlace rechaza las solicitudes del cliente si el servicio de autenticación no está disponible.
   Simple rule	A la derecha de Grant, haga clic en simple rule. Este modo admite whitelist mode y blacklist mode. whitelist mode: Las solicitudes que coinciden con los hosts y rutas especificados omiten la autenticación. Todas las demás solicitudes la requieren. blacklist mode: Solo las solicitudes que coinciden con los hosts y rutas especificados requieren autenticación. Todas las demás solicitudes la omiten. Haga clic en + Rule condition para establecer el nombre de dominio de la solicitud, la ruta y el encabezado de la solicitud. Domain name: El nombre de dominio solicitado (host). Path: La ruta de la API solicitada. Path match condition: La ruta admite coincidencia exacta, coincidencia de prefijo y coincidencia de expresión regular. Exact match: Introduzca la ruta completa, por ejemplo, /app/v1/order. Prefix match: Introduzca un prefijo de ruta que termine con un asterisco (). Por ejemplo, para coincidir con todas las solicitudes que comienzan con /app, establezca el valor en /app/. Regular expression match: La expresión regular debe seguir la sintaxis RE2. Para más información, consulte Sintaxis RE2. Case sensitive: Si se selecciona esta opción, la coincidencia de ruta distingue entre mayúsculas y minúsculas. Request header: La información de encabezado de la solicitud. Los encabezados se combinan con un AND lógico. Haga clic en + Request Header para configurar múltiples encabezados. Header key: El nombre del campo de encabezado. Condition: Las condiciones de coincidencia admitidas para los encabezados. Equal To: El valor de la clave de encabezado especificada en la solicitud es igual al valor introducido. Not Equal To: El valor de la clave de encabezado especificada no es igual al valor introducido. Exists: La solicitud contiene la clave de encabezado especificada. Does Not Exist: La solicitud no contiene la clave de encabezado especificada. Contains: El valor de la clave de encabezado especificada contiene el valor introducido. Does Not Contain: El valor de la clave de encabezado especificada no contiene el valor introducido. Prefix: El valor de la clave de encabezado especificada comienza con el valor introducido. Suffix: El valor de la clave de encabezado especificada termina con el valor introducido. Regex: El valor de la clave de encabezado especificada coincide con la expresión regular introducida. La expresión regular debe seguir la sintaxis RE2. Para más información, consulte Sintaxis RE2. Value: El valor del campo de encabezado.
   Complex rule	A la derecha de Grant, haga clic en complex rule. Este modo le permite configurar reglas de autorización con lógica combinada AND/OR/NOT, utilizando la permission data structure de Envoy en YAML. La autenticación se requiere solo para las solicitudes que coinciden con estas condiciones; todas las demás solicitudes omiten la autenticación. Nota Para una descripción completa de los campos en la estructura de datos de permisos, consulte la documentación oficial de Envoy. Para ejemplos de configuración, consulte Complex rule examples.

   Regresará a la página global authentication. Si la nueva regla de autenticación de la puerta de enlace aparece en la lista, significa que la regla se ha creado correctamente.

Consultar y gestionar reglas de autenticación

1. Inicie sesión en la consola MSE.

2. En el panel de navegación izquierdo, seleccione Cloud-native Gateway > Gateways. En la barra de navegación superior, seleccione una región.

3. En la página Gateways, haga clic en el nombre de la puerta de enlace destino.

4. En el panel de navegación izquierdo, seleccione Security Management > Global Authentication.

5. En la página global authentication, busque la regla de autenticación objetivo y haga clic en Details en la columna Actions. Puede consultar la Basic Information y la Authentication Configuration del servicio actual, así como ver y gestionar su Authorization Information.

   La sección Authentication configuration muestra campos como authentication service, authentication API, token location, timeout, mode, allow body in authentication request, allowed headers in authentication request y allowed headers from authentication response. La sección Authorization information está en modo de lista de permitidos. Las condiciones de la regla se combinan con un OR lógico, mientras que los elementos coincidentes dentro de una regla se combinan con un AND lógico. La tabla de reglas de autorización incluye las columnas Request domain name, Request path match items, Case sensitive, Request header match items y Actions.

   En la sección Authorization Information, haga clic en Create authorization info. En el cuadro de diálogo que aparece, introduzca un Request domain name y una Request path, seleccione un Match mode y luego haga clic en OK para agregar la regla de autorización.

Operaciones relacionadas

También puede realizar las siguientes operaciones para gestionar reglas de autenticación y autorización:

• Habilitar una regla: En la página Global Authentication, busque la regla objetivo y haga clic en Enable en la columna Actions para activarla.

• Deshabilitar una regla: En la página Global Authentication, busque la regla objetivo y haga clic en Close en la columna Actions para desactivarla.

• Editar una regla: En la página Global Authentication, busque la regla objetivo y haga clic en Edit en la columna Actions para modificar su configuración.

• Eliminar una regla: En la página Global Authentication, busque la regla objetivo y haga clic en Delete en la columna Actions para quitarla.

Ejemplos de reglas complejas

permissions:
# and_rules specifies that authentication is performed when all the following rules are met.
- and_rules:
    rules:
      - url_path:
          # Prefix match for the path.
          path:
            prefix: /
      - header:
          # Regular expression match.
          safe_regex_match:
            regex: "(exampleA\\.com|exampleB\\.com)"
          # HTTP pseudo-header is supported. You can use the ":authority" header to obtain the domain name.
          name: ":authority"

permissions:
# or_rules specifies that authentication is performed if any of the following rules are met.
- or_rules:
    rules:
      # and_rules specifies that this rule is met only when 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 specifies that this rule is met 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 specifies that this rule is met 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"