Dynamics 365 F&O

Integraciones con otros sistemas a través de OData – Autenticación con OAuth

n una entrada anterior vimos cómo descargar las definiciones de entidades de datos existentes en Dynamics 365 F&O por medio de OData, pero hacer uso de las entidades de datos por medio de un explorador web no resulta un método muy práctico. El uso más práctico de OData es implementarlo en aplicaciones personalizadas que realicen la conexión directamente con Dynamics 365.

Para poder hacer uso de los servicios es necesario pasar primero la seguridad del sistema. A diferencia de Dynamics AX2012, donde la autenticación y el consumo del servicio se hacen en el mismo ciclo, OData requiere que se le envíe un token de autenticación que se debe obtener con antelación desde Azure Active Directory usando el protocolo OAuth 2.0, por tanto, antes de entrar en detalle sobre cómo se puede hacer uso de OData en una aplicación veremos toda la configuración necesaria de seguridad tanto para extraer el token de OAuth como para permitir que la aplicación sea aceptada por Dynamics 365, y un ejemplo de extracción del token desde código.

01 Permitir una aplicación externa autenticarse con Dynamics 365

Para que una aplicación pueda consumir los servicios de OData, es necesario que se encuentre previamente registrada en el tenant de Azure Active Directory usado en Dynamics 365.

Lo primero es conectarse al portal de Azure (https://portal.azure.com) usando unas credenciales con los permisos suficientes para poder tanto conectarse al portal como para poder crear nuevos artefactos en el tenant usado en la instancia de 365.

Dentro del formulario de App Registrations se debe crear un nuevo registro usando el botón New Registrations

Dentro del formulario de App Registrations se debe crear un nuevo registro usando el botón New Registrations

Aparecerá un formulario donde se solicitarán las siguientes opciones:

• • Nombre: Es el nombre de la aplicación (Puede ser cualquiera, no necesariamente igual al de la integración)

• • Tipos de cuenta soportados: Hay 3 tipos, pero dado que la integración que se va a hacer es solamente interna, se seleccionará Solo cuentas en este directorio de organización

• • URI de redirección: Landed Cost es clave para fijar un precio de venta adecuado que cubra los costos y permita obtener ganancias.

Al dar clic en Registrar se completa el proceso y se redirigirá a una nueva ventana donde se muestran los detalles de la aplicación registrada. Hay un parámetro llamado Permitir flujos de clientes públicos, este valor se discutirá un poco más adelante, pero se puede habilitar.

Finalmente se deben asignar permisos de acceso a las API de Dynamics para que la aplicación pueda hacer uso de los servicios de OData. Los permisos se asignan en Permisos de API, se debe agregar permisos y buscar la API llamada Dynamics ERP

Al seleccionar debemos dar permisos delegados y seleccionar los tres ítems que aparecen disponibles y dar clic en agregar permisos

En este punto es importante considerar el tipo de aplicación que se desarrolla, dado que el modelo de autenticación de Azure Active Directory requiere que, o bien que un usuario ingrese sus credenciales en una ventana de inicio de sesión usando sus credenciales de correo o de Azure, o que la aplicación se autentique usando un valor secreto que tenga almacenado y concuerde con lo que tenga configurado el registro de aplicación.

Si la aplicación va a permitir que el usuario ingrese sus propias credenciales, es necesario habilitar el valor de flujos públicos visto anteriormente. Si la aplicación por el contrario no va a poder solicitar las credenciales de un usuario porque se trata de un servicio o demonio de ejecución en segundo plano, o porque no lo tiene considerado, es necesario crear un secreto. Dado que la aplicación de ejemplo será una aplicación de consola que se va a ejecutar muchas veces, solicitar en forma constante credenciales no es práctico, por lo cual se va a agregar un secreto al registro de aplicación.

Para agregar un secreto se debe entrar dentro del registro de la aplicación al menú de certificados y secretos, donde se debe crear un nuevo secreto. Azure solo pedirá como valores necesarios un nombre descriptivo y un periodo de validez

Luego de asignar los valores y guardar, se crea un registro de secreto. Hay que copiar en forma inmediata el valor de la columna valor dado que es el valor que se debe guardar en la aplicación para hacer la autenticación y solo va a ser visible justo después de creado, si se cambia de menú o se refresca la ventana, el valor queda oculto y no se puede rescatar, haciendo necesario crear un nuevo secreto

02 Registrar aplicación en Dynamics 365

El registro de aplicación en Azure Active Directory no es suficiente para poder conectarse a los servicios web de 365, es necesario hacer adicionalmente el registro de la aplicación dentro de 365 para que reconozca la aplicación, le permita conectarse y sepa adicionalmente con qué usuario debe registrar en el sistema la actividad que realice y el nivel de permisos que el servicio va a tener.

Para registrar la aplicación se debe ingresar a la ruta Administración del sistema > Configurar > Aplicaciones de Azure Active Directory, dentro del formulario se crea un nuevo registro con los siguientes datos:

• Id de cliente: El identificador de aplicación que es generado automáticamente en Azure cuando se creó el registro de aplicación, aparece visible en la visión general del registro

• Nombre: Un valor descriptivo del registro, puede ser el mismo nombre usado en Azure para el registro de la aplicación, pero no es un valor que se valide.

• De usuario: El usuario que va a impersonar la actividad generada por el servicio en 365. El nivel de permisos dentro de 365 con los que cuente la aplicación dependerá de los roles que tenga asignado el usuario que se asigne. Para efectos de pruebas se puede usar una cuenta con el rol de administrador de sistema, pero lo ideal es que se genere una cuenta dedicada que tenga permisos lo más acotados posibles.

03 Generar token de autenticación con OAuth 2.0

OAuth es un protocolo abierto, y por tanto no está atado para ser usado por una sola plataforma, pero para este caso específico se usara Visual Studio 2022 y el lenguaje C# para desarrollar el ejemplo de extracción del token por medio de código.

El primer paso es tener creada una solución en Visual Studio, y dentro de esta solución un proyecto en C#. Por simplicidad, en este caso particular usaremos como tipo de proyecto “Aplicación de consola”.

El siguiente paso es agregar al proyecto y a Visual Studio la librería Microsoft.Identity.Client (MSAL.Net). Esta librería es propia de Microsoft que está disponible en el repositorio NuGet, y nos permite extraer el token de autenticación sin necesidad de entrar en los detalles de fondo de cómo opera OAuth.

04 Instalando los paquetes desde NuGet

La manera más sencilla es usar la herramienta Administrar paquetes NuGet para la solución, la cual se encuentra en el menú de Visual Studio Herramientas / Administrador de paquetes NuGet / Administrar paquetes NuGet para la solución.

En este formulario se debe ingresar a la pestaña Examinar. Luego, usando el cuadro de búsqueda buscar la librería mencionada para finalmente instalarla en el proyecto de prueba. Se debe aceptar la instalación de otros paquetes prerrequisito que el asistente de instalación muestre durante el proceso.

04 Usando MSAL.Nett

La librería descargada Microsoft.Identity.Client cuenta con varias opciones disponibles para obtener el token dependiendo del tipo de aplicación que se esté desarrollando (Web, dispositivo, aplicación de escritorio, aplicación móvil, etc.). Esta librería da la posibilidad de abrir un cuadro de diálogo donde el usuario puede autenticarse o si ya se autenticó anteriormente en otro sistema (Office, Teams, Windows, etc.) seleccionar la cuenta que va a usar sin necesidad de volver a ingresar las credenciales, pero en este ejercicio no tenemos una interfaz de usuario y tampoco queremos ingresar las credenciales constantemente, por lo cual haremos uso de autenticación usando el secreto que creamos anteriormente en Azure.

El código de ejemplo para lograr lo mencionado anteriormente se muestra a continuación:

Como se puede ver, básicamente MSAL solamente requiere de nuestra parte entregarle algunos detalles de donde se va a autenticar, a qué se necesita acceder, nivel de permisos y credenciales para autenticarse, que en este caso corresponden al valor del secreto almacenado.

Al ejecutar el método ejemplo se imprime lo siguiente en consola: