Implementar Latch Cloud TOTP en un APM de F5

Cada vez que nos reunimos con nuestros Partners de Alianzas Estratégicas, es una excusa para compartir experiencias, tecnologías y aprender. Ver cómo, entre ambos, podemos seguir mejorando la seguridad de nuestros clientes. En días pasados, Andrew Oteiza me estuvo comentando sobre las bondades de F5 APM, y comenzamos a hablar sobre la posibilidad de utilizar nuestro Latch Cloud TOTP para poder loguearte al portal sin problemas. Debido a esta accesibilidad, decidimos escribir este post dedicado a aquellos que gestionen F5 APM basándonos en el artículo publicado sobre cómo usar 2FA en el APM.

La implementación de Latch Cloud TOTP se relaciona directamente con la posibilidad de ejecutar un iRule en el F5 para poder generar los códigos QR, por lo cual, lo primero que se debe hacer es crear un Virtual Server con el iRule que ejecuta esa acción (generate_ga_code), asignarle una IP y un puerto de conexión, el perfil del usuario y en los recursos asignar el iRule.

Imagen 1: Virtual Server creado, con una IP, un puerto y un perfil asignado

Hasta aquí tenemos la generación del código QR y la lectura con nuestro móvil. Sin embargo, debemos modificar la política implementada en el F5 para que nos permita manejar el token generado por Latch Cloud TOTP. Para llevar a cabo esta acción, debemos de generar otro iRule al que llamaremos ga_code_verify y lo asignaremos al Virtual Server que actualmente tiene la política de APM (sería uno distinto al utilizado anteriormente para generar el código QR, en el siguiente vídeo de ejemplo (Vídeo 2), tiene la IP 10.1.10.47). Este iRule tomará como variable el token introducido, y verificará que que el secret key, resguardado en el Data Group List, sea el correcto.

Después de haber creado la web de login, el siguiente paso es generar un Custom iRule Event Agent. Referenciaremos al iRule ya creado previamente (ga_code_verify) y le asignaremos distintas salidas según el resultado obtenido al ingresar el usuario el token:

Imagen 3: salidas dependiendo del resultado obtenido al verificar el token.

Name: Successful
Expression: expr { [mcget {session.custom.ga_result}] == 0 } change

Name: No Google Auth Key Found
Expression: expr { [mcget {session.custom.ga_result}] == 2 } change

Name: Invalid Google Auth Key
Expression: expr { [mcget {session.custom.ga_result}] == 3 } change

Name: User locked out
Expression: expr { [mcget {session.custom.ga_result}] == 4 } change

Al pasar por este control, estará la validación del usuario en el AD y la asignación de recursos. De la política existente agregaremos dos instancias, una para que el usuario ingrese el token, y otra donde haremos la verificación de que el token es correcto.

Imagen 4: gráficos del proceso de verificación completo

Finalmente, aplicaremos la política y verificaremos su funcionamiento desde la óptica del usuario, que será exactamente igual a como estamos acostumbrados a usar LATCH Cloud TOTP, tal como puede verse en el siguiente vídeo (Vídeo 3):