Autenticación de API con el dispositivo NetScaler
Hay un cambio de paradigma en la forma en que las aplicaciones modernas interactúan con sus clientes. Tradicionalmente, los clientes del navegador se utilizaban para acceder a los servicios. Las aplicaciones configuran cookies de sesión para rastrear el contexto del usuario. Las aplicaciones modernas y distribuidas dificultan el mantenimiento de las sesiones de usuario en los microservicios. Debido a esto, la mayoría de los accesos a las aplicaciones se han basado en la API. Los clientes que se comunican con estos servicios distribuidos también han evolucionado. La mayoría de los clientes obtienen los tokens de una entidad de confianza llamada Servidor de Autorización para demostrar la identidad y el acceso del usuario. Estos clientes luego presentan el token a la aplicación con cada solicitud de acceso. Por lo tanto, los dispositivos proxy tradicionales, como NetScaler, deben evolucionar para dar soporte a estos clientes. Un dispositivo NetScaler proporciona una forma para que los administradores gestionen dicho tráfico. NetScaler se puede implementar como una puerta de enlace de API para gestionar todo el tráfico destinado a los servicios publicados. Se puede implementar una pasarela de API para entornos tradicionales (multinube híbrida o HMC) o nativos de la nube. La API de Gateway finaliza todo el tráfico entrante para ofrecer varios servicios como autenticación, autorización, limitación de velocidad, redirección, almacenamiento en caché, descarga SSL, firewall de aplicaciones, etc. Por lo tanto, se convierte en un componente crítico de la infraestructura.
Tipos de tokens
Los tokens intercambiados durante el acceso a la API se ajustan principalmente al protocolo OAuth/OpenID Connect (OIDC). Los tokens de acceso que se usan solo para el “acceso delegado” se ajustan al protocolo OAuth, mientras que los identificadores de identificación que cumplen con la OIDC también contienen información del usuario. Los tokens de acceso suelen ser una masa de datos opaca o aleatoria. Sin embargo, a veces pueden ser tokens chamuscados que cumplen con los estándares JWT (JSON Web Token). Los identificadores de identidad siempre están firmados como JWT.
Acceso a la API con OAuth
El tipo de autenticación OAuth en un dispositivo NetScaler se puede utilizar para gestionar los protocolos OAuth y OIDC. OIDC es una extensión del protocolo OAuth.
OAuthAction en un dispositivo NetScaler se puede utilizar para gestionar clientes interactivos, como los navegadores, y clientes nativos, como las aplicaciones cliente. Los clientes interactivos se redirigen al proveedor de identidad para iniciar sesión mediante el protocolo OIDC. Los clientes nativos pueden obtener los tokens fuera de banda y pueden presentarlos en un dispositivo NetScaler para acceder a ellos.
Nota:
El token de acceso obtenido de los endpoints se puede almacenar en caché para solicitudes posteriores, lo que mejora el rendimiento de la API.
Para configurar la compatibilidad con el almacenamiento en caché de tokens mediante la interfaz de línea de comandos, escriba el siguiente comando en la línea de comandos:
set aaaparameter -APITokenCache <ENABLED>
<!--NeedCopy-->
En las siguientes secciones se describe el método de acceso a la API que utilizan los clientes nativos.
Servidor virtual para acceso a la API
Para implementar un dispositivo NetScaler para un acceso a la API, se implementa un servidor virtual de administración del tráfico (TM) con autenticación 401. Está asociado a un servidor virtual de autenticación (autenticación, autorización y auditoría) que contiene las directivas de autenticación y sesión. El siguiente fragmento de configuración crea uno de esos servidores virtuales.
Add lb vserver lb-api-access SSL <IP> 443 -authn401 On -AuthnVsName auth-api-access
Bind ssl vserver lb-api-access -certkeyName <ssl-cert-entity>
Add authentication vserver auth-api-access SSL
<!--NeedCopy-->
Nota:
Deberá vincular un servicio al servidor virtual de administración del tráfico y una directiva de autenticación (con OAuthAction que se describe a continuación) al servidor virtual de autenticación para completar la configuración.
Después de crear el servidor virtual, es necesario agregar una OAuthAction junto con la directiva correspondiente. Hay varias otras opciones dentro de una acción de OAuth, según el tipo de token y otros mecanismos de seguridad.
Configuración de OAuth para identificadores de identificación
Los identificadores de identidad siempre están firmados como JWT. Es decir, llevan el encabezado, la carga útil y la firma. Como se trata de tokens autónomos, un dispositivo NetScaler puede validarlos localmente. Para validar estos tokens, el dispositivo necesitaría conocer la clave pública de la clave privada correspondiente utilizada para firmarlos.
A continuación se muestra un ejemplo de OAuthAction con ciertos argumentos obligatorios junto con “certEndpoint”.
Add authentication OAuthAction oauth-api-access -clientid <your-client-id> -clientsecret <your-client-secret> -authorizationEndpoint <URL to which users would be redirected for login> -tokenEndpoint <endpoint at which tokens could be obtained> -certEndpoint <URL at which public keys of IdP are published>
<!--NeedCopy-->
Donde:
-
Client ID: Cadena única que identifica al proveedor de servicios. El servidor de autorización infiere la configuración del cliente mediante este ID. Longitud máxima: 127.
-
Client Secret: Cadena secreta establecida por el usuario y el servidor de autorización. Longitud máxima: 239.
-
authorizationEndpoint: URL en la que los usuarios normalmente iniciarían sesión (cuando se utilizan clientes interactivos).
-
tokenEndpoint: URL del servidor de autorización en el que se obtienen o intercambian los tokens o el código
-
certEndpoint: URL en la que el servidor de autorización publica las claves públicas utilizadas para firmar los tokens. El servidor de autorización puede publicar más de una clave y elegir una de ellas para firmar los tokens.
Nota:
El ID del cliente/el secreto del cliente/authorizationEndpoint/TokenEndpoint son parámetros opcionales para el acceso a la API. Sin embargo, es una buena práctica proporcionar valores para estos parámetros, ya que la entidad de acción se puede reutilizar para diferentes propósitos.
En la configuración anterior, “certEndpointpoint” es esencial para la validación del ID Token. Este punto final contiene las claves públicas del certificado utilizado para firmar los tokens. Estas claves públicas deben corresponder a la especificación JWK (claves web JSON).
Una vez configurado el certEndpoint en el dispositivo NetScaler, sondea el punto final periódicamente (con un intervalo predeterminado de 1 día que se puede personalizar en la configuración) para mantener las claves públicas actualizadas. Una vez que las claves públicas estén disponibles, ADC puede realizar la validación local de los identificadores de identificación entrantes.
Configuración de OAuth para tokens de acceso opacos
Los tokens opacos no se pueden verificar localmente en el dispositivo NetScaler. Deben validarse en el servidor de autorización. Un dispositivo NetScaler utiliza el “protocolo de introspección” mencionado en las especificaciones de OAuth para verificar estos tokens. Se incluye una nueva opción, introspectURL, en la configuración de OAuth para verificar los tokens opacos.
set oauthAction oauth-api-acccess -introspectURL <URL of the Authorization Server for introspection>
<!--NeedCopy-->
El formato de la API de introspección se ajusta a la especificación de https://tools.ietf.org/html/rfc7662#section-2.1 de esta manera:
POST /introspect HTTP/1.1
Host: server.example.com
Accept: application/json
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
token=mF_9.B5f-4.1JqM&token_type_hint=access_token
<!--NeedCopy-->
Directiva de enlace al servidor virtual de autenticación
Una vez creada OAuthAction, es necesario crear la directiva correspondiente para invocarla.
add authentication policy oauth-api-access -rule <> -action <oauth-api-access>
bind authentication vserver auth-api-access -policy oauth-api-access -pri 100
<!--NeedCopy-->
Configuración de seguridad adicional en un dispositivo NetScaler
La validación del token incluye comprobaciones de la vida útil del token. Las fichas fuera del plazo aceptable se rechazan. A continuación se muestran las configuraciones adicionales para mayor seguridad. Se recomienda configurar algunos de ellos siempre.
Público: La acción de OAuth se puede configurar con el destinatario previsto del token. Todos los tokens coinciden con esta URL configurada. Un dispositivo NetScaler tiene una función adicional en la que el campo de audiencia realmente apunta a un patrón establecido en el dispositivo. Con este conjunto de patrones, un administrador puede configurar más de una URL para la audiencia.
add policy patset oauth_audiences
bind patset oauth_audiences https://app1.company.com
bind patset oauth_audiences https://app2.company.com
bind patset oauth_audiences httpsL//app1.company.com/path1
set oAuthAction oauth-api-access -audience oauth_audiences
<!--NeedCopy-->
En el ejemplo anterior, se especifica más de una audiencia en un conjunto de patrones. Por lo tanto, solo se permite un token entrante si contiene alguna de las URL configuradas en el conjunto de patrones.
Emisor: identidad del servidor cuyos tokens se van a aceptar. Longitud máxima: 127. Se recomienda configurar el emisor de los tokens en OAuth Action. Esto garantiza que no se permitan los tokens emitidos por un servidor de autorización incorrecto.
SkewTime: especifica el sesgo de reloj permitido en número de minutos que un dispositivo NetScaler permite en un token entrante. Por ejemplo, si skewTime es 10, el token sería válido desde (tiempo actual - 10) min a (tiempo actual+ 10) min, es decir, 20 min en total. Valor predeterminado: 5
AllowedAlgorithms: esta opción permite al administrador restringir ciertos algoritmos en los tokens entrantes. De forma predeterminada, todos los métodos admitidos están permitidos. Sin embargo, se pueden controlar mediante esta opción.
La siguiente configuración garantiza que solo se permitan los tokens que utilizan RS256 y RS512:
set oAuthAction oauth-api-access -allowedAlgorithms RS256 RS512
<!--NeedCopy-->
Una vez realizada la configuración anterior, solo se permiten los tokens que usen RS256 y RS512.
Omitir cierto tráfico de la autenticación
En muchos casos, hay algunas API de descubrimiento a las que los clientes pueden acceder públicamente. Estas API suelen revelar la configuración y las capacidades del propio servicio. Un administrador puede configurar el dispositivo NetScaler para omitir la autenticación de estas URL de metadatos mediante la directiva de “no autenticación” que se describe a continuación:
add authentication policy auth-bypass-policy -rule <> -action NO_AUTHN
bind authentication vserver auth-api-access -policy auth-bypass-policy -pri 110
<!--NeedCopy-->
NO_AUTHN es una acción implícita que hace que la autenticación se complete cuando la regla coincida. Hay otros usos de la acción NO_AUTHN más allá del alcance del acceso a la API.
En este artículo
- Tipos de tokens
- Acceso a la API con OAuth
- Servidor virtual para acceso a la API
- Configuración de OAuth para identificadores de identificación
- Configuración de OAuth para tokens de acceso opacos
- Directiva de enlace al servidor virtual de autenticación
- Configuración de seguridad adicional en un dispositivo NetScaler
- Omitir cierto tráfico de la autenticación