Configuración SMTP-IMAP utilizando OAUTH2

Desde Microsoft han habilitado la autenticación moderna mediante OAuth2. Para ello, se debe crear una aplicación en Microsoft Azure (ver apartado configuración) y solicitar un token de autenticación que se utilizará en las llamadas a la API de IMAP (de Aspose.Mail).

En segelevia este cambio afecta al protocolo IMAP que se utiliza en la recepción del buzón del correo a través del Email Reader. Pero también se puede configurar SMTP para que trabaje mediante este mecanismo de autenticación moderna.

En cuanto al IMAP, en SegElevia, para acceder el Email reader se debe realizar click sobre el icono correspondiente a un SOBRE situado en la barra superior del menú junto a los iconos de seguimiento de estado de actividades, tareas y procesos.

Posteriormente accederemos a la pantalla del Buzón de Entrada en la que podremos gestionar los correos electrónicos con funcionalidades parecidas a las de los clientes web de correo electrónico similares.

Si desea utilizar la autenticación moderna (obligatoria para IMAP) y su correo electrónico es el Outlook 365 debe seguir los siguientes pasos:

· Configuración de la aplicación en Azure/Office 365

· Configuración parámetros de conexión contra IMAP OAuth2 en SegElevia

· Cambios en la conexión mediante Aspose.Mail

· Configuración parámetros de conexión contra SMTP

o SegElevia

o LoginManagerService

o segClient/segColaborador

Configuración de la aplicación en Azure/office 365

Puede usar el servicio de autenticación OAuth proporcionado por Azure Active Directory (Azure AD) para permitir que la aplicación se conecte con los protocolos IMAP, POP o SMTP para acceder a Exchange Online en Office 365. Para usar OAuth con la aplicación, deben realizar los siguientes pasos:

Registrar aplicación

Para usar OAuth, una aplicación debe estar registrada con Azure Active Directory.

1. Acceder al portal de Azure con el usuario: https://portal.azure.com/

2. Buscar y seleccionar Microsoft Entra Id

3. En aplicaciones App registrations creamos una nueva + New registration:

4. Rellenamos los datos del registro: Name=SegEleviaMail

Agregar credenciales

Las credenciales son utilizadas por aplicaciones cliente confidenciales que acceden a una API web, permiten que su aplicación se autentique como sí misma, sin necesidad de interacción por parte de un usuario en tiempo de ejecución.

Puede agregar certificados como credenciales para su registro de aplicación de cliente confidencial se debe realizar a través de los siguientes pasos:

1. Se puede acceder en la misma ruta Azure Active Directory -> Manage -> App registrations y veremos la nueva aplicación creada y procedemos a crear la clave para acceder desde Add a certificate or secret:

2. Se nos abre la siguiente pantalla donde añadiremos la clave y la caducidad:

ATENCIÓN: la Caducidad (Expires) se debe poner según se crea conveniente, el máximo permitido son 24 meses. Es aconsejable poner un recordatorio/alarma antes que venza la caducidad para renovar el Secret durante el periodo establecido. Posteriormente se debe actualizar en segelevia recordando posponer el recordatorio/alarma de nuevo.

3. Una vez generado el secreto se debe copiar en algún sitio porque NO SE VOLVERÁ A MOSTRAR y si se pierde se debe generar una nuevo.

4. Una vez creada la aplicación y generado el secreto se deben conceder los permisos para acceder a los protocolos IMAP/SMTP:

5. Para crear un nuevo permiso se realiza a través del botón Add a permission:

6. Se debe seleccionar la API Microsoft Graph:

7. Se accede a través de Delegated permissions

o Seleccionar OpenId > offline_access

o Seleccionar IMAP.AccessAsUser.All

o Seleccionar SMTP.Send

o Pulsar en Add permissions al final de la lista:

8. Para finalizar se debe Conceder el consentimiento a los permisos seleccionando Conceder consentimiento de administrador:

Deberá quedar así:

Recopilación de datos

Desde la pantalla principal de registro de la aplicación se pueden recuperar los datos que posteriormente se solicitaran en la configuración de SegElevia.

· Application (Client) ID (1): En la pantalla principal del registro de la aplicación

· Directory (Tenant) ID (2): Clave que identifica la empresa

· Client credentials (3): Certificado (recuperado en el momento de la creación).

URL de redirección

En el apartado de URI de redirección, deberán indicar la URL de conexión a SegElevia, con la siguiente ruta:

https://BASEURL/RUTA/FormEngine.mvc/StoreAuthToken

Configuración parámetros de conexión

⚠️Atención: Las cookies de autenticación deben estar marcadas como SameSite=Lax. Esto se debe hacer des del setup de instalación de SegElevia.

Para realizar la configuración de los datos del IMAP en SegElevia se realiza desde el menú Configuración - Correo electrónico. En este caso hay dos modelos de diálogo en función si sólo se configura IMAP o también SMTP:

Sólo IMAP

IMAP y SMTP

Servidor: dirección del servidor de correo de outlook: outlook.office365.com.

⚠️Atención: Se debe cambiar si apunta a cualquier otro host de “office365.com” que no sea “outlook.office365.com”, sino no funcionará.

Puerto: puerto que se utiliza en el servidor de correo electrónico para admitir las conexiones entrantes.

Modo asignación: Automático o manual

Refresco automático: indica el intervalo de minutos de refresco automático del correo electrónico.

Azure: este apartado se debe cumplimentar indicando los datos obtenidos en el apartado Recopilación de datos.

o Id. de directorio (inquilino)/TenantId equivale a Directory (Tenant) ID (2): Clave que identifica la empresa

o Id. de aplicación (cliente)/ClientId equivale a Application (Client) ID (1): En la pantalla principal del registro de la aplicación

o Secreto/Secret equivale a Client credentials (3): Certificado (recuperado en el momento de la creación).

Después de informar los datos de Azure hay varias posibilidades según la configuración de módulos y configuraciones, pero es importante entender que ya no se introducen los passwords de las cuentas, sino que se deben validar externamente mediante la autenticación directa en la web de Microsoft.

Así pues, en los mismos puntos dónde antes se indicaba el usuario y el password, ahora simplemente se indica la cuenta y un nuevo botón para abrir la validación externa. El funcionamiento es igual (o muy similar) para todos:

· Aparece el siguiente botón en el formulario:

· Este botón, guarda los cambios del formulario y abre una nueva ventana del navegador con la página de autenticación de cuenta de Microsoft, algo así:

· Una vez seleccionada la cuenta e introducidos los datos en Microsoft vuelve a redirigir la navegación a una página genérica de validación del token obtenido:

· Desde esta página se muestra un mensaje conforme puede verificar que funcione correctamente el token recibido.

· Además, en esta página aparece un conjunto de acciones para poder probar los distintos puntos de conexión con el correo:

o Probar conexión (SMTP): Envía un correo a una dirección (interna) mediante la configuración SMTP estándar.

o Probar conexión e-Client (SMTP): Envía un correo a una dirección (interna) mediante la configuración SMTP para el segCliente o segColaborador.

o Probar conexión empresa (SMTP): Envía un correo a una dirección (interna) mediante la configuración SMTP para la configuración de una empresa determinada.

o Probar conexión (IMAP): Probar la conexión mediante protocolo IMAP (para el lector de correos).

Como se puede ver, pues, los tipos de configuración de autenticación OAuth son los 4 mencionados:

· SMTP

· SMTP Empresa

· SMTP Front

· IMAP

IMAP

La configuración general, se realiza desde el diálogo mostrado en el apartado anterior Configuración > Correo electrónico > IMAP

Para cada cuenta IMAP, desde la opción Configuración > Configurar buzón de correo (IMAP)

Dónde se puede ver el mensaje informativo y el nuevo botón para validar la cuenta de correo electrónico.

SMTP

La configuración general SMTP para el envío de correos des de SegElevia, se realiza en el mismo punto que la de IMAP, como se ha mostrado anteriormente en Configuración > Correo electrónico > SMTP.

Aquí hay dos posibilidades, emisor único o por usuario.

Emisor único

En este caso ya aparece el botón de aplicar en la misma configuración, además del mensaje informativo sobre la validación de la cuenta, y el textbox para la cuenta:

A destacar que como ya hemos comentado no aparece el password ya. También recordar que el usuario y el correo electrónico deberían coincidir, o sino el usuario debería tener permisos para enviar como esa cuenta.

Emisor usuario

Cuando en la pantalla anterior, se escoge Usuario como tipo de emisor, las cuentas utilizadas son las de cada login particular, por lo que desaparece la posibilidad de indicar los datos de la cuenta de correo electrónico y su validación:

Con esa configuración, el adminstrador deberá verificar que cada login tenga bien establecida la cuenta en la administración de logins: Administración > Gestión de logins > Logins

En esta pantalla tampoco aparece ya el password, y aparece el mensaje de información del nuevo sistema de validación. Igual que el caso anterior, deberían coincidir el Correo electrónico y el Usuario de correo electrónico para evitar problemas en el envío.

Luego, cada login, cuando se conecte deberá validar la cuenta de forma individual en Configuración > Cambiar contraseña email (SMTP). Se mantiene ese nombre por retrocompatibilidad aunque propiamente ya no se trata de cambiar la contraseña sino de validar la cuenta:

En este caso no podemos modificar la cuenta, porque debe haberlo hecho el administrador, y sólo podemos validar.

SMTP Empresa

En instalaciones multiempresa es posible reesciribir la configuración de SMTP para cada empresa en la siguiente pantalla desde Configuración > Datos generales > Empresas / Oficinas. Desde ahí, para cada empresa, se pueden editar los datos del correo electrónico:

En caso de no informarlos, se utilizan los de la configuración de SMTP general. Como podemos ver, aparece el botón para validar la cuenta. Al cambiar el Usuario, recordar también cambiar el correo electrónico de origen en la pestaña dirección, si no coinciden puede dar problemas:

En el caso de la empresa, en la pantalla de validación, se puede probar la configuración por cada empresa, y por defecto queda preseleccionada la de la cuenta que se acaba de validar:

SMTP Front

Las herramientas frontoffice segCliente y segColaborador, por su posibilidad de funcionar de forma independiente a la herramienta de backoffice SegElevia, trabajan el envío de correos de forma un poco distinta, y la configuración se realiza en el siguiente formulario heredado: e-Client > Configuración Logins e-Client > Configuración SMTP

Como se puede observar, vuelven a aparecer los campos de configuración de la aplicación de Azure que permite la autenticación externa. También aparecen dos emisores, pero una sola cuenta, así pues, si se configuran cuentas distintas se deberá corroborar con el administrador de Office365 que estén correctamente configurados los permisos de envío entre las distintas cuentas.

Por otra parte, aquí no se puede validar la cuenta directamente y se debe realizar desde una nueva opción específica: e-Client > Validar usuario SMTP front

En este caso en la posterior página de validación, en la acción de Probar conexión e-Client aparecen los dos tipos de emisor para probar los dos tipos principales de origen en el envío:

· Emisor: el emisor general

· Emisor recordatorio password: el emisor que envía los recordatorios de passwords, o el correo del pin para la autenticación multifactor.

App móvil

El servidor de la app móvil también requiere de configuración específica para el envío de correos de alta, o recordatorio de passwords. Esta configuración la realizan los técnicos que instalan la aplicación, para cualquier duda, contactad con el responsable correspondiente.

Descargar Manual

A continuación, adjuntamos el Manual en pdf para poder descargar.

 Manual configuración SMTP-IMAP utilizando OAUTH2