En este post voy a mencionar algunos aspectos básicos a tener en cuenta, según mi experiencia, respecto a los tipos de usuarios en D365. Y luego explicar el paso a paso de cómo generar un usuario de servicio o “Application User”. Como extra, voy a dejar un ejemplo de aplicación de consola para conectarse a D365 utilizando este método.
Tipos de usuarios admitidos en D365
Se conocen, al menos, tres tipos de usuarios en Dynamics 365
- Usuarios interactivos
- Usuarios no interactivos
- Usuarios de aplicación o de servicio
Los usuarios interactivos, son
los más comunes. Son usuarios nominados que consumen licencia y que se van a
loguear a la aplicación de Dynamics mediante un dispositivo a través de usuario
y contraseña.
Los usuarios no interactivos, por
el contrario, son un tipo de usuario admitido por Dynamics que me permite
ejecutar cualquier acción sobre la api de Dynamics pero estos no consumen
licencia. Se trata de usuarios que solo sirven para ejecutar acciones backend
sobre Dynamics y que no se trata de un usuario de “a pie” logueandose a la
aplicación. El método de autenticación de este tipo de usuarios es también
utilizando el protocolo OAuth como los usuarios interactivos. Como limitación,
solo pueden crearse hasta 5 usuarios no interactivos por entorno.
Por otro lado, los usuarios de
aplicación o de servicio son similares a los no interactivos en el sentido de
que no consumen licencia pero, la ventaja es que no existe limitación en la
creación de estos. Se utilizan en escenarios de integración de datos o procesos
que ejecutan backend. Utilizan otro método de autenticación, ClientSecret
(link para más detalle del flujo de autenticación).
Si los usuarios no interactivos y
los de aplicación son idénticos en funcionalidad ¿Cuándo usar uno u otro?
Bueno, siempre depende del
contexto de la implementación. Pero, para todo proceso backend siempre trataría
de usar usuarios de aplicación. Solo usaría los usuarios no interactivos en
aquellos escenarios donde tenga que conectarme a una api de terceros que el
login no admita el flujo client credencials y solo sea a través de
usuario y contraseña. En ese caso siempre utilizar usuarios no interactivos
porque no es una práctica recomendada utilizar usuarios interactivos.
Paso a paso de cómo generar un usuario de servicio
Pre-requisitos:
·
Es necesario tener acceso al portal de Azure
como administrador o tener los permisos suficientes como para registrar una
aplicación dentro del Active Directory.
·
Tener permisos de administración dentro del
entorno de Dynamics 365 para configurar el usuario de servicio dentro del
entorno.
·
No es mandatorio, pero es necesario tener un rol
de seguridad preparado para asignar a este usuario de servicio. No es una buena
práctica asignar el “Administrador de Sistema” aunque en el ejemplo lo vamos a
hacer igual.
1-
Necesitamos registrar una aplicación en el Azure
Active Directory. Ingresamos a Azure
2-
Dentro del portal de Azure buscamos en la caja
de búsqueda “Registro de aplicaciones” e ingresamos
3-
Seleccionamos “Nuevo registro”
4-
Colocamos un nombre a nuestra aplicación,
generalmente se colocan nombres como por ejemplo: Integración-DEV,
SystemExternalUser, etc. Pero esto es libre y en la opción de quién puede
acceder a la api, dejamos marcada la opción de “Solo cuentas de mi
organización”. Luego oprimimos “Registrar”.
5-
Ahora necesitamos indicarle a esta “Aplicación”
que se debe conectar con la Api de Dynamics utilizando el rol de Impersonate.
Este rol nos permite interactuar con la api como si se tratara de un usuario
común y corriente.
6-
Seleccionamos “Agregar un permiso” luego
seleccionar la aplicación “Dynamics CRM” (es posible que figure el logo viejo y
no el actualizado de Dataverse):
Seguido a lo anterior tildar la única
opción disponible y luego oprimir el botón “Agregar permisos”
7-
Ahora sigue la generación de un “secreto” que
hará las veces de contraseña de nuestro usuario de servicio. Vamos a la sección
de “Certificados y secretos”
8-
Seleccionar “Nuevo secreto de cliente”
9-
La descripción es opcional. En el atributo de
“Expira”, se pide setear el tiempo por el cual nuestro “Secreto” o password del
usuario de servicio, va a tener vigencia. Por defecto, Microsoft recomienda 6
meses. Pero es posible colocar un intervalo mucho mas grande e incluso
personalizado.
10-
Una vez generado el registro del secreto, es
IMPORTANTE copiar el valor del mismo y guardarlo en un lugar seguro, ya que al
salir de la pantalla el mismo ya no estará visible. Si perdemos este dato, nos
fuerza a generar otro valor.
Hasta aquí, finalizaron los pasos para
generar el usuario de servicio. Ahora queda lo último que es ingresar al portal de administración denuestro entorno Dynamics 365 y agregar el usuario al entorno, asignándole
un rol de seguridad.
Hay que ingresar al entorno, luego a “Configuración”,
luego ira “Usuarios y permisos” por último ingresar a “Usuarios de la
aplicación”:
Seleccionar “Nuevo usuario de la
aplicación”, “Agregar una aplicación” y nos va a aparecer la aplicación registrada
en Azure. Seleccionamos la misma, le asignamos un rol de seguridad y eso es
todo.
Bonus Track ¿Cómo probar la conexión? 🚀
Te comparto una aplicación de consola para que puedas probar la conexión utilizando este método de autenticación. Lo que vas a necesitar es el “App ID” que es simplemente el valor que figura en Azure:
Y necesitaremos también el secreto que obtuvimos en el paso 10. Con esos dos datos, más la URL del entorno de Dynamics ya podes usar la aplicación de consola de ejemplo y probar esto.
Espero te haya sido útil este post. Si me olvidé de algo o querés mas detalles acerca de este tema déjame escrito en los comentarios 😉.
Comentarios
Publicar un comentario