Salesforce MFA/2FA: proceso, uso, limitaciones y bug

Este es el segundo artículo sobre mi experiencia en MFA. Si no leíste el primero, y no tiene conocimientos previos, te aconsejo que lo leas antes.

En este artículo vamos a ver varias cosas:

1. Para los admin/developers verás los pasos para activar la funcionalidad .
2. Verás los puntos más impotantes respecto a los procesos de enrollment de dispositivo, uso por parte de los usuarios, unenrollment y los principales unhappy paths.
3. Comentaré la limitaciones que he encontrado bajo mi punto de vista.
4. Describiré un bug que te puede afectar y te pido me ayudés a agilizarlo.

Cómo activar el MFA para los usuarios

Existen 2 opciones para los administradores:

• Crear o modificar un Profile para:
  • asignar el Permission de gestión del MFA.
  • otro para asignar el Permission (obligatoriedad) de autenticación con MFA.
• Crear o modificar un Permission Set para:
  • asignar el Permission de gestión del MFA.
  • otro para asignar el Permission (obligatoriedad) de autenticación con MFA.

Veamos los 2 escenarios a continuación.

Mediante el uso de un Profile

Únicamente debes crear o modificar uno nuevo y asignar el Permission de Manage Multi-Factor Auhtentication in User Interface y/o el de autenticación mediante uso de MFA que se denomina Multi-Factor Authentication for User Interface Logins.

El primero normalmente se lo asignarás a los administradores mientras el segundo se lo asignarás a los usuarios finales que deseas que se autentiquen usando MFA.

Estos son los 2 Permission que deberás asignar

Mediante el uso de un Permission Set

La segunda opción, y en mi caso más versátil, es el uso de Permission Sets. Análogamente crearás o modificarás un Permission Set para asignar la gestión y otro para la autenticación del usuario final mediante MFA.

En la siguiente captura puedes ver cómo he creado un Permission Set llamado 2FA. Busco los System Permission relacionados con Multi-Factor, y el relevante es, el que aparece en última posición.

Creación de Permission Set y asignación del System Permission

Este es el System Permission que debes asignarle al Permission Set 2FA

Si vas a disponer de usuarios gestores de MFA, te recomiendo que crees otro Permission Set denominado, por ejemplo 2FAGestor, y le asignes la segunda opción.

Este es el System Permission que debes asignarle al Permission Set 2FAGestor

Como ves, este proceso es realmente sencillo y no son necesarios conocimientos de administrador avanzado. Cuando le asignas a un usuario el Profile ó el Permission Set de autenticación mediante MFA en su User Detail aparecen varias opciones.

Opciones que aparecen en User Detail cuando le has asignado a un usuario la Autenticación mediante MFA

• App Registration: One-Time Password Authenticator: si el usuario utiliza una aplicación como Google Authenticator, Authy o Microsoft Authenticator aquí aparecerá que lo tiene activado.
• App Registration: Salesforce Authenticator: si el usuario emplea la Salesforce Authenticator aquí aparecerá que lo tiene activado.

• Security Key (U2F): si el usuario utiliza una Yubikey aparecerá aquí.
• Temporary Verification Code (Expires in 1 to 24 Hours): si el usuario temporalmente no puede acceder a los mecanismos de autenticación que tenga activados, puede solicitar al administrador un código temporal para seguir adelante, sin necesidad de esperar volver a tener acceso al dispositivo.

Inicialmente, no entendí muy bien por qué Salesforce había diseñado esta interfaz, y finalmente he llegado a estas conclusiones que he confirmado con el equipo de soporte de Salesforce:

• El usuario puede tener varios métodos de autenticación registrados, hasta el punto que utilice 3! Puede usar una YubiKey, además puede utilizar la aplicación móvil Salesforce Authenticator y además puede ser Google Authenticator (o cualquier otra). No es una user interface que ganaría el premio de usabilidad del año, pero…
• En cualquier momento el administrador puede eliminar uno de estos métodos.

Cómo obtener el método usado por los usuarios

En un momento determinado querrás saber, qué usuarios tienen métodos activados, cuales son, etc. Básicamente conozco he probado los siguientes métodos:

• Crear un report del Report Type Identity Verification Methods
• Consultar via API el objeto TwoFactorMethodsInfo
• Query para conocer los usuarios que tienen un Permission Set activado para uso de MFA

Este es un ejemplo de Report básico que encontrarás utilizando el Report Type Identity Verification Methods, no tiene ningún misterio, lo puedes ejecutar directamente, programarlo para enviarlo bajo ciertas condiciones que quieras recibir, etc.

Este es el Report más básico que puedes crear

También puedes acceder mediante API al objeto TwoFactorMethodsInfo. Para ello tendrás que proporcionar el System Permission Manage Multi-Factor Authentication in API.

La query que he utilizado en el Workbench es:

/services/data/v53.0/query/?q=SELECT+UserId+,+User.Username+,+HasUserVerifiedMobileNumber+,+HasUserVerifiedEmailAddress+,+HasSalesforceAuthenticator+,+HasTotp+,+HasU2F+from+TwoFactorMethodsInfo

Resultado de la Query al consultar el objeto TwoFactorMethodsInfo

Para aquellos que utilicéis Postman como y, el proceso es totalmente equivalente y conocido

La siguiente SOQL query es algo limitada, pero proporciona aquellos usuarios que tienen asignado un Permission Set cuya autenticación es mediante MFA, puedes consultar este hilo para más información (https://trailhead.salesforce.com/trailblazer-community/feed/0D54S00000DylTRSAZ).

SELECT AssigneeId 
FROM PermissionSetAssignment 
WHERE PermissionSet.PermissionsDelegatedTwoFactor = True

Proceso de Enrollment del usuario

No voy a entrar en los detalles, ni captura de pantallas, porque ya compartí varios videos donde se puede observar perfectamente. Lo que voy a destacar son aquellos aspectos y mis opiniones respecto a este proceso:

1. Es muy buena idea que los usuarios se descarguen la Salesforce Authenticator App versus cualquier otra. Varias son las razones: el soporte que podemos obtener bajo incidencias, y su usabilidad son muy superiores al usar las otras Apps.
2. El proceso de la UI, claramente promociona el uso de la Salesforce Authenticator, que ya me parece bien, basado en mis conclusiones del punto anterior. Si tu empresa necesita que se use otra App, deberás formar a los usuarios y complicará el proceso.
3. El usuario puede registrar varias Apps y además una USB key. Como dije en el primer artículo esto sorprende, pero Salesforce lo recomienda, ya que si en un momento determinado el usuario pierde acceso a un método puede utilizar otro (aunque me parece algo improbable este escenario, aceptamos barco). En la vida real, creo que esto debe explicarse muy bien a los usuarios, y puede crear confusiones durante su utilización.
4. El usuario debe tener cobertura de datos durante el proceso, una vez finalizado no necesita cobertura y puede usar el código que se genera cada 30». Esto aplica a cualquier de las Apps.
5. Si el usuario no utiliza la Salesforce App, el usuario deberá tener acceso a la cámara para escanear el código QR que aparece en pantalla.

Proceso de uso (Happy Path)

Con el usuario habiendo finalizado el proceso de enrollment, a partir de este momento, cada vez que quiera autenticarse en la Org o en una Comunidad su experiencia variará en función de la App:

1. Si utiliza la Salesforce Authenticator y habilita los servicios de localización, podrá usar la capacidad por la cual, si se encuentra en un radio a la localización actual, podrá entrar directamente sin ninguna interacción (el radio de actuación está disponible en la misma App – esta pregunta me la hizo mi compañero Isaac y flipé, gracias crack).
2. Además, si no desea esa comodidad o no comparte los servicios de localización, solo deberá confirmar mediante un botón de Accept, y el proceso de autenticación habrá finalizado.
3. Si no usa la Salesforce Authenticator, cada vez que se autentique, deberá proporcionar el código de 6 dígitos, lo que supone la experiencia de usuario menos agradable (aunque es la más común en el mercado con otros servicios como Google, etc.).

Procesos de uso (Unhappy Path)

Basicamente existen 2 escenarios a considerar:

1. El usuario final pierde el móbil o la USB Key o se va del proyecto.
2. El usuario final no tiene acceso al terminal temporalmente (se ha olvidado el móvil o la USB Key).
3. Los escenarios donde el usuario no mete los códigos correctos o no saber usar la App, no los considero, porque creo que las situaciones en las que se pueden llegar a poner los usuarios, supera mi imaginación.

El usuario pierde el método de autenticación

Si el usuario pierde, le roban, o no va a recuperar uno de los métodos de autenticación, o debemos desconectarlo por cualquier otro motivo (se va del proyecto), el administrador debe desvincularle de ese método.

Para ello existe la funcionalidad estándar de Disconnect:

La opción de Disconnect deshabilita la vinculación del método con el usuario

Nota: Si el usuario se desvincula del proyecto además aconsejo Freeze/De-Active (sólo para Administradores noveles).

Quiero destacar:

• Si el usuario ha utilizado la Salesforce Authenticator, la entrada que se creó en la App no se le borrará automáticamente, y sería interesante explicarle como eliminar esa entrada, para evitar acumular entradas inservibles.
• Si el usuario utiliza cualquier otra App, el código se seguirá generando, pero ya no le será útil, no le veo más inconveniente.

Durante este proceso, el usuario va recibiendo correos, de las activaciones de métodos. Estos emails pueden ser un poco confusos para los usuarios finales, y tienes la posibilidad de solicitar el equipo de Soporte de Salesforce que los desactive.

El usuario no tiene acceso temporalmente al método de autenticación (Temporary Code y bug!)

En catalán hay un proverbio: «Qui no té cap, que tingui cames» (básicamente que si olvidas las cosas tendrás que volver a buscarlas), pero esto en Salesforce no es así, gracias a que tenemos a los administradores y debería decir «Si no tienes memoria, búscate un administrador!».

Cuando un usuario olvida su teléfono/Usbkey en casa o no tiene acceso en este momento, el escenario ideal no es desvincularlo del método de autenticación (porque cuando tenga acceso , volverá a necesitar repetir el proceso de enrollment), y si no tiene acceso al terminal, bendita solución le damos.

Para ello Salesforce proporciona la capacidad estándar de generar un Temporary Verification Code. Este proceso está repleto de sorpresas, requiere de interacción entre Administrador y usuario y tiene un bug importante.

Mediante la opción de Generate se inicia el proceso para generar el código temporal

Al iniciar el proceso, lo primero que te va a sorprender, es que el Administrador deberá validar su identidad 🥸. Es decir, deberá enrollarse con MFA y deberá seguir el mismo proceso de MFA que un usuario final. Esto es debido a que Salesforce considera, desafortunadamente en mi opinión, que debe delegarse al Administrador la generación del MFA y requiere una High Assurance Session.

Por si tienes dudas de lo que te estoy explicando, por favor dirígete la página del Help: https://help.salesforce.com/s/articleView?id=sf.security_temp_id_verification_code_generate.htm&type=5 y en el punto comprueba la frase «If you don’t already have a session with a high-assurance security level, Salesforce prompts you to verify your identity.«

Este proceso no es algo que el Administrador espere, y le fuerza a enrollarse en MFA. Mi recomendación, aunque para cada proyecto será distinto y quizás debas buscar otra alternativa, es que modifiques en Session Settings, para que el Login mediante Username/Password sea considerado High Assurance (esta solución se la debo a mi compañero Alex Herrador, gracias compañero!).

He modificado los Session Settings para que el Username/Password sea considerado High Assurance

El proceso posterior consiste en 2 pantallas: seleccionar la longevidad de este código y la propia generación de este. El administrador deberá comunicar al usuario este código para que lo utilice en su próximo login.

Cuando el usuario recibe este código, puede autenticarse con sus credenciales y la plataforma le solicita el código temporal que ha recibido del administrador.

Si el usuario, recupera el acceso al método de autenticación antes del período de vigencia, el administrador puede cancelar el código y expirarlo.

El administrador puede expirar el código generado.

Bug importante (necesito tu ayuda)

Hasta aquí, todo correcto hasta que te das cuenta que este proceso no funciona para los usuarios de Comunidad (Experience Cloud).

😢 Cuándo el usuario de la Comunidad intenta autenticarse y proporcionar el código temporal que le ha facilitado el Administrador, sus credenciales nunca son aceptadas y no puede autenticarse 😢.

Después de abrir un Caso con el Soporte de Salesforce, hablar con el Success Manager, buscar en Linkedin al Identity Product Manager, y que un Engineer lo confirmarra (a mi madre no la pude contactar) aunque reconocen este bug, de momento no hay fecha de corrección. Puedes encontrar el known Issue en esta dirección: https://trailblazer.salesforce.com/issues_view?id=a1p4V000001rov1QAA.

Te pido que si lo crees conveniente, puedas votar en este 🙌 ENLACE 🙌 , para que este bug sea corregido con prioridad por parte de Salesforce, ya que afectará a muchos de nosotros y de momento no he conseguido motivarlos lo suficiente.

Pero Esteve, ¿Por qué tanto alboroto si hay un Workaround? Revoke Temporary Verification Code and ask that the user approve via Authenticator when available.

Porque si el usuario se ha dejado el terminal en casa, y revocas el código temporal, sigue sin poder acceder a la App, porque justamente no tiene el terminal. Lo que estás haciendo, es que no pueda acceder por no tener el terminal y además le cancelas el código que le podría ayudar.

Nota: Si consigo obtener información sobre la fecha de resolución, y quieres recibir la fecha, suscríbete a esta entrada, y realizaré un comentario y lo recibirás.

Limitaciones

Estas son las limitaciones que he encontrado:

1. ¿Puedo limitar las aplicaciones que puede usar el usuario como método de Autenticación? NO, confirmado con el Soporte de Salesforce tras varios emails. El usuario puede usar cualquier App que cumpla el estándar.
2. ¿Puedo modificar la user interface del proceso de enrollment, porque quiero tal o cual requerimiento? No.
3. El proceso de generación y uso de códigos temporales no funciona con los usuarios de Comunidad.
4. En la UI no se puede saber que Authenticator App ha utilizado el usuario cuando no es la de Salesforce, solo saber que la tiene activada.
5. La oferta de Yubikeys en el mercado puede complicar el proceso de verificación de aquellas que van a funcionar correctamente.
6. Los casos de uso para los unhappy path requieren comunicaciones directas con los administradores. Escenarios que proporcionaran un autoservicio y limitar la actuación del administrador, sería mucho más user-friendly y con un tiempo de respuesta mucho más ágil.

Espero que te sea de ayuda y me encantaría recibir tus comentarios, correcciones u opiniones al respecto.