Conceptos, entidades y terminología de nFactor
Este tema captura algunas de las principales entidades involucradas en la autenticación de nFactor y su importancia.
Esquema de inicio de sesión
nFactor desacopla la “vista”, la interfaz de usuario, con el “modelo” que es el manejo en tiempo de ejecución. La vista de nFactor está definida por el esquema de inicio de sesión. El esquema de inicio de sesión es una entidad que define lo que ve el usuario y especifica cómo extraer los datos del usuario.
Para definir una vista, el esquema de inicio de sesión apunta a un archivo en el disco que define el formulario de inicio de sesión. Este archivo debe cumplir con la especificación del “Protocolo de formularios comunes de Citrix”. Este archivo es esencialmente una definición XML del formulario de inicio de sesión.
Además del archivo XML, el esquema de inicio de sesión contiene expresiones de directiva avanzadas para obtener el nombre de usuario y la contraseña de la solicitud de inicio de sesión del usuario. Estas expresiones son opcionales y se pueden omitir si el nombre de usuario y la contraseña del usuario llegan con los nombres de variables de formulario esperados.
El esquema de inicio de sesión también define si el conjunto actual de credenciales se debe usar como credenciales SingleSignOn predeterminadas.
El esquema de inicio de sesión se puede crear ejecutando el siguiente comando de la CLI:
add authentication loginSchema <name> -authenticationSchema <string> [-userExpression <string>] [-passwdExpression <string>] [-userCredentialIndex <positive_integer>] [-passwordCredentialIndex <positive_integer>] [-authenticationStrength <positive_integer>] [-SSOCredentials ( YES | NO )]
<!--NeedCopy-->
Nota:
Las credenciales SSOCredentials indican si las credenciales de los factores actuales son las credenciales SSO predeterminadas. El valor por defecto es NO.
En la configuración de autenticación nFactor, las credenciales del último factor se utilizan para el SSO de forma predeterminada. Al usar la configuración de SsoCredentials, se pueden usar las credenciales de factor actuales. En caso de que esta configuración se establezca en diferentes factores, el factor final que tiene esta configuración establecida toma la prioridad.
Para obtener más información sobre cada parámetro, consulte https://developer-docs.citrix.com/projects/citrix-adc-command-reference/en/13/authentication/authentication-loginSchema/#add-authentication-loginS.
Etiqueta de directiva
Una etiqueta de directiva es un conjunto de directivas. Es una construcción que no es ajena a la infraestructura de directivas de Citrix ADC. Etiqueta de directiva define un factor de autenticación. Es decir, contiene todas las directivas necesarias para determinar si se cumplen las credenciales del usuario. Todas las directivas de una etiqueta de directiva pueden considerarse homogéneas. La etiqueta de directiva para la autenticación no puede tomar directivas de tipo diferente, por ejemplo, reescribir. En otras palabras, todas las directivas de una etiqueta de directiva validan la misma contraseña/credencial del usuario, en su mayoría. El resultado de las directivas en una policyLabel sigue la condición lógica OR. Por lo tanto, si la autenticación especificada por la primera directiva tiene éxito, se omiten las demás directivas que la siguen.
La etiqueta de directiva se puede crear ejecutando el siguiente comando de la CLI:
add authentication policy label mylabel –loginSchema <>
<!--NeedCopy-->
Una etiqueta de directiva toma el esquema de inicio de sesión como propiedad. El esquema de inicio de sesión define la vista de esa etiqueta de directiva. Si no se especifica el esquema de inicio de sesión, se asocia un esquema de inicio de sesión implícito, LSCHEMA_INT, a esa etiqueta de directiva. El esquema de inicio de sesión decide si una etiqueta de directiva se convierte en un acceso directo o no.
Etiqueta de servidor virtual
En la infraestructura de directivas avanzada de Citrix ADC, un servidor virtual también es una etiqueta de directiva implícita. Esto se debe a que el servidor virtual también se puede vincular a más de una directiva. Sin embargo, un servidor virtual es especial porque es el punto de entrada para el tráfico del cliente y puede tomar directivas de un tipo diferente. Cada una de las directivas que pone bajo su propia etiqueta dentro del servidor virtual. Por lo tanto, el servidor virtual es un conglomerado de etiquetas.
Siguiente factor
Siempre que una directiva esté vinculada a un servidor virtual o a una etiqueta de directiva, se puede especificar con el siguiente factor. El siguiente factor determina lo que se debe hacer si una autenticación determinada tiene éxito. Si no hay un factor siguiente, se concluye el proceso de autenticación para ese usuario.
Cada directiva enlazada a un servidor virtual o etiqueta de directiva puede tener un factor siguiente diferente. Esto permite la máxima flexibilidad en la que el éxito de cada directiva puede definir una nueva ruta para la autenticación del usuario. El administrador puede aprovechar este hecho y crear factores de reserva inteligentes para los usuarios que no cumplen ciertas directivas.
Directiva de exclusión de autenticación
nFactor introduce una directiva integrada especial llamada NO_AUTHN. La directiva NO_AUTHN siempre devuelve el éxito como resultado de la autenticación. No-auth se puede crear ejecutando el siguiente comando de la CLI:
add authentication policy noauthpolicy –rule <> -action NO_AUTHN
<!--NeedCopy-->
Según el comando, la directiva no-authentication toma una regla que puede ser cualquier expresión de directiva avanzada. El resultado de la autenticación siempre es correcto desde NO_AUTHN.
Una directiva no-auth en sí misma no parece agregar valor. Sin embargo, cuando se utiliza junto con etiquetas de directivas de paso a través, ofrece una gran flexibilidad para tomar decisiones lógicas para impulsar el flujo de autenticación de usuarios. La directiva NO_AUTHN y los factores de paso ofrecen una nueva dimensión a la flexibilidad de nFactor.
Nota: Consulte los ejemplos que describen el uso de no-auth y el acceso directo en las secciones posteriores.
Factor/etiqueta de paso
Una vez que el usuario ha pasado la autenticación en el servidor virtual (para el primer factor), las autenticaciones posteriores se producen en las etiquetas de directiva o en los factores definidos por el usuario (secundarios). Cada etiqueta/factor de directiva se asocia a una entidad de esquema de inicio de sesión para mostrar la vista de ese factor. Esto permite personalizar las vistas en función de la ruta que el usuario habría tomado para llegar a un factor determinado.
Existen tipos especializados de etiquetas de directiva que no apuntan explícitamente a un esquema de inicio de sesión. Las etiquetas de directivas especializadas apuntan a un esquema de inicio de sesión que en realidad no apunta al archivo XML de la vista. Estas etiquetas/factores de directivas se denominan factores de “transferencia”.
Los factores de acceso directo se pueden crear ejecutando los siguientes comandos de la CLI:
Ejemplo 1:
add authentication policylabel example1
<!--NeedCopy-->
Ejemplo 2:
add loginschema passthrough_schema –authenticationSchema noschema
add authentication policylabel example2 –loginschema passthrough_schema
<!--NeedCopy-->
El factor de acceso directo implica que el subsistema de autenticación, autorización y auditoría no debe volver al usuario para obtener la credencial establecida para ese factor. En su lugar, es una sugerencia para que la autenticación, la autorización y la auditoría continúen con las credenciales ya obtenidas. Esto es útil en casos en los que no se quiere la intervención del usuario. Por ejemplo:
-
Cuando al usuario se le presentan dos campos de contraseña, después del primer factor, el segundo factor no necesita la intervención del usuario.
-
Cuando se realiza la autenticación de un tipo (por ejemplo, certificado) y el administrador debe extraer grupos para ese usuario.
El factor de paso se puede usar con la directiva NO_AUTH para realizar saltos condicionales.
Flujo de autenticación nFactor
La autenticación siempre comienza en el servidor virtual de nFactor. El servidor virtual define el primer factor para el usuario. El servidor virtual sirve el primer formulario que ve el usuario. El formulario de inicio de sesión que ve el usuario se puede personalizar en el servidor virtual mediante directivas de esquema de inicio de sesión. Si no hay directivas de esquema de inicio de sesión, se muestra al usuario un solo campo de nombre de usuario y contraseña.
Si se debe mostrar al usuario más de un campo de contraseña en un formulario personalizado, se deben usar directivas de esquema de inicio de sesión. Permiten mostrar diferentes formularios basados en las reglas configuradas (como usuario de intranet frente al usuario externo, proveedor de servicios A frente al proveedor de servicios B).
Una vez que se publican las credenciales de usuario, la autenticación comienza en el servidor virtual de autenticación, el primer factor. Como el servidor virtual de autenticación se puede configurar con varias directivas, cada una de ellas se evalúa en una secuencia. En cualquier momento dado, si una directiva de autenticación tiene éxito, se toma el siguiente factor especificado contra ella. Si no hay otro factor, el proceso de autenticación finaliza. Si existe el siguiente factor, se comprueba si ese factor es un factor de paso o un factor regular. Si se trata de transferencia, las directivas de autenticación de ese factor se evalúan sin intervención del usuario. De lo contrario, el esquema de inicio de sesión asociado a ese factor se muestra al usuario.
Ejemplo de uso de directivas de factor de paso y sin autenticación para tomar decisiones lógicas
El administrador quiere decidir nextFactor en función de los grupos.
add authentication policylabel group check
add authentication policy admin group –rule http.req.user.is_member_of("Administrators") –action NO_AUTHN
add authentication policy nonadmins –rule true –action NO_AUTHN
bind authentication policy label group check –policy admingroup –pri 1 –nextFactor factor-for-admin
bind authentication policy label groupcheck –policy nonadmins –pri 10 –nextfactor factor-for-others
add authentication policy first_factor_policy –rule <> -action <>
bind authentication vserver <> -policy first_factor_policy –priority 10 –nextFactor groupcheck
<!--NeedCopy-->