DEV Community: Juan Carlos Ruiz Pacheco

Publicar aplicaciones de Office 365 (M365)

Juan Carlos Ruiz Pacheco — Tue, 07 Jan 2020 18:25:45 +0000

Como partners de Microsoft podemos publicar aplicaciones entorno a la plataforma de M365 (Office 365), esto incluye aplicaciones como

Office add-ins
SharePoint solutions
Power BI visual
Teams Apps

Al publicar estas Apps, ellas aparecen como aplicaciones disponibles en los public Marketplace de Microsoft para cada uno de estos servicios.

Para ello debemos cumplir con los siguientes requisitos

Tener una cuenta de partner en el Partner Center
Registrarse con una cuenta de desarrollador de M365
Completar el perfil de partner desarrollador

Tener una cuenta de partner en el Partner Center

No profundizaré mucho en esta, hay que ir al Partner Center y registrarse, sobra decir que debes ser una empresa constituida legalmente para ello.

Registrarse con una cuenta de desarrollador de M365

Ya estando registrado cómo partner debes inscribirte cómo desarrollador de M365.

Inicia sesión en el Partner Center con las credenciales de partner.
En otra pestaña Inicia sesión en el Portal De Registro Como Developer si te pregunta por credenciales utiliza un personal liveID NO cuentas corporativas, es decir NO tu cuenta de partner.
Una vez allí selecciona la opción de Office
Lo cual te lleva a esta pantalla, das click en Sign up now
Y diligencias el formulario
Al hacer esto te trae de vuelta al Partner Center, donde notarás que se habilita el módulo de Office Store.

Qué pasa sino me registro como developer de M365

Lo que sucederá es que no te aparecerá el modulo de Office Store, no tendrás forma de publicar una de las Apps listadas al inicio.

Completar el perfil de partner desarrolador

Esto es muy importante y muchas veces se pasa por alto, sino completas este proceso no podrás publicar ninguna aplicación por lo que es importante avanzar en este tema en tanto continuas con el desarrollo o antes de iniciarlo.

Desde el Partner Center vas a la configuración (engine en la parte superior izquierda) y seleccionas Developer Settings (también vas directo dando clic en el vínculo anterior)
Te aparecerá un panel como este, donde verás "Verification Status: Pending"
Debes completar la información en cada una de las etapas, y usar tus credenciales de partner. Si uno de los pasos no tiene una verificación exitosa recibirás una alerta como esta: "Verification Status: Rejected", que impedirá que tu cuenta sea verificada hasta no hacer las correcciones.
Una vez completas todos los pasos tu cuenta queda verificada. "Verification Status: Authorized"

Qué pasa si trato de publicar una aplicación y mi cuenta no está verificada?

Esto pasa, pero el mensaje no saldrá hasta que no des click en publicar, por lo que no te hagas falsas ilusiones si el botón te sale habilitado.

Estás listo para publicar aplicaciones de M365 como Partner de Microsoft. 😊

Añadir tracking de consumo en despliegues ARM

Juan Carlos Ruiz Pacheco — Tue, 31 Dec 2019 23:12:35 +0000

Título Alterno:

Atribución del consumo de Azure de nuestros clientes

He invitado a co-escribir este artículo a mi buen amigo y colega Juan Carlos Sosa, quien trabaja como Ingeniero en Habilitas.

Habilitas es una empresa Costarricense que genera productos para el sector financiero, más abajo en el capítulo Caso Real de implementación Habilitas nos describe el caso particular de su compañia y como el tracking de consumo los beneficia en el proceso de implementación de su solución.

Pueden seguir a Juan Carlos Sosa en Dev.to

Juan Carlos G. Sosa RivasFollow

Lead en Habilitas Team, Sr. Software Dev, Geek.

Cuando trabajamos como partners de Microsoft (por ejemplo ISVs) tenemos control de cuanto es el consumo de Azure de nuestras soluciones, esto es relativamente fácil cuando nuestro software es un SaaS (Software As A Service). Sin embargo en ocasiones los requerimientos de nuestros clientes implican que algo, o toda, nuestra aplicación se despligue en la infraestructura de ellos.

Algunos casos comunes en los que se requiere el despliegue de infraestructura en suscripciones de Azure de los clientes son:

Bases de datos: por regulación o políticas internas los datos deben quedarse bajo el completo control del cliente
Web App / Virtual Machine: El cliente requiere una 'máquina dedicada' donde se reduzca en su totalidad el riesgo de compartir datos en memoria, archivos y otros recursos con otras organizaciones y requiere ser el administrador de esa infraestructura.

Estos y otros escenarios comunes son perfectamente realizables gracias a la flexibilidad que nos brinda la nube, sin embargo hay otros desafíos que no siempre son detectables a simple vista.

Entre más exitosa es tu solución más Azure consumes

Conforme tu solución SaaS es adoptada por tus clientes, tu consumo de servicios en la nube tiende a subir, por ello en la medida en que seas exitoso Microsoft es exitoso también. Desde luego entre más consumo de Azure se genere por el éxito de tu negocio más visibilidad tienes con el equipo comercial de Microsoft y eso abre las puertas a otras oportunidades de ofertas, ventas conjuntas, entrenamientos y otros beneficios más para los partners.

Justo allí es donde surgen algunas preguntas importantes.

¿Qué pasa cuando debo hacer despliegue de infraestructura en las suscripciones de mis clientes?

Cuando despliegas la infraestructura de tu aplicación en las suscripciones de tus clientes los consumos de Azure generados son sus consumos y ellos cubren esos gastos. Ese consumo es derivado de la aplicación que les vendiste, pero normalmente no tienes forma de saber de saber cual es el consumo de esos servicios ni forma de incluirlos en tus reportes y por ende no puedes recibir crédito por el consumo que has influenciado.

¿Cómo puedo medir ese consumo de servicios de Azure que mi empresa (el partner) ha generado de manera indirecta?

Hay que marcar la infraestructura desplegada en tus clientes, para hacerlo debes desplegar esa infraestructura por medio de un template ARM y en dicho template agregar algunos atributos que te permitan a ti y a Microsoft tener un adecuado seguimiento de los consumos de Azure derivados de esos servicios.

A continuación revisaremos cómo inyectar los atributos de seguimiento en un template ARM y dónde podemos seguimiento a dichos consumos.

Alerta de Privacidad
Perfil de partner en el "Microsoft Partner Center"
Registrar el Guid en el Partner Center
Adicionar el Tracking Guid a los ARM
Verificar el Tracking de Consumo en Reportes
Caso Real de implementación Habilitas
Notas importantes

Alerta de Privacidad

Los datos recolectados por Azure y la plataforma de Partners de esta manera son cobijados por las políticas de privacidad de Microsoft.

De igual manera, como partner, es tu responsabilidad notificar a tus clientes al respecto de que haces seguimiento de los consumos derivados de los consumos de servicios de tu aplicación.

Perfil de partner en el "Microsoft Partner Center"

Lo se, parece un poco obvio pero es mejor aclararlo, este mecanismo esta diseñado para partners de Microsoft y para ser partner debes tener tu empresa registrada en el Partner Center, si aún no lo has hecho puedes iniciar aquí tu registro como partner/ ISV.

Generar un Guid para el seguimiento

Para realizar el tracking debes tener un Guid (Globally Unique Identifier) el cual debes asocial al template ARM y también en tu cuenta del Partner Center.

Hay 3 formas principales de crear este Guid

Utilizando el Formulario de generación de GUID : Esta opción es la recomenda aunque no es requerida.
Usando PowerShell: Basta con ejecutar New-Guid y la consola nos devuelve un Guid con el formato requerido.

PS C:\> New-Guid
Guid
----
0352cf0f-2e7a-4aee-801d-7f27f8344c77

Cualquier otro mecanismo con el que estés familiarizado siempre y cuando retorne un Guid con el formato requerido

Registrar el Guid en el Partner Center

Una vez generado el Guid es necesario registrarlo en el Partner Center, para ello vamos a Account Settings o siguiendo los pasos de la imagen (si, Developer Settings)
Una vez allí hacemos scroll down hasta encontrar Tracking GUIDs
Damos click en "Add Tracking GUID" y diligenciamos el formulario con el Id generado en la sección anterior y una descripción. Puedes generar IDs por cliente, por ambiente, por aplicación, en escencia por cada cosa que desees, por eso es conveniente usar una descripción que se adapte a tus necesidades.
Una vez hecho esto el Guid aparece en la lista, podemos agregar todos lo que se consideren necesarios.

Adicionar el Tracking Guid a los ARM

Teniendo registrado el Guid en el Partner Center es hora de incluirlos en el/los template ARM que usaremos para desplegar la infraestructura.

Para ello lo que se hace es agregar un nuevo recursos a la lista y este recurso tiene nuestro Guid con el prefijo pid-.

Dentro del ARM ubicamos la sección de recursos que viene con esta estructura, usualmente entre el 1ro y el 3er miembro de la lista.
```
"resources": [
    {recurso 1...},
    {recurso 2...},
    {recurso N...}
]
```

Justo arriba del primer recurso adicionamos el siguiente recurso, fíjate en el atributo "name" allí encuentras el prefijo pid- seguido del Guid registrado en el Partner Center, en este caso 0352cf0f-2e7a-4aee-801d-7f27f8344c77. Atentos con la , al final, es una lista de objetos JSON por lo que sino pones la , arruinarás la estructura.

{
    "apiVersion": "2018-02-01",
    "name": "pid-0352cf0f-2e7a-4aee-801d-7f27f8344c77",
    "type": "Microsoft.Resources/deployments",
    "properties": {
        "mode": "Incremental",
        "template": {
            "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
            "contentVersion": "1.0.0.0",
            "resources": [
            ]
        }
    }
}

El archivo JSON queda más o menos así

...
"resources": [
    {
        "apiVersion": "2018-02-01",
        "name": "pid-0352cf0f-2e7a-4aee-801d-7f27f8344c77",
        "type": "Microsoft.Resources/deployments",
        "properties": {
            "mode": "Incremental",
            "template": {
                "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
                "contentVersion": "1.0.0.0",
                "resources": [
                ]
        }
    }
},
    {recurso 1...},
    {recurso 2...},
    {recurso N...}
],
...

Ahora es tiempo de hacer el despliegue ARM template y una vez hecho procedemos a verificar que los recursos hayan quedado marcados de correctamente.

Verificar el Guid

Primero asegúrate de tener instalado el módulo de Azure para PowerShell, puedes instalarlo de cualquiera de estas formas según lo que requieras.

PS C:\> Install-Module -Name Az -AllowClobber -Scope CurrentUser

PS C:\> Install-Module -Name Az -AllowClobber -Scope AllUsers

Ahora asegúrate de tener en PowerShell iniciada la sesión en tu suscripción de Azure. Si manejas más de una suscripción debes hacer comandos adicionales que encuentras en la documentación de Azure Power Shell.

PS C:\> ConnectAzAccount

Una vez instalado ya puedes verificar que los ítems hayan quedado marcados para tracking. Es sencillo ejecutando este script de PowerShell, mi recomendación es que lo guardes en un archivo armtagverifier.ps1 y lo ejecutes por consola.

Param(
    [GUID][Parameter(Mandatory=$true)]$guid,
    [string][Parameter(Mandatory=$true)]$resourceGroupName
)

# Get the correlationId of the pid deployment

$correlationId = (Get-AzResourceGroupDeployment -ResourceGroupName $resourceGroupName `
                    -Name "pid-$guid").correlationId

# Find all deployments with that correlationId

$deployments = Get-AzResourceGroupDeployment -ResourceGroupName $resourceGroupName |
                Where-Object{$_.correlationId -eq $correlationId}

# Find all deploymentOperations in a deployment by name
# PowerShell doesn't surface outputResources on the deployment
# or correlationId on the deploymentOperation

foreach ($deployment in $deployments){

# Get deploymentOperations by deploymentName
# then the resourceId for any create operation

    ($deployment |
        Get-AzResourceGroupDeploymentOperation |
        Where-Object { 
            $_.properties.provisioningOperation -eq "Create" `
            -and $_.properties.targetResource.resourceType -ne "Microsoft.Resources/deployments"
        }
    ).properties.targetResource.id

}

Al ejecurtarlo te pedirá el Guid y el nombre del grupo de recursos en el que se realizó el despliegue.

Supply values for the following parameters:
guid: 0352cf0f-2e7a-4aee-801d-7f27f8344c77
resourceGroupName: nombreResourceGroup

Y el resultado es una lista de los recursos que han quedado marcados con el despliegue

/subscriptions/adcbda71-......uank/config/web
/subscriptions/adcbda71-......uank/hostNameBindings/testjuank.azurewebsites.net
/subscriptions/adcbda71-......uank
...

Verificar el Tracking de Consumo en Reportes

Habiendo configurado el traking de consumo en el despliegue de infraestructura utilizando el Guid, la plataforma de Azure comienza a buscar correlación entre los datos de consumo de las suscripciones y los Guid registrados en la plataforma de partners.

Para visualizar dicha información hay que dirigirse al Partner Center, módulo de MPN y la opción de Analize. Es importante notar esto, ya que dependiendo el tipo de partner y los servicios que ofrezca tu empresa puedes tener otros módulos cada uno con su propia opción de Analize.
En el módulo de Analize vamos a Cloud product Performance
Allí vamos a la pestaña "Microsoft Azure" y en el combo "Partner Association Type" seleccionamos "Customer Usage Attribution". Allí ya podemos ver el resultado del consumo de Azure que hemos generado por cada tracking (Guid) que hemos registrado en el portal. El reporte se despliega en el dashboard.

Caso Real de implementación Habilitas

by Juan Carlos Sosa

Como empresa nos enfocamos totalmente hacia el desarrollo orientado a la nube (Específicamente Microsoft Azure) mediante tecnologías Microsoft, nuestro ámbito principal es la generación de soluciones que se integran con las aplicaciones de línea de negocio de las compañías. Trabajamos bajo la modalidad software como servicio (SaaS), infraestructura como servicio (IaaS) y plataforma como servicio (PaaS), todo esto dependiendo de cada caso cubierto y de las especificaciones y restricciones que cada cliente pueda tener.

Con el tiempo hemos ido creciendo en cuanto a tecnologías y servicios que prestamos a los clientes, así como también en modalidades y niveles de servicio disponibles, todo esto ha implicado ir adaptándonos a requerimientos y políticas internas de cada organización, las cuales son cada vez más estrictas. Muchos de nuestros clientes hacen parte del sector financiero.

Actualmente la evolución de la empresa nos ha impulsados a dos nuevos escenarios de cambio y adaptación:

Escenario 1: Restricciones de negocio

En nuestros recientes proyectos hemos trabajado con entidades que requieren que sus servicios corran total o parcialmente en sus propias suscripciones de Azure, esto debido a que deben seguir algunas restricciones legales o de operación, relacionadas con la custodia de la infraestructura o los datos que recolectan.

Esto nos genera dificultades para rastrear el consumo que generan nuestras aplicaciones dado que todo el consumo que estamos influenciando se ha quedado sin tracking alguno, ni de nuestro lado ni del lado de Microsoft.

Escenario 2: Delegación de control

En ocasiones los clientes quieren delegar el control de su infraestructura en el proveedor de la solución(nosotros) y en ocasiones requerimos delegar el control de dicha infraestructura en el cliente, por diversos motivos.

Actualmente contamos con infraestructura en la nube que está cubriendo las necesidades de nuestros clientes, aunque estos recursos actualmente se encuentran bajo nuestra cuenta de azure principal queremos reorganizarlos para permitirle al cliente tener el control de las mismas en sus propias suscripciones.
Aunque este escenario nos resulta conveniente - en la medida que delegamos el control de esa infraestructura - , no nos resulta tan favorable de cara a medir nuestro impacto como partner en el ecosistema.

Remediación

En primer lugar: la implementación del tracking de consumo en las plantillas ARM nos proporcionará dos oportunidades de mejora:

La posibilidad de organizar, automatizar y poder replicar a futuro nuestros despliegues mediante plantillas. Esta posibilidad de replicación nos permitirá tener despliegues más confiables y propiciará la exactitud de la replicación entre los diferentes ambientes a utilizar (en nuestro caso por lo general Desarrollo, QA y Producción).
Mediante la utilización de la plantilla ARM podremos adicionar el GUID para hacer tracking de nuestra solución. De esta forma tenemos visibilidad del acumulado de consumo de Azure de nuestra solución en Azure en nuestros clientes, lo cual a su vez nos permite tener mayor relevancia y oportunidades de beneficios dentro del programa de Partners de Microsoft.

Notas importantes

Aunque esta funcionalidad es muy buena, no es perfecta y hay algunas restricciones que debes tener en cuenta

Si haces un nuevo despliegue por ARM Template en el mismo grupo de recursos bien sea utilizando el mismo Guid o uno nuevo, el tracking anterior desaparece. Es decir siempre se tiene en cuenta solo el último despliegue.
Si adicionas nuevos servicios al grupo de recursos estos servicios no se encontrarán marcados con el Guid, por lo que no puedes trackear el consumo de los nuevos servicios aunque estén en el mismo grupo de recursos.
Debes tratar la infraestructura de tu aplicación como un todo, cada adición o eliminación de un servicio supone que hagas un nuevo despliegue. Esto podría ser engorroso por lo que te sugiero implementar "Infraestructura como Código" en tus pipeline de DevOps. Los templates ARM son una muy buena forma de hacerlo, pero cuentas con otras opciones como las API de ARM o Terraform.
⚠ Este blog post esta basado, en buena parte, en la documentación oficial de Microsoft: "Azure partner customer usage attribution"

Autenticación de Bots con Azure Active Directory

Juan Carlos Ruiz Pacheco — Fri, 27 Dec 2019 00:50:09 +0000

Adicionar autenticación usando Azure AD es 'relativamente' sencillo.

'Relativamente'?, si relativamente porque aunque el concepto de como hacer una integración con el directorio activo es ámpliamente conocido, los detalles para hacer dicha integración no suelen ser tan obvios.

Para poder usar de manera intuitiva Azure AD sería necesario tener algunos conocimientos previos de los flujos de autenticación modernos (OAuth principalmente), y admitámoslo ese no es el caso la mayoría de las veces así que hay que darse unas cuentas vueltas a la documentación y hay que reconocer que muchas veces eso tampoco es suficiente.

En esta entrada de blog me enfocaré en como realizar integración de un bot creado con Bot Framework y por extensión hospedado en Azure Web App Bot (o corriendo localmente).

lo sé, suena redundante, pero me gusta decir: "mejor que so-sobre y no que fa-falte"

Resumen

Hay un conjunto de pasos para realizar la integración y en algunos casos no importa el orden en que los realices por ejemplo podrías crear el Web App Bot primero, pero hay una razón por la cual es mucho mejor leer esta entrada de blog que seguir el pie de la letra la documentación. Si sigues estos pasos no habrá lugar a confusiones, en especial en escenarios corporativos cuando es posible que te encuentres con ambientes de Azure con múltiples suscripciones o AD tenants.

Si, ya he llorado lagrimas y no quiero que te pase lo mismo, así que aquí te presento una serie de pasos en los que tienes que seguir el orden propuesto para obtener los resultados deseados, rápidamente y sin confusiones.

Con el propósito de enfocarnos en la integración y no en el desarrollo del bot vamos a utilizar la librería de ejemplos del Bot Framework y con uno de ellos probaremos que la integración ha funcionado de manera exitosa.

Registrar el Bot en Azure AD
Configuración de la App Registrada
Crear y configurar un Web App Bot en Azure
Configuración de la solución en Visual Studio
Configuración del emulador
Prueba de Autenticación con Azure AD

Registrar el Bot en Azure AD

Registro inicial de la aplicación

En el portal de Azure vamos al Directorio Activo, puedes hacerlo como quieras, a mi en particular me gusta usar la barra de búsqueda así
Una vez en el Azure AD vamos a 'App Registrations' y damos click en 'New Registration'
En la ventana emergente le ponemos nombre al bot y en "Supported account types" nos aseguramos de seleccionar la indicada, dado que los bots la mayoría de las veces son para atender incluso a gente fuera de nuestra organización se recomienda que usemos la 2 opción, si nuestro bot requiere autenticación de otras plataformas con Microsoft ID como cuentas de outlook o de Xbox podríamos usar la 3ra.
Un poco más abajo del paso anterior encontramos "Platform configuration" y está marcado como opcional. Puedes dejarlo en blanco si quieres, en mi caso lo marcaré con la primera opción ya que , por supuesto, el Bot es una parte aplicación web y otra cliente móvil.
Click en "Register" y esperamos unos segundos
Y listo! ... por ahora, porque antes otra explicación.

Ahora que tenemos registrada la aplicación necesitamos entender la mecánica básica del flujo de autenticación.

En corto:

La aplicación se presenta ante en Azure AD, para ello demuestra su identidad con un ID (llamado Client ID) y un Password (llamado Secret)
Si el directorio la conoce le devuelve un token que debe usar en cualquier transacción que requiera hacer con el AD
Cuando un usuario inicia sesión desde la aplicación, la aplicación usa una URL provista por el Azure AD en la que el usuario puede ingresar sus datos de acceso de manera segura
Al iniciar de manera exitosa el usuario es redirigido a una URL de la aplicación (Redirect URL) incluyendo en los datos del request (URL, Headers o a veces body) un token de acceso para el usuario y otros metadatos.

He resaltado tres componentes, al lado de cada uno una breve explicación

Client ID: Es único por cada aplicación
Secret: Pueden haber varios, desaparecen una vez generados, así que es mejor copiarlos, usarlos y olvidarse de ellos. Si se requiere de nuevo en ese caso mejor generar uno nuevo.
Redirect URL: Pueden ser varias, son las URL autorizadas de la aplicación, donde está puede analizar los contenidos del request (redirect) que le hicieron y extraer el token del usuario y los metadatos que lo acompañan.

Configuración de la App Registrada

En el Azure AD vamos a la App Registrada
En Overview logramos identificar dos datos muy importantes, que para facilidad vale la pena que guardes para más adelante. El primero de ellos es el Client ID y el segundo Tenant ID que no es otra cosa que el ID del directorio Activo donde se registró la aplicación.

Id Value

Client ID da2e26d8-a9c9-442a-8831-c972fe6f281a

Tenant ID bcc54888-4288-4bbd-c041-3225637c7154
En el panel de la izquierda navegamos hasta "Authentication" y allí damos click en "Add a platform"
En el panel emergente damos click en el botón 🌐 Web
En Redirect URIs colocamos https://token.botframework.com/.auth/web/redirect todo lo demás lo dejamos tal como está. Damos click en "Configure"
A continuación navegamos a "Certificates & Secrets" en el sidebar y damos click en "New client secret"
En la ventana emergente ponle un nombre que te ayude a recordar a quien o para que usaste ese secreto de la aplicación, selecciona el tiempo de expiración que desees para el secreto, en este caso he seleccionado "Never" pero en cada compañía manejan políticas diferentes para ello. Click en "Add".
Una vez creado copia de inmediato el secreto, una vez generado, cuando regreses a esta ventana, ya no lo podrás recuperar. Les muestro el mio porque igual solo existirá mientras creo este artículo.

Description	Expires	Value
juankbot	12/26/2020	`j32e5fbN@lk[Su0oZXmLFnazaPgt@uv_`

Con esto terminamos nuestra configuración en el Azure AD, los datos relevantes que debemos llevarnos son

Item	Value
Client ID	`da2e26d8-a9c9-442a-8831-c972fe6f281a`
Tenant ID	`bcc54888-4288-4bbd-c041-3225637c7154`
Secret	`j32e5fbN@lk[Su0oZXmLFnazaPgt@uv_`

Permisos en el Microsoft Graph (opcional en este momento)

Ya tenemos nuestra aplicación registrada en el Azure AD y tenemos los datos para el acceso, pero a ¿Qué cosas le vamos a dar acceso?.

Podemos dar acceso a infinidad de cosas de Productos de Microsoft, del Microsoft Graph e incluso de aplicaciones de terceros o propias.

Hay 2 tipos de permisos, delegados y de aplicación.

Hablamos de "Permisos de aplicación" cuando la aplicación corre como un servicio en segundo plano sin que ningún usuario deba iniciar sesión.

Como nuestro bot necesita actuar en nombre de un usuario (usualmente para conectarse con aplicaciones o servicios a los cuales el usuario tiene acceso completo o limitado) necesitamos permisos delegados.

Por el momento solo nos interesa autenticarnos e iniciar sesión, así que debemos conceder los siguientes permisos cuando se acceda desde nuestra aplicación.

profile
openid
offline_access

Para hacerlo debemos seguir los siguiente pasos en el Azure AD.

Navegar hasta el registro de la aplicación, ingresar en el registro
Navegar en el sidebar hasta "API Permissions" y dar click en "Add a permission"
En el panel emergente seleccionamos "Microsoft Graph"
Seguidamente damos click en "Delegated permissions" y usando la barra de búsqueda, buscamos y seleccionamos profile,openid,offline_access, damos click en "Add permissions"
Una vez hecho podemos dejar 'pre-autorizados' estos permisos para todos los miembros de la organización, sino lo hacemos cuando cada usuario inicie sesión se le preguntará si desea conceder estos permisos a la aplicación.
Esperamos unos segundos y damos click en "Refresh" de tal manera que el botón "Grant admin consent for..." se active. Le damos click.
En el diálogo emergente iniciamos sesión, se nos preguntará si queremos dar consentimiento para estos permisos en toda la organización, aceptamos.

Con esto finalizamos la configuración de permisos en el AD.

Crear y configurar un Web App Bot en Azure

Creación del Web App Bot en Azure

Ahora crearemos un Azure Web App Bot, que en escencia es el bot que conectaremos con Azure AD.

Creamos un nuevo grupo de recursos y para este caso lo llamaremos juank-rg, para hacerlo en el home de Azure portal le damos click en donde indica la siguiente figura.

Una vez allí buscamos "Resouce Group", colócale un nombre adecuado, selecciona la región de tu conveniencia y procede a crearlo.
Ve al grupo de recursos recién creado, dale click en "Add"
En el panel de creación busca "Web App Bot" y procede a crearlo
Hasta este punto configura la información según consideres pertinente.
Selecciona el App Service plan correspondiente, sino tienes un App Service Plan o no sabes qué es, procede a crear uno desde allí mismo. Asegúrate de usar un nombre y región apropiados.
Recomiendo siempre, SIEMPRE, dejar habilitado Application Insights el día que tengas que hacer solución de problemas lo agradecerás. También recuerda configurar una región a apropiada par ti.
‼ Hemos llegado al punto importante de la integración con el Azure Active Directory. Haz click en el recuadro justo abajo de la configuración anterior "Microsoft App ID and Password".

⚠ Al momento de escribir este artículo es MUY MALA IDEA usar la opción de auto-creación, porqué? porque si lo haces de esa manera tendrás que volver al directorio activo y buscar la aplicación que creará automáticamente. Y si de suerte el directorio activo que usas está en otra suscripción de Azure, te harás un enredo que bueno... por eso escribo este artículo.

Dale click en "Create New" y pega allí los datos que guardamos anteriormente. Y finaliza dando click en "OK".
Al finalizar dale click en "Create" y la plataforma procederá a crear el Bot y los demás assets necesarios.

Configuración del Web App Bot

Ahora que hemos creado en el servicio en Azure debemos hacer un par de configuraciones.

En el bot services vamos a Settings y en el panel de la derecha hacemos scroll hasta la parte inferior buscando "OAuth Connection Settings" Y damos click allí.
Le colocamos un nombre adecuado a la conexión, ciertamente un Bot podría iniciar sesión contra varios Directorios diferentes, así que aquí debemos configurar nuestro directorio activo. Hay dos formas de hacerlo, con Azure AD v1 y Azure AD v2. Ambas funcionan pero en condiciones normales siempre deberías seleccionar la última versión disponible, en este momento Azure AD v2. Así que seleccionamos ese en la lista de service providers. Inmediatamente aparecen los campos que debemos llenar, para los cuales ya tenemos información. En el campo "Scopes" colocamos los valores que listo a continuación, los cuales indican que necesitamos permiso para iniciar sesión y acceder a la info del usuario. Esta lista puede cambiar dependiendo de que otras cosas queremos acceder del Microsoft Graph.

Item Value

Client ID da2e26d8-a9c9-442a-8831-c972fe6f281a

Tenant ID bcc54888-4288-4bbd-c041-3225637c7154

Secret j32e5fbN@lk[Su0oZXmLFnazaPgt@uv_

Scopes openid profile

La lista de scopes es case-sensitive y debe estar separada por espacios en blanco.
Le damos click en "Save" y queda así
Inmediatamente volvemos a abrirla para dar click en "Test Connection" allí debes iniciar sesión, usa tus credenciales para acceder al portal de Azure. Sino has hecho el paso opcional de asignación de permisos en el Azure AD verás una pantalla como está y como eres admin te dará la opción de consentimiento de estos permisos para todos los usuarios de la organización, si ya habías hecho el paso de los permisos esta pantalla no aparecerá.
Al autenticarte aparecerá la siguiente pantalla de comprobación donde puedes ver y copiar el token generado. Sino sale o recibes un error deberás revisar la configuración anterior o incluso volver a revisar el registro de la Aplicación en el Azure AD. Guarda y cierra el dialogo.
Ahora que tenemos la autenticación del servicio configurada y verificada vamos a "Configuration" en el Sidebar y allí encontraremos "Application Settings" y justo en la lista de settings
- MicrosoftAppId
- MicrosoftAppPassword
Verificamos que los valores correspondan, pista: siempre corresponden.

⚠ Ten presente que aunque el setting MicrosoftAppId es editable, cambiarlos por el ID de una nueva aplicación que tengas en el Azure AD no servirá de nada, tu aplicación quedará inútil ya que este valor debe corresponder siempre con el que aparece en "Settings" que como podrás ver es un campo ineditable.

Con esto terminamos la configuración del servicio del Bot. Sin embargo para que el tema siguiente funcione se requiere un paso adicional así que lo haremos de una vez.

En la configuración agregamos un nuevo setting llamado ConnectionName y le asignamos el mismo nombre que usamos en la configuración de los "OAuth Settings", en mi caso azure-ad-juank.

Configuración de la solución en Visual Studio

Como lo mencionamos al inicio, con el ánimo de enfocarnos en la configuración y no en el código, haremos uso de uno de los ejemplos del Bot Framework.

microsoft / BotBuilder-Samples

Welcome to the Bot Framework samples repository. Here you will find task-focused samples in C#, JavaScript/TypeScript, and Python to help you get started with the Bot Framework SDK!
Usaremos cualquiera de los relacionados con autenticación en el repositorio, las configuraciones que aquí realice aplican para cualquier framework y lenguaje con las variantes normales que correspondan a cada uno.
En ese caso usaré un ejemplo de C# net Core que se encuentra en "samples/csharp_dotnetcore/", llamado "18.bot-authentication".

Te recomiendo que clones el repositorio y que trabajes luego solo en este proyecto de ejemplo de tal forma que en cada compilación no tardes tanto como si tuvieras los más de 45 ejemplos cargados.
Abrimos el archivo de configuración de la solución, el cual en el caso de C# es appsettings.json allí encontraremos los mismos settings que dejamos configurados en el Web App Bot, para poder probar el bot en el entorno local debemos tener lo settings locales.
```
{
"MicrosoftAppId": "da2e26d8-a9c9-442a-8831-c972fe6f281a",
"MicrosoftAppPassword": "j32e5fbN@lk[Su0oZXmLFnazaPgt@uv_",
"ConnectionName": "azure-ad-juank"
}
```

Eso es todo , el ejemplo va a funcionar.
Si te preguntas cual es el propósito del setting ConnectionName les el siguiente párrafo.

TL;DR

Para que el bot pueda mostrar una ventana de login al usuario se requiere que te comuniques con las API de Auth de Azure AD y con el Auth setting que configuraste en el servicio Web App Bot. Y llevar el control de todo el flujo de autenticación por tu cuenta.

Hacer todo este trabajo manualmente no es imposible, pero si dispendioso, así que existe forma de crear una Adaptive Card para autenticación por OAuth, pero si quieres solucionarlo de manera aún más fácil el SDK de bot Framework, en este caso el SDK para net core, incluye un OAuthPrompt que internamente -adivino- hace uso de un Adaptive Card y se encarga de toda la lógica del flujo de autenticación.

Pues bien para que el OAuthPrompt funcione requiere información relacionada con nuestro Azure AD y nuestra aplicación...

Claro! el MicrosoftAppId y MicrosoftAppPassword son dos de esos datos, pero y todo lo demás?
El tenant Id, los permisos requeridos, las URL de autenticación, las de token, las URL autorizadas en el Azure AD etc, ¿Dónde están?.

Bueno esos datos los hemos dejado (y otros son resueltos) por el Web App Bot en el Auth Setting (en mi caso azure-ad-juank).

Así que por ello en ConnectionName hemos dejado el valor del Auth Setting del Web App Bot.

Dentro de la solución encontramos donde se hace la configuración del AuthPrompt aquí. Dialogs/MAinDialog.cs

public MainDialog(IConfiguration configuration, ILogger<MainDialog> logger)
    : base(nameof(MainDialog), configuration["ConnectionName"])
{
    Logger = logger;

    AddDialog(new OAuthPrompt(
        nameof(OAuthPrompt),
        new OAuthPromptSettings
        {
            ConnectionName = ConnectionName,
            Text = "Please Sign In",
            Title = "Sign In",
            Timeout = 300000, // User has 5 minutes to login (1000 * 60 * 5)
        }));

Puedes ver claramente como extrae el nombre de la configuración y luego lo pasa al OAuthPromptSettings.

Dónde se muestra el OAuthPrompt? Más abajo justo en este método.

private async Task<DialogTurnResult> PromptStepAsync(WaterfallStepContext stepContext, CancellationToken cancellationToken)
{
    return await stepContext.BeginDialogAsync(nameof(OAuthPrompt), null, cancellationToken);
}

ngrok

Ngrok es un proxy que permite que el bot en tu emulador se comporte como si estuviera corriendo desde azure, permitiendo que si es necesario use todos los servicios de azure Bot disponibles en el backend.

⚠⚠⚠ Debes hacer esto ❗❗❗
No entraré en detalles de como descargarlo y configurarlo, pero los encuentras aquí en detalles al respecto

Configuración del emulador

Si ejecutamos la aplicación recién configurada desde Visual Studio o desde el kit de herramientas del Bot Framework tenemos esto.

El Bot ya está corriendo, ahora debemos conectarnos con emulador y con ngrok.

En la configuración del emulador en este ícono parte inferior izquierda ⚙ , encuentras la siguientes opciones de autenticación, ambas son soportadas, sin embargo para efectos de la prueba te recomiendo marcar solo la primera.
Cuando se configure la conexión con el bot es ⚠ IMPORTANTE configurar el MicrosoftAppId y MicrosoftAppPassword

Prueba de Autenticación con Azure AD

Teniendo la instancia del bot corriendo desde Visual Studio, realizamos la conexión con el emulador. Si recibes este mensaje entonces todo va bien, sino entonces debes revisar nuevamente los MicrosoftAppId y MicrosoftAppPassword en
- la configuración de la conexión en el emulador
- en la solución
- en el Bot Web App
- en el Azure AD
El bot está diseñado para pedir autenticación con cualquier texto que ingreses, con excepción de que ingreses logout ¯\_(ツ)_/¯ . Así que ingresa cualquier texto como prueba, en este caso ingresé 123. Veras que el bot despliega el OAuthPromt pidiendo login. Damos click al botón.
Al darle click al enlace el emulador pedirá confirmación. Acéptala.
Una vez inicies sesión notarás que no te pide autorizar permisos ya que lo hemos hecho en alguna de las opciones ofrecidas anteriormente. Si iniciaste sesión exitosamente recibirás estos mensajes, dile que sí para que te muestre el token de usuario.

Eso es todo! hemos conectado un Bot de Microsoft Bot Framework con Azure Active Directory para realizar la autenticación.

C# - la palabra clave volatile

Juan Carlos Ruiz Pacheco — Mon, 02 Dec 2019 05:59:38 +0000

La palabra clave volatile es una de esas palabras clave muy pocas veces comprendidas, la documentación permite concluir que hay que utilizarla siempre que se manejen hilos, pero esto no siempre es así.

Sin embargo lograr identificar que es lo que hace realmente esta palabra clave es una labor complicada así que dedicaré este artículo a explorar esta funcionalidad y a crear un ejemplo práctico que permita entender su verdadera naturaleza.

La documentación

En docs encontramos la siguiente definición de la palabra clave volatile:

La palabra clave volatile indica que varios subprocesos que se ejecutan a la vez pueden modificar un campo. Los campos que se declaran como volatile no están sujetos a optimizaciones del compilador que suponen el acceso por un subproceso único. Esto garantiza que el valor más actualizado está en todo momento presente en el campo

Revisa acá la referencia completa

Debemos resaltar dos aspectos importantes de ese texto:

Se menciona que los campos volatile no son susceptibles de optimizaciones por parte del compilador. Cuales optimizaciones?
Dice que esto garantiza que el valor más actualizado siempre esta presente en el campo. No se supone que esto es así siempre?

A continuación revisaremos estas dos preguntas.

Optimizaciones del compilador

Siempre que compilamos un programa hecho con C# el compilador se encarga de convertir ese código C# en código de lenguaje IL, bueno realmente en OpCodes de IL.

Esto es así de sencillo, pero resulta que cuando compilamos nuestro código en la configuración release o más específicamente cuando se marca la casilla de Optimizar código en el proyecto (ver imagen) el compilador realiza una revisión general del código par determinar que cosas puede hacer funcionar de una manera mejor a la que codificó el programador inicialmente, o incluso como puede cambiar cosas en el ejecutable que no están en manos del programador ni del propio lenguaje para que el programa sea más eficiente.

Usando la línea de comandos podemos también adicionar optimize en los modificadores del compilador.

Ejemplo

csc t2.cs -optimize

Estas optimizaciones son calculadas por el compilador haciendo uso de un complejo juego de reglas algunas de las cuales dependen de la arquitectura del procesador ( x86, x64, IA64, etc) y algunas otras del modelo de memoria que se esta trabajando.

Los modelos de memoria son un tema complejo incluso desde sus fundamentos si bien no es algo imposible de aprender, pero quien quiera puede profundizar un poco más al respecto puede leer el libro de Sistemas Operativos Modernos de Andrew Tanembaum y desde luego buscar referencias adicionales en internet.

Adicionalmente a las optimizaciones realizadas por el compilador de C# tenemos una segunda etapa de compilación y optimizaciones realizadas por el JIT al momento de ejecutarse el programa, las cuales tiene su propio conjunto de reglas algunas de las cuales también están influenciadas por la arquitectura del procesador y el modelo de memoria.

El Valor Actualizado

Parte de las optimizaciones realizadas por el compilador pueden evitar que en algún momento determinado los campos de memoria donde se encuentran las variables no sean actualizados con su valor más reciente, porque?

Cada vez que el procesador hace una operación necesita colocar el valor de las variables en uno de sus registros, de tal forma que si tenemos por ejemplo un bucle con una suma de esta manera:

int i = 0;
while (condicion)
{
    i = i + 1;
}

El procesador enviaría el valor de i a uno de sus registros y el valor 1 en otro registro, al obtener el valor de la suma el procesador debe colocar este valor de nuevo en memoria en la variable i de tal forma que al continuar el bucle todo el proceso se repite.

Esta secuencia sin embargo puede ser optimizada por el compilador ya que se hace innecesario que el valor de i sea copiado de los registros de la CPU a la memoria y viceversa tantas veces como dure el bucle, así que el compilador genera un código ejecutable que permite que los cálculos sean hechos en su totalidad en los registros de la CPU y solo hasta salir del bucle estos datos serian copiados de nuevo a la memoria.

Este tipo de optimizaciones que usan cache trae una mejora considerable en la ejecución de procesos intensivos a nivel matemático y funcionan bastante bien en la mayoría de los escenarios.

Optimizaciones de cache y el problema de los hilos

Cuando el compilador esta realizando las optimizaciones analiza todo lo que pueda hacer referencia a las variables en el contexto del subproceso (hilo) actual.

Realmente en la mayoría de sistemas operativos no se ejecutan los procesos sino los subprocesos y se le llama proceso a un grupo de subprocesos que comparten la memoria.

Con base en lo analizado realiza las optimizaciones, por ello el problema surge cuando un hilo ("nuevo") trata de acceder al valor de una variable que esta siendo modificada en un hilo ("inicial") diferente.

Es posible que el hilo "inicial" se encuentre en medio de una rutina optimizada para funcionar por cache (en los registros de la CPU) y al no estar copiando el valor de la variable de nuevo en memoria tras cada operación, el hilo "nuevo" no verá los cambios realizados.

Así que en escenarios donde existan múltiples hilos lo ideal es bloquear este tipo de optimizaciones y estar muy atento a los casos donde no sea conveniente inactivarlas pues hay casos para todo.

Código de ejemplo

Bien después de la teoría vamos a la práctica, veremos ejemplos donde

volatile no sirve para nada y creo que son la mayoría de casos en el mundo real – al menos en CPUs x86 ya que en IA64 al parecer el tema es muy diferente)
casos que de acuerdo a la teoría que acabamos de ver funciona perfectamente desde que lo compiles en modo Release y para x86.

Ejemplo 1

Este es el ejemplo típico, donde todos usamos volatile porque así lo dice la documentación pero la realidad es que en estos casos no sirve de NADA.

using System.Threading;
using System;

static class BackgroundTaskDemo
{
    //volatile
    static int i = 0;
    private static bool stopping = false;

    static void Main ()
    {
        new Thread(EfectuarTrabajo).Start();
        Thread.Sleep(5000);
        stopping = true;


        Console.WriteLine("Main exit");
        Console.ReadLine();
    }

    static void EfectuarTrabajo()
    {
        i++;
        Console.WriteLine("Valor de i="+i);
        Console.WriteLine("EfectuarTrabajo exit " + i);
    }
}

Podríamos poner a i como volatile pero no habría diferencia puesto que básicamente el código no necesita ni tiene como ser optimizado. Así que volatile no bloquearía ninguna optimización.

Ejemplo 2

Este es el ejemplo tampoco sirve de NADA, si bien en el bucle se ve la necesidad de optimizar el rendimiento del código evitando que se copie el valor de i o de stopping de los registros de la CPU a la memoria y viceversa.

Resulta que al convertir i a string estamos forzando al compilador a que no utilice el cache dado que necesita el valor mas reciente de i en la memoria para poder llamar el método ToString() y al método WriteLine().
Adicionalmente al llamar a alguno de esos métodos se requiere colocar en los registros de la CPU los valores necesarios para cambiar de contexto y para poder ejecutar las operaciones internas de dichos métodos, así que no hay manera de optimizar nada.

using System.Threading;
using System;

static class BackgroundTaskDemo
{
    //volatile
    private static bool stopping = false;

    static void Main ()
    {
        new Thread(EfectuarTrabajo).Start();
        Thread.Sleep(5000);
        stopping = true;


        Console.WriteLine("Main exit");
        Console.ReadLine();
    }

    static void EfectuarTrabajo()
    {
        int i = 0;

        while (!stopping)
        {
            i++;
            Console.WriteLine("Valor de i=" + i.ToString());
        }
        Console.WriteLine("EfectuarTrabajo exit " + i);
    }
}

Nuevamente podríamos ponerle a i como volatile pero no habría diferencia puesto que básicamente el código no necesita ni tiene como ser optimizado. Así que volatile no bloquearía ninguna optimización.

Ejemplo 3

En este si que funcionan las optimizaciones! pero el programa no funcionará ya que ambas variables caen en la optimización.

El compilador optimizara el uso de i para que se apoye en los registros del procesador de principio a fin, eso es perfecto!.

Pero por otro lado la variable stopping también es optimizada, trayendo como resultado que siempre este en uno de los registros y por tanto los hilos nunca se enteren en que momento stopping cambio de valor para que saliera del bucle.


static class BackgroundTaskDemo
{
    private static bool stopping = false;

    static void Main ()
    {
        new Thread(EfectuarTrabajo).Start();
        Thread.Sleep(5000);
        stopping = true;


        Console.WriteLine("Main exit");
        Console.ReadLine();
    }

    static void EfectuarTrabajo()
    {
        int i = 0;
        Console.WriteLine("Valor de i=" + i.ToString());
        while (!stopping)
        {
            i++;
        }
        Console.WriteLine("Valor de i=" + i.ToString());
        Console.WriteLine("EfectuarTrabajo exit ");
    }
}

Al ejecutar la version release para x86 de este programa veremos como, aunque en código parece que todo saldrá bien, al ejecutarse el programa este nunca terminara pues el hilo nunca se entera que stopping cambió su valor. En pantalla veríamos perpetuamente:

Main Exit

Y nada más :(.

Ejemplo 4

Dado que el ejemplo anterior nos muestra como se activan las optimizaciones de código del compilador, es tiempo de evitarlas haciendo uso de volatile.


static class BackgroundTaskDemo
{
    private volatile static bool stopping = false;

    static void Main ()
    {
        new Thread(EfectuarTrabajo).Start();
        Thread.Sleep(5000);
        stopping = true;


        Console.WriteLine("Main exit");
        Console.ReadLine();
    }

    static void EfectuarTrabajo()
    {
        int i = 0;
        Console.WriteLine("Valor de i=" + i.ToString());
        while (!stopping)
        {
            i++;
        }
        Console.WriteLine("Valor de i=" + i.ToString());
        Console.WriteLine("EfectuarTrabajo exit ");
    }
}

Ahora si en pantalla veremos el resultado esperado

Main Exit
EfectuarTrabajo exit

Ejemplo 5

Este es el mismo ejemplo anterior pero un poco mas elaborado haciendo uso de algunas operaciones de System.Math las cuales son suceptibles de optimización por el compilador.



using System.Threading;
using System;

static class BackgroundTaskDemo
{
    //volatile
    private  static bool stopping = false;

    static void Main ()
    {
        new Thread(EfectuarTrabajo).Start();
        Thread.Sleep(5000);
        stopping = true;


        Console.WriteLine("Main exit");
        Console.ReadLine();
    }

    static void EfectuarTrabajo()
    {
        int i = 0;
        int j = 2;

        while (!stopping)
        {
            i++;
            j = 100 + (int)Math.Sin((double)i * 10d);
        }
        Console.WriteLine("EfectuarTrabajo exit " + i);
    }
}

Prueba quitando y poniendo volatile y verás la diferencia claramente.

HAS PRUEBAS Y COMPARTE TUS EJEMPLOS

Hasta la próxima!.