Hablemos sobre .Net y Azure

Mes: mayo 2021

Evitar usuarios de redes sociales duplicados en Azure AD B2C (Propuesta)

Azure AD B2C es un excelente servicio para el manejo de inicio de sesión y registro de usuarios que además ofrece integración con redes sociales.

Uno de los aspectos negativos es que no ofrece ningún tipo de mecanismo para unificar usuarios, o al menos para prevenir su duplicación, cuando el email es el mismo.

En este post analizaremos en detalle que herramientas Azure AD B2C nos provee y crearemos una propuesta de arquitectura para detectar usuarios duplicados. En los próximos artículos completaremos la implementación.

Contexto

Dentro de Azure AD B2C existe el concepto de Proveedor de Identidad, el cuál representa el servicio dueño de la identidad virtual de los usuarios.

Ejemplos de proveedores de identidad pueden ser Google o GitHub, los cuáles son externos, ya que son ellos los responsables por la información de los usuarios.

Pero también tenemos la opción de utilizar email y contraseña y que Azure AD B2C se encargue de la identidad. Este proveedor se denomina Local.

Caso de uso

Un usuario opta por registrarse mediante el proveedor local (con email y contraseña) con el email usuario@gmail.com.

Sin embargo, más tarde inicia sesión con GitHub utilizando el mismo email. Es bastante frecuente que el usuario olvide el primer inicio de sesión.

Si bien se utilizaron dos proveedores de identidad diferentes (Local y GitHub), la identidad de usuario es la misma.

Azure AD B2C no ofrece un mecanismo para detectar estos casos, lo que deriva en la creacion de dos perfiles de usuarios diferentes.

Solución

Azure AD B2C crea una identidad de usuario para cada usuario nuevo que se registra, independientemente de qué proveedor se haya utilizado.

Tabla comparativa usuario Local y GitHub
Tabla comparativa usuario Local y GitHub

La solución “ideal” sería unificar las identidades en los casos donde el email es el mismo, sin embargo eso implica escribir “Políticas personalizadas” y es mucho más complejo (Escribiré una serie de posts dedicados exclusivamente a esto).

Una solución parcial, pero eficaz y eficiente, consiste el prevenir la creación de un usuario si ya existe un usuario con el mismo email (sea de un proveedor externo como local).

Conectores de API

Los Conectores de API es una forma de integrar nuestro flujo de usuario con REST APIs para poder realizar validaciones o ejecutar reglas de negocio antes de la creación de un usuario.

Los conectores pueden ser llamados en dos momentos específicos:

  • Después de haber iniciado sesión con un proveedor de identidad externo. Este conector se ejecuta solo para inicios de sesión con proveedores externos y antes de completar el formulario con los atributos de usuario.
  • Antes de crear el usuario. Este conector se ejecuta después de completar el formulario de atributos de usuario y antes de la creación del usuario.
Diagrama de flujo de conectores
Diagrama de flujo de conectores

Los Conectores de API son invocados únicamente durante el registro de un usuario, ya sea con un proveedor externo o local, y no durante el inicio de sesión.

Microsoft Graph API

El equipo de Microsoft ha creado una REST API estándar llamada Graph API la cuál nos va a permitir interactuar con Azure AD B2C.

Una de las caracteristicas que nos interesa es la de poder consultar la base de datos de usuarios de Azure AD B2C.

Propuesta

Hasta el momento tenemos los Conectores de API para ejecutar REST APIs y Microsoft Graph API para obtener información de la base de datos de usuarios.

Nos falta una pieza fundamental para completar la solución: una REST API que sea ejecutada por un Conector e interactúe con Graph API.

Para esto vamos a utilizar Azure Functions. No sólo es muy fácil de integrar y económico, sino también simple de utilizar. Al ser un servicio serverless, no tenemos que preocuparnos por la infraestructura, sino solo de nuestro código.

Propuesta de arquitectura

Nuestra API recibirá como parte de la petición el email con el que se está iniciando sesión y validará contra Microsoft Graph API si ya existe un usuario con ese mismo email en nuestro tenant de Azure AD B2C. En caso de existir devolverá un código de estado de error (400 – Bad Request), caso contrario un código de estado de éxito (200 – Ok).

El Conector de API leerá el código de estado devuelto y continuará con el flujo d ejecución si el código es exitoso, o detendrá el flujo y mostrará al usuario un error si el código no es exitoso.

Próximos Pasos

Ya con la propuesta en pie, estamos en condiciones de comenzar a crear los componentes necesarios para la implementación de la solución.

No te pierdas el próximo post donde vamos a comenzar a crear los Conectores de API junto con una Azure Function base que nos va a permitir entender la propuesta.

Código más testeable con ISystemClock

Te propongo examinar juntos el siguiente fragmento de código:

public class BirthDayCalculator
{
    public int CalculateNextBirthDayInDays(
        int month,
        int day)
    {
        var today = DateTime.UtcNow;
        var birthDay = new DateTime(today.Year, month, day);

        if (birthDay < today)
            birthDay = birthDay.AddYears(1);

        return (int)(birthDay -  today).TotalDays;
    }
}

A primera vista se ve bien, dados un mes y un día, el método CalculateNextBirthDayInDays() calcula y retorna la cantidad de días restantes para el próximo cumpleaños.

Sin embargo, algo no huele del todo bien. Ese método no soporta test unitarios.

Problema

Dos de los requesitos estrictamente necesarios de un test unitario, es que debe tener absoluto control del contexto de ejecución y debe ser repetible.

La solución que vimos en la sección anterior, funciona, pero depende de la propiedad estática DateTime.UtcNow. Debido a que no podemos controlar los valores que dicha propiedad puede tomar, no tenemos forma de escribir casos de prueba controlados y repetibles.

Alternativa poco elegante

Una alternativa simple al problema planteado es que el método CalculateNextBirthDayInDays() reciba un parámetro adicional representando la fecha y hora actual. Algo más o menos así:

public class BirthDayCalculator
{
    public int CalculateNextBirthDayInDays(
        int month,
        int day,
        DateTime today)
    {
        var birthDay = new DateTime(today.Year, month, day);

        if (birthDay < today)
            birthDay = birthDay.AddYears(1);

        return (int)(birthDay -  today).TotalDays;
    }
}

Esta modificación, poco elegante pero efectiva, nos permite escribir pruebas como la siguiente:

[Fact]
public void CalculateNumberOfDays()
{
    // Arrange
    var sut = new BirthDayCalculator();

    // Act
    var actualDays = sut.CalculateNextBirthDayInDays(
        month: 3,
        day: 13, 
        today: DateTime.UtcNow);

    // Assert
    Assert.Equal(290, actualDays);
}

Esta implementación tiene los siguientes puntos en contra:

  • No tenemos una forma común o servicio para obtener la fecha actual en forma testeable y centralizada, generando casi con seguridad código repetido.
  • Cada vez que es necesario realizar cálculos con fechas, necesitamos agregar un parámetro adicional. Incluso en aquellos casos donde se haga uso de del método CalculateNextBirthDayInDays().
public int ConsumingCode(DateTime today)
{
    int month = 3, day = 13;
    var calculator = new BirthDayCalculator();

    return calculator.CalculateNextBirthDayInDays(
        month,
        day,
        today);
}

ISystemClock al rescate

El equipo de Microsoft ha creado una bonita interfaz junto con una implementación estándar que se encuentra disponible en el paquete Microsoft.AspNetCore.Authentication llamada ISystemClock y SystemClock respectivamente.

Esta interfaz nos permite solucionar los dos puntos anteriores. Por un lado, no necesitamos agregar parámetros extras a todos los métodos, por el otro, nos permite utilizar inyección de dependencias para centralizar una única implementación.

namespace Microsoft.AspNetCore.Authentication
{
    public interface ISystemClock
    {
        DateTimeOffset UtcNow { get; }
    }
}

¿Cómo la usamos?

Vamos a modificar la clase BirthDayCalculator para recibir por parámetro en el constructor mediante inyección de dependencias la interfaz ISystemClock.

Luego simplemente reemplazamos la llamada a DateTime.UtcNow por _systemClock.UtcNow.

public class BirthDayCalculator
{
    private readonly ISystemClock _systemClock;

    public BirthDayCalculator(ISystemClock systemClock)
    {
        _systemClock = systemClock;
    }

    public int CalculateNextBirthDayInDays(
        int month,
        int day)
    {
        var today = _systemClock.UtcNow;
        var birthDay = new DateTime(today.Year, month, day);

        if (birthDay < today)
            birthDay = birthDay.AddYears(1);

        return (int)(birthDay - today).TotalDays;
    }
}

¿Cómo lo testeamos?

Primero generaremos una clase fake, la cuál llamaremos FakeSystemClock, que implemente la interfaz y que reciba mediante un parámetro en el constructor la fecha y hora a retornar.

public class FakeSystemClock : ISystemClock
{
    private readonly DateTime _desiredDay;

    public FakeSystemClock(DateTime desiredDay)
    {
        _desiredDay = desiredDay;
    }

    public DateTimeOffset UtcNow => _desiredDay;
}

Finalmente, modificamos el test para generar una nueva instancia de FakeSystemClock y pasamos esa instancia a nuestro BirthDayCalculator.

[Fact]
public void CalculateNumberOfDays()
{
    // Arrange
    var desiredDay = new DateTime(2021, 5, 26, 10, 0, 0);
    var fakeSystemClock = new FakeSystemClock(desiredDay);
    var sut = new BirthDayCalculator(fakeSystemClock);

    // Act
    var actualDays = sut.CalculateNextBirthDayInDays(
        month: 3,
        day: 13);

    // Assert
    Assert.Equal(290, actualDays);
}

Si estuviésemos utilizando librerías como Moq o FakeItEasy, no necesitaríamos crear esta clase fake.

ISystemClock en Asp.Net Core

Si estamos en el contexto de aplicaciones Asp.Net Core, podemos utilizar la implementación estándar provista como parte del paquete.

Sólo necesitamos registrarla en nuestro contenedor IoC.

public void ConfigureServices(IServiceCollection services)
{
    services.AddScoped<ISystemClock, SystemClock>();

    // More services
    services.AddControllers();
}

Conclusión

De una forma muy simple y con poco refactoring, podemos eliminar las dependencias a DateTime.UtcNow y hacer nuestro código testeable gracias a ISystemClock.

Podrás encontrar el código completo de ejemplo en mi GitHub.

Azure Days 2021: Azure Web PubSub

Durante los días 21 y 22 de Mayo, se llevó a cabo de forma online el Azure Days 2021 de la mano de ConoSur.Tech.

Es un evento totalmente gratuito y en español donde diversos referentes y expertos de la comunidad ofrecen charlas sobre distintas tecnologías y servicios en Azure.

Este año tuve el enorme placer y honor de participar como speaker dando una charla de un nuevo servicio que promete revolucionar la forma en la que utilizamos WebSockets: Azure Web PubSub.

Estuve hablando sobre todas las funcionalidades y características que nos ofrece este excelente servicio. Además, mostré una pequeña demo de como funciona el servicio y como se integra fácilmente con Azure Functions.

Azure Days 2021 – Azure Web PubSub

Y como un pequeño extra, les dejo la entrevista que me hizo la genia de Ivana Tilca.

Azure Days 2021 – Entrevista

Podrán encontrar el repositorio de la demo con todo el código de los ejemplos aquí.

Manejo de excepciones sin excepciones con .NET 5

Uno de los aspectos más importantes en el desarrollo de aplicaciones es el manejo de excepciones. Esto es verdadero independientemente del tipo de aplicación o plataforma.

Es habitual que incluso diseñemos reglas de negocio en forma de excepciones, por ejemplo para validar parámetros de entrada o ejecutar acciones no permitidas sobre algunas entidades de dominio.

Algo negativo o falla de diseño que tiene esta forma de manejar excepciones es que no es para nada declarativa. C# no provée ningún mecanismo para hacer explícito qué excepciones puede arrojar un método.

En esta sesión veremos una alternativa para solucionar esa falla de diseño apoyándonos en una excelente librería llamada OneOf.

Manejo de excepciones sin excepciones

Como siempre, podrán encontrar el código completo de todos los ejemplos en mi GitHub.

Personalización de vistas en Azure AD B2C

Azure AD B2C es un servicio brillante que nos permite generar flujos para inicio de sesión, registro, recupero de contraseña, etc., en forma muy simple y rápida sin necesidad de escribir código.

Sin embargo, en ocasiones es necesario implementar nuestra propia hoja de estilos de forma que los usuarios tengan una experiencia totalmente integrada.

En este artículo veremos como personalizar nuestras vistas aplicando hojas de estilos propias.

Contexto

Cuándo desarrollamos aplicaciones web, uno de los factores determinantes para el éxito o el fracaso de nuestra aplicación es la experiencia de usuario o UX.

Un estilo o diseño consistente favorece la experiencia de usuario haciendo la utilización más intuitiva y una navegación más fluida.

Si bien Azure AD B2C ofrece flujos de usuario con vistas listas para usar y diseños estándares, puede que no sean consistentes con el resto de nuestra aplicació y necesitemos implementar nuestra propia hoja de estilos.

Requerimiento

Ya tenemos configurado nuestro flujo de usuario unificado para registro o inicio de sesión incluyendo algunos proveedores externos.

Inicio de sesión estándar
Inicio de sesión estándar

Ahora necesitamos que la lista de proveedores externos se muestre primero, es decir, antes de la opción con Email y Contraseña.

Para lograr implementar este requerimiento es necesario realizar algunas modificaciones al código css.

¿Cómo funciona?

Cada flujo de usuario está compuesto por una serie de vistas. A su vez, cada vista tiene asociado un archivo de estilos particular.

Desde el panel del flujo de usuario, navegaremos a la sección Diseños de Página para acceder a la lista de vistas que componen el flujo actual.

Lista de diseños de páginas
Lista de diseños de páginas

Como podemos apreciar en la imagen anterior, cada diseño de página tiene la opción de utilizar contenido personalizado, y en el caso de activar esta opción podremos indicar la URI de la página personalizada.

Página personalizada

Para poder utilizar nuestra página personalizada podemos usar un archivo *.html estático, o también páginas dinámicas como .NET, NodeJS o PHP.

El código HTML puede contener cualquier elemento, el único requerimiento es un elemento div con id igual a "api", como en el siguiente ejemplo:

<!DOCTYPE html>
<html>
<head>
</head>
<body>
    <div id="api"></div>
</body>
</html>

Azure AD B2C agregará todos los elementos necesarios dentro del div mencionado anteriormente.

Dentro de este HTML podemos incluir referencias a archivos *.css o *.js, el único requerimiento es que estos archivos sean accesibles públicamente mediante HTTPS.

Plantillas predefinidas

Si bien tenemos la opción de utilizar HTML totalmente personalizado, Azure AD B2C nos ofrece plantillas completas que podemos utilizar como base.

Sobre estas plantillas base haremos nuestros cambios. Esto hace mucho más simple la personalización.

Podemos descargar las platillas base desde aquí.

Hosting

Las plantillas personalizadas que crearemos deben poder ser accedidas en forma pública mediante una petición GET HTTPS.

Podemos utilizar cualquier tipo de servicio a tal fin, como Azure Web Apps, Azure Functions, una aplicación web Node.js, etc.

Para este ejemplo utilizaremos un archivo *.html estático almacenado en un blob de Azure Storage.

Queda fuera del alcance de este artículo la configuración de Azure Storage. Puedes visitar la documentación oficial para encontrar instrucciones paso a paso al respecto.

Prueba inicial

Para entender cómo funcionan las plantillas personalizadas comenzaremos haciendo una prueba muy simple. Crearemos un archivo llamado index.html cuyo único contenido será un Título de página.

Este archivo no contendrá ningún estilo css ni ningún otro elemento html, solo el div con id "api" y un elemento title:

<!DOCTYPE html>
<html>
<head>
    <title>Prueba inicial</title>
</head>
<body>
    <div id="api"></div>
</body>
</html>

Debemos subir este archivo a Azure Storage y asegurarnos que es de público acceso. Al finalizar, tomar nota de la URI de acceso.

Finalmente, actualizaremos el diseño de página para utilizar como plantilla personalizada la URI que copiamos en el paso anterior.

Luego de guardar los cambios y ejecutar el flujo de usuario, deberíamos obtener el siguiente resultado:

Inicio de sesión sin estilo
Inicio de sesión sin estilo

Implementación del requerimiento

Para poder implementar el requerimiento, vamos a partir de la plantilla por defecto que Azure AD B2C utiliza. Podemos obtener este diseño desde la misma vista donde configuramos la vista personalizada.

Una vez descargada la plantilla, podemos hacer las modificaciones que necesitamos sobre la misma en función de nuestras necesidades.

Para implementar satisfactoriamente nuestro requerimiento, necesitamos alterar el estilo del elemento div con id "api" de forma que ordene los elementos interiores de forma inversa, para eso combinaremos las propiedades display: flex y flex-direction: column-reverse.

Agregaremos un atributo style al elemento con el valor "flex-direction: column-reverse; display: flex;" como se muestra a continuación:

<html>
<head>
  <title>Sign up or sign in</title>

  <meta charset="utf-8">
  <meta http-equiv="X-UA-Compatible" content="IE=edge">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <link href="https://ajax.aspnetcdn.com/ajax/bootstrap/3.3.5/css/bootstrap.min.css" rel="stylesheet" type="text/css">
  <style id="common">...</style>
  <style id="idpselector">...</style>
  <style>...</style>
  <style>...</style>
  <script type="text/javascript" src="chrome-extension://lbdfknhegglkmkgffjecdpodddfnibpb/inject.js"></script>
</head>
<body data-new-gr-c-s-check-loaded="14.1010.0" data-gr-ext-installed="">
  <div id="background_branding_container" data-tenant-branding-background-color="true">
    <img data-tenant-branding-background="true" ...>
  </div>
  <div class="container  unified_container " role="presentation">
      <div class="row">
          <div class="col-lg-6">
              <div class="panel panel-default">
                  <div class="panel-body">
                      <img class="companyLogo" data-tenant-branding-logo="true" ...>
                      <div id="api" style="flex-direction: column-reverse;display: flex;">
                      </div>
                  </div>
              </div>
          </div>
      </div>
  </div>
  <div id="mfa_inject_cartdata" hidden="hidden"></div>
  <div id="mfa_inject" hidden="hidden"></div>
</body>
</html>

Una vez realizado el cambio en el archivo, lo subiremos a Azure Storage como hicimos anteriormente y guardamos la URI correspondiente.

Una vez guardados los cambios, ejecutaremos el flujo de usuario nuevamente. Esta vez la lista de proveedores externos aparecerá primero, antes de la opción Email y Contraseña.

Inicio de sesión con diseño modificado
Inicio de sesión con diseño modificado

El equipo de desarrolladores de Azure AD B2C puede ir cambiando el html por defecto con el tiempo, en todos los casos donde se requieran personalizaciones como esta, es recomendable analizar cuidadosamente y familiarizarse con la hoja de estilos provista.

Consideraciones

En este ejemplo partimos de una plantilla base e hicimos cambios casi triviales para satisfascer el requerimiento. Sin embargo en ocasiones los cambios serán mucho más complejos.

Cabe destacar que además de poder incluir elementos html adicionales y estilos css, también podemos incluir código JavaScript, ya sea embebido o referenciando archivos externos.

JavaScript

Para poder incluir código JavaScript, ya sea mediante código embebido o archivos externos, necesitamos habilitar su uso desde la sección Propiedades del flujo de usuario.

Habilitar JavaScript
Habilitar JavaScript

Por cuestiones de seguridad, Azure AD B2C tiene ciertas restricciones en cuánto a JavaScript que pueden ir variando con el tiempo. Es recomendable leer atentamente la documentación oficial.

iframes

Los elementos del tipo iframe son considerados inseguros, razón por la cuál no son soportados por Azure AD B2C.

Conclusión

Azure AD B2C nos ofrece la posibilidad de tener un control total sobre la hoja de estilos de cada una de las vistas.

Gracias a este control y la posibilidad de incluir nuestro propio código css, html y js, podremos crear experiencias de usuario totalmente consistentes con el resto de nuestra aplicación.

Integrando Web MVC + Web API .Net 5 con Azure AD B2C

Cuándo trabajamos en ambientes de microservicios, o al menos con distintas APIs, que están protegidos utilizando Azure AD B2C, es necesario que el Front End pueda interactuar con las APIs.

Hoy veremos los pasos necesarios para integrar los tres componentes y tener así nuestro ecosistema de servicios integrados y protegidos con Azure AD B2C.

IMPORTANTE: para poder implementar los pasos aquí mencionados es necesario contar con una configuración básica en Azure AD B2C. Podrás encontrarlos en el siguiente paso a paso.

Antes de Comenzar

En este tutorial vamos a utilizar .Net 5 como marco o framework de desarrollo, con lo cual es un requisito excluyente tener instalado .Net 5 SDK. Si aún no lo tienes, lo puedes descargar aquí, también encontrarás un instructivo paso a paso en caso de que tengas dudas.

Por otro lado, vamos a utilizar Visual Studio 2019 Community Edition, sin embargo este no es un requerimiento excluyente ya que podemos utilizar cualquier editor de texto o ambiente de desarrollo como Visual Studio Code o Notepad++. Puedes descargar Visual Studio 2019 aquí.

Contexto

En los últimos años ha proliferado mucho el desarrollo de aplicaciones compuestas por módulos o APIs independientes del Front End, favoreciendo así la escalabilidad y adaptabilidad a los cambios.

Por supuesto que esto genera un nuevo desafío: Integrar Front Ends y APIs de forma fácil y simple.

Requerimiento

Por un lado tenemos una aplicación Web MVC .Net 5 integrada con Azure AD B2C, por el otro lado tenemos una aplicación Web API .Net 5 que sólo acepta peticiones de usuarios que hayan sido autenticados por Azure AD B2C.

Necesitamos realizar los cambios necesarios para que nuestra aplicación MVC pueda comunicarse con nuestra API.

Solución

Nuestra API solo acepta peticiones de usuarios autenticados por Azure AD B2C, para esto utiliza JWT tokens. Estos tokens contienen la información suficiente para asegurar que se trata de un usuario legítimo.

La API espera recibir con cada petición una cabecera o header de autenticación incluyendo un JWT token emitido por Azure AD B2C.

La solución consiste en configurar los mecanismos necesarios para que la aplicación MVC pueda generar JWT tokens en nombre del usuario y así hacer las peticiones a la API en forma correcta.

Paso 1: Preparar la aplicación Web MVC

Lo primero que haremos es preparar nuestra aplicación Web MVC para mostrar los resultados obtenidos de la API, esto implica crear un Modelo de Vista o View Model, un Controlador y una Vista..

Modelo de Vista o View Model

Para poder mostrar el resultado obtenido de la API necesitamos un View Model, para lo cuál crearemos una nueva clase llamada WeatherForecastViewModel.cs bajo el directorio Models:

public class WeatherForecastViewModel
{
    public DateTime Date { get; set; }

    public int TemperatureC { get; set; }

    public int TemperatureF { get; set; }

    public string Summary { get; set; }
}

El View Model que acabamos de crear se corresponde a la plantilla que utiliza Visual Studio por defecto.

Controlador

Por el momento el controlador tendrá la tarea de comunicarse con la API y devolver los resultados a la vista. Los pasos son los siguientes:

  1. Hacer la petición a la API
  2. Leer y deserializar el resultado
  3. Devolver el resultado a la vista.

Crearemos un nuevo Controlador llamado WeatherController dentro del directorio Controllers. Este controlador tendrá una sola acción:

public class WeatherController : Controller
{
    private readonly HttpClient _httpClient;

    public WeatherController(HttpClient httpClient) =>
        _httpClient = httpClient;

    public async Task<IActionResult> Index()
    {
        var response = await _httpClient.GetAsync("https://localhost:5002/weatherforecast");
        var content = await response.Content.ReadAsStringAsync();
        var values = JsonConvert.DeserializeObject<IEnumerable<WeatherForecastViewModel>>(content);

        return View(values);
    }
}

Debido a que la API está protegida, este controlador todavía no va a funcionar. Modificaremos en los próximos pasos el controlador para poder realizar la interacción con la API en forma exitosa.

Además de incluir algunos usings que serán sugeridos por Visual Studio, es necesario instalar un paquete adicional para la deserialización: Newtonsoft.Json.

Vista

Para mostrar los resultados crearemos una nueva vista llamada Index.cshtml, pero antes debemos crear un nuevo directorio llamado Weather dentro del directorio Views.

Directorio de vistas
Directorio de vistas

El código de la vista estará compuesto simplemente por una tabla mostrando los resultados obtenidos en el controlador.

@model IEnumerable<WeatherForecastViewModel>
@{
    ViewData["Title"] = "Weather";
}

<h1>Weather</h1>
<table class="table">
    <thead>
        <tr>
            <th>@Html.DisplayNameFor(model => model.Date)</th>
            <th>@Html.DisplayNameFor(model => model.TemperatureC)</th>
            <th>@Html.DisplayNameFor(model => model.TemperatureF)</th>
            <th>@Html.DisplayNameFor(model => model.Summary)</th>
        </tr>
    </thead>
    <tbody>
        @foreach (var item in Model)
        {
            <tr>
                <td>@Html.DisplayFor(modelItem => item.Date)</td>
                <td>@Html.DisplayFor(modelItem => item.TemperatureC)</td>
                <td>@Html.DisplayFor(modelItem => item.TemperatureF)</td>
                <td>@Html.DisplayFor(modelItem => item.Summary)</td>
            </tr>
        }
    </tbody>
</table>

Como último paso debemos agregar un acceso directo a esta nueva vista en la cabecera general.

Para esto agregaremos uno nuevo elemento a la sección Header de la vista compartida llamada _Layout.cshtml que se encuentra dentro del directorio Views/Shared:

<ul class="navbar-nav flex-grow-1">
    <li class="nav-item">
        <a class="nav-link text-dark" asp-area="" asp-controller="Home" asp-action="Index">Home</a>
    </li>
    <li class="nav-item">
        <a class="nav-link text-dark" asp-area="" asp-controller="Home" asp-action="Privacy">Privacy</a>
    </li>
    <li class="nav-item">
        <a class="nav-link text-dark" asp-controller="Weather" asp-action="Index">Weather</a>
    </li>
</ul>
<partial name="_LoginPartial" />

En este punto ya tenemos la vista preparada, si ejecutamos el proyecto MVC deberíamos ver una nueva entrada en la cabecera. Sin embargo, si intentamos navegar hasta esta nueva vista, obtendremos un error.

Este error se debe a que todavía, nuestra aplicación no puede generar el token necesario para interactuar con la API.

Pantalla de bienvenida
Pantalla de bienvenida

Paso 2: Configuración en Azure AD B2C

Hasta el momento configuramos en nuestro tenant de Azure AD B2C un registro de aplicación para la aplicación MVC y otro registro de aplicación para la API.

Además, cuando registramos la API creamos un ámbito o scope llamado Lector que se ve asi:

https://linkedinazureadb2c.onmicrosoft.com/posts/Lector

Bien, ahora necesitamos configurar nuestra aplicación MVC en Azure AD B2C para que pueda solicitar JWT tokens incluyendo el scope de la API. Para esto necesitamos realizar lo siguiente:

  1. Generar un secreto de cliente o client secret
  2. Asignar permisos para utilizar el scope

Generar secreto de cliente

Para generar un secreto tenemos que ir al registro de aplicación correspondiente a la aplicación MVC, y luego en sección Certificados y secretos crear un nuevo secreto de cliente.

Certificados y secretos
Certificados y secretos

Sólo necesitamos darle una descripción, podemos dejar el campo Expiración en su valor por defecto que es de 6 meses. Una vez creado, podremos obtener el valor creado por Azure desde la de secretos utilizando el botón para copiar.

El valor del secreto solo se puede ver y/o copiar por única vez al momento de su creación. Es importante tomar nota del mismo o tendremos que crear uno nuevo.

Asignar permisos para utilizar el scope

Desde el registro de aplicación MVC iremos a la sección Permisos de API y agregaremos un nuevo permiso.

Agregar permiso de API
Agregar permiso de API

Luego navegamos a la pestaña Mis API y seleccionamos del listado la API que habíamos creado para proteger nuestra Web API .Net 5.

Finalmente seleccionamos el permiso Lector que creamos cuando creamos el scope y agregamos el permiso.

Como último paso para terminar de dar los permisos necesarios es conceder consentimiento de administrador. Desde la misma sección de Permisos de API veremos el nuevo permiso pero en estado No concedido.

Concedemos el permiso y terminamos. El icono pasara de naranja a verde como se muestra en la imagen con los otros permisos.

Conceder consentimiento de administrador
Conceder consentimiento de administrador

Paso 3: Configurar aplicación Web MVC

Habiendo realizado todas las configuraciones pertinentes en torno a Azure AD B2C, podemos proceder con la configuración de la aplicación MVC.

Comenzaremos agregando el secreto de cliente que configuramos en el paso anterior al archivo appsettings.json, dentro de la sección "AzureAdB2C".

"AzureAdB2C": {
  "Instance": "https://linkedinazureadb2c.b2clogin.com",
  "ClientId": "00000000-0000-0000-0000-000000000000",
  "Domain": "linkedinazureadb2c.onmicrosoft.com",
  "SignUpSignInPolicyId": "B2C_1_InicioSesionConRegistro",
  "ClientSecret": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}

Finalmente debemos configurar los servicios necesarios para poder generar los JWT tokens necesarios y así poder interactuar con la API.

Para esto, en el método ConfigureServices de la clase Startup.cs utilizaremos los métodos de extensión EnableTokenAcquisitionToCallDownstreamApi() indicando la lista de scopes habilitados y AddInMemoryTokenCaches().

public void ConfigureServices(IServiceCollection services)
{
    services.AddControllersWithViews()
        .AddMicrosoftIdentityUI();

    services.AddMicrosoftIdentityWebAppAuthentication(Configuration, "AzureAdB2C")
        .EnableTokenAcquisitionToCallDownstreamApi(new string[] { "https://linkedinazureadb2c.onmicrosoft.com/posts/Lector" })
        .AddInMemoryTokenCaches();

    services.AddRazorPages();
}

Paso 4: Generar JWT tokens

En el paso anterior configuramos los servicios necesarios para poder generar los JWT tokens que necesitamos incluir en las peticiones a nuestra API.

Uno de esos servicios es ITokenAcquisition, el cuál nos habilita una serie de métodos para obtener de forma muy sencilla distintos tipos de JWT tokens.

Comenzaremos recibiendo en el constructor del controlador mediante inyección de dependencias el servicio y guardándolo en una variable local. Tendremos que agregar la referencia a Microsoft.Identity.Web en la lista de usings.

private readonly HttpClient _httpClient;
private readonly ITokenAcquisition _tokenAcquisition;

public WeatherController(
    ITokenAcquisition tokenAcquisition,
    HttpClient httpClient)
{
    _httpClient = httpClient;
    _tokenAcquisition = tokenAcquisition;
}

Luego modificaremos la acción Index() del controlador. Utilizaremos el método GetAccessTokenForUserAsync() del servicio ITokenAcquisition para obtener un JWT token en nombre del usuario actual indicando la lista de scopes que queremos incluir.

Por último, solo necesitamos incluir el token como nuevo header de autenticación en la petición a la API.

public async Task<IActionResult> Index()
{
    var accessToken = await _tokenAcquisition.GetAccessTokenForUserAsync(new[] { "https://linkedinazureadb2c.onmicrosoft.com/posts/Lector" });
    _httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", accessToken);
    _httpClient.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));

    var response = await _httpClient.GetAsync("https://localhost:5002/weatherforecast");
    var content = await response.Content.ReadAsStringAsync();
    var values = JsonConvert.DeserializeObject<IEnumerable<WeatherForecastViewModel>>(content);

    return View(values);
}

Paso 5: Pruebas

Si llegamos a este punto y no hemos olvidado ningún paso ni configuración, estamos listos para compilar y ejecutar la solución.

Luego de iniciar sesión, podemos verificar que todo funcione correctamente haciendo clic en la nueva acción disponible en la cabecera. Deberíamos ver el resultado devuelto por la API en forma de tabla.

Resultado en forma de tabla
Resultado en forma de tabla

Si intentamos acceder a la vista sin haber iniciado sesión obtendremos una excpción del tipo MsalUiRequiredException.

Es nuestra responsabilidad detectar este escenario y redireccionar al usuario a la pantalla de inicio de sesión.

Conclusión

Con este post hemos completado una integración completa de una aplicación Web MVC, una Web API y Azure AD B2C, y vimos que es muy simple e intuitivo la forma en que los tres componentes se integran.

Gracias a las librerías Microsoft.Identity.Web y Microsoft.Identity.Web.UI podemos escribir muy poco código y reducir así el esfuerzo y tiempo necesarios.

Podrás encontrar el código completo en mi GitHub.

Lanzamiento de Azure Web PubSub (Preview)

En la última semana de Abril, Microsoft anunció el lanzamiento en modo preview de un nuevo servicio llamado Azure Web PubSub.

En este artículo veremos cuáles son las características principales, posibles casos de uso y costos de este nuevo servicio que promete ser el nuevo de facto para comunicación de aplicaciones en tiempo real.

Mensajería en tiempo real

Azure Web PubSub es un servicio totalmente manejado (no requiere la gestión de componentes de infraestructura) diseñado para la construcción de aplicaciones que requieren mensajería en tiempo real con soporte nativo para WebSockets.

Una de las claves de WebSockets es que soporta comunicación dual bidireccional (full-duplex) entre clientes y servidores utilizando TCP. Azure Web PubSub simplifica todo el manejo relacionado a los servidores WebSockets.

Es por esto que Azure Web PubSub permite crear aplicaciones con mensajería en tiempo real en forma ágil, eficiente, escalable y simple.

Características principales

Una de las características principales es que Azure Web PubSub está preparado para arquitecturas de gran escala y con alta disponibilidad, siendo un servicio robusto y seguro.

Otra característica interesante es la integración en forma nativa con Azure Functions, lo que nos permite modelar arquitecturas totalmente serverless.

En cuánto a lo que respecta a lenguajes de programación para la creación de servidores, al momento existen SDKs para C#, Java, JavaScript y Python.

Azure Web PubSub vs Azure SignalR

Ambos servicios tienen cómo propósito simplificar la construcción y manejo de sistemas de mensajería en tiempo real entre clientes y servidores. Además ambos utilizan WebSockets.

Sin embargo, Azure SignalR está basado en una serie de librerías de SignalR que requieren algunos componentes específicos, qué en muchos casos no están disponibles en el cliente. Por el contrario, Azure Web PubSub sólo necesita WebSockets.

Casos de Uso

Vista general de Azure Web PubSub
Vista general de Azure Web PubSub

La lista de posibles casos de uso puede ser ilimitada, o al menos muy extensa. Pero aquí tenemos algunos casos de uso comunes:

  • Actualizaciones altamente frecuentes: como juegos o subastas.
  • Chats: aplicaciones que requieren algún tipo de interacción entre usuarios (vendedores con clientes por ejemplo)
  • Estado en tiempo real de distintos tipos de dispositivos: incluyendo no sólo dispositivos IoT sino también smartphones y computadoras.

Precio

El servicio se factura en función de la cantidad de unidades y de la cantidad de mensajes mensuales.

  • Unidades: Cada unidad representa una cantidad máxima de conexiones concurrentes. Así por ejemplo, a mayor cantidad de unidades mayor cantidad de conexiones concurrentes
  • Mensajes: los mensajes se miden en kilobytes de salida y se estiman en 2KB por mensaje. De esta forma se calcula estimativamente que 1000 mensajes equivalen a 2000KB

El servicio se encuentra disponible en dos opciones, Free y Standard. Un aspecto destacable es que el servicio es 100% pago por uso y no implica un costo inicial.

A continuación una tabla comparativa:

FreeStandard
Conexiones concurrentes por unidad201000
Mensajes por unidad por día20000Sin límites (el primer millón de mensajes es gratis)
Precio por unidad por díaGratisUSD 1.61
Cantidad máxima de unidades1100
Tabla comparativa Free vs Standard

Podrás encontrar información más detallada en la aquí.

Conclusión

Azure Web PubSub es nuevo servicio diseñado para comunicación de aplicaciones en tiempo real que promete ser eficiente, escalable, seguro y ágil.

Si querés conocer más sobre el servicio, la documentación oficial es excelente.

© 2021 Facu The Rock

Tema por Anders NorenArriba ↑