Hablemos sobre .Net y Azure

Etiqueta: Azure AD B2C

Azure AD B2C: A real silver bullet (CloudWithChris.com)

Esta semana tuve la oportunidad de participar del canal de Chris Reddington para hablar un poco de Azure AD B2C en la sección llamada “Tales from the Real World”, donde los participantes nos cuentan distintos ejemplos de servicios de Azure en la vida real.

En este caso estuvimos hablando de mi participación como organizador de vOpen.Tech y como gracias a Azure AD B2C fuimos capaces de sobreponernos a todos los desafíos que la pandemia de COVID nos generó en la organización de la edición 2020.

Azure AD B2C – Cloud With Chris

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

En artículo anterior de la serie armamos nuestro Conector y configuramos Azure AD B2C para utilizarlo y así detectar y prevenir usuarios duplicados. Además creamos una Azure Function con código base para probar el conector.

En este post final completaremos la implementación escribiendo el código necesario para consultar Microsoft Graph API por usuarios con el mismo email ya sea como identidad o email adicional.

Preparación

Antes de comenzar con la implementación necesitamos recolectar las siguientes piezas de información y hacer algunas configuraciones:

  1. ID de Tenant o Directorio
  2. ID de Aplicación
  3. Generar un Secreto de Cliente
  4. Dar permisos para Microsoft Graph API

ID de Tenant y ID de Aplicación

Para obtener las primeras dos piezas de información que necesitamos debemos ir al registro de aplicaciones seleccionar la aplicación con la cuál vamos a trabajar. Cuándo realizamos la configuración inicial creamos un registro de aplicación llamado Sitio Web Increíble, ese es el que seleccionaremos en este caso.

Dela sección Información general del registro de aplicación podremos ver la información necesaria.

Registro de aplicación
Registro de aplicación

Generar secreto de cliente

Desde el mismo registro de aplicación podremos generar un secreto de cliente. En la sección Certificados y Secretos creamos un Nuevo secreto de cliente. Sólo necesitamos completar la descripción (la cuál es usada como referencia) y seleccionar una expiración.

Generación de secreto de cliente
Generación de secreto de cliente

Al finalizar veremos el secreto de cliente en la lista de secretos, necesitamos copiar el valor. Es importante tener en cuenta que una vez que abandonemos esta página ya no podremos a volver a ver el valor.

Valor del secreto de cliente
Valor del secreto de cliente

Permisos para Microsoft Graph API

Desde la sección Permisos de API en el registro de aplicación, agregamos un nuevo permiso de Microsoft Graph. Dentro de la categoría Permisos de Aplicación agregamos el permiso User.Read.All como se muestra a continuación:

Permisos de Microsoft Graph para leer usuarios

Es muy importante conceder consentimiento permisos de administrador para nuestro tenant, de lo contrario los permisos no serán efectivos.

Implementación

Si bien Microsoft Graph expone una API REST muy bien documentada, el equipo de Microsoft creó una librería para facilitarnos la tarea y que se encuentra disponible vía paquetes de NuGet. Comenzaremos agregando al proyecto de Azure Function los siguientes paquetes de NuGet:

Microsoft.Graph
Microsoft.Graph.Auth
Microsoft.Identity.Client

Luego, a partir del ID de Aplicación, el ID de Tenant y el Secreto de Cliente que obtuvimos anteriormente, vamos a generar una instancia de GraphServiceClient:

// Usings
using Microsoft.Graph;
using Microsoft.Graph.Auth;
using Microsoft.Identity.Client;

// Código
var confidentialClientApplication = ConfidentialClientApplicationBuilder
    .Create("<< ID de Aplicación >>")
    .WithTenantId("<< ID de Tenant >>")
    .WithClientSecret("<< Secreto de Cliente >>")
    .Build();

var authProvider = new ClientCredentialProvider(confidentialClientApplication);

var graphClient = new GraphServiceClient(authProvider);

Buscando usuarios por email

Estamos buscando encontrar usuarios con el mismo email que el usuario actual está intentando usar, con lo cuál buscamos usuario cuya identidad sea el mail o usuarios que tengan el email como parte de sus emails adicionales. Esto requiere dos peticiones diferentes.

  • Búsqueda por identidad
var usersByIdentity = (await _graphClient.Users
    .Request()
    .Filter($"identities/any(c:c/issuerAssignedId eq '{email}' and c/issuer eq '{"<< ID de Tenant >>"}')")
    .GetAsync())
        .ToArray();
  • Usuarios por otros emails:
var usersByOtherEmails = (await _graphClient.Users
    .Request()
    .Filter($"otherMails/any(c:c eq '{email}') and UserType eq 'Member'")
    .GetAsync())
        .ToArray();

Si alguna de las dos peticiones anteriores contiene algún resultado, eso quiere decir entonces que hemos encontrado otro usuario con el mismo email que el usuario actual y demos detener el flujo de usuario. De lo contrario podemos continuar con la ejecución del flujo de usuario.

Quiero hacer mención al los usuarios de Stackoverflow boehlefeld y LuisEduardox de quién tomé las dos consultas necesarias para interactuar con Microsoft Graph a partir de las respuestas aquí y aquí mencionadas.

Como vimos en el post anterior, detenemos la ejecución del flujo de usuario retornando como respuesta "action" : "ShowBLockPage".

if (usersByIdentity.Any() || usersByOtherEmails.Any())
{
    return new OkObjectResult(
        new
        {
            version = "1.0.0",
            action = "ShowBlockPage",
            userMessage = $"Email {req.email} is duplicated."
        });
}

return new OkObjectResult(
    new
    {
        version = "1.0.0",
        action = "Continue"
    });

Solución completa

Juntando todas las piezas, nuestra Azure Function se ve de la siguiente forma:

var confidentialClientApplication = ConfidentialClientApplicationBuilder
    .Create("<< ID de Aplicación >>")
    .WithTenantId("<< ID de Tenant >>")
    .WithClientSecret("<< Secreto de Cliente >>")
    .Build();

var authProvider = new ClientCredentialProvider(confidentialClientApplication);

var graphClient = new GraphServiceClient(authProvider);

var usersByIdentity = (await _graphClient.Users
    .Request()
    .Filter($"identities/any(c:c/issuerAssignedId eq '{email}' and c/issuer eq '{"<< ID de Tenant >>"}')")
    .GetAsync())
        .ToArray();

var usersByOtherEmails = (await _graphClient.Users
    .Request()
    .Filter($"otherMails/any(c:c eq '{email}') and UserType eq 'Member'")
    .GetAsync())
        .ToArray();

if (usersByIdentity.Any() || usersByOtherEmails.Any())
{
    return new OkObjectResult(
        new
        {
            version = "1.0.0",
            action = "ShowBlockPage",
            userMessage = $"Email {req.email} is duplicated."
        });
}

return new OkObjectResult(
    new
    {
        version = "1.0.0",
        action = "Continue"
    });

Sólo nos resta desplegar la nueva versión de nuestra Azure Function y probar.

Conclusión

En este post nos enfocamos en la parte final de la solución la cual implicó la interacción con Microsoft Graph para detectar usuarios con el mismo email que el usuario que se está intentando crear.

Una solución un poco más elegante pero mucho más compleja es la unificación de identidades, para lo que necesitamos utilizar Políticas Personalizadas de Azure AD B2C. Dejaremos esa para más adelante.

Para ver la implementación final en detalle te recomiendo revisar el repositorio en GitHub.

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

En artículo anterior discutimos sobre este posible inconveniente cuando trabajamos con distintos proveedores de identidad y planteamos una propuesta de arquitectura combinando Conectores, Azure Functions y Microsoft Graph API..

En este post vamos a analizar qué son los Conectores y cómo nos pueden ser de gran ayuda para requerimientos de este tipo. Además crearemos un conector junto con una API muy simple utilizando Azure Functions.

Conectores

Ya vimos que los conectores nos proporcionan un mecanismo para ejecutar REST APIs antes de que Azure AD B2C haga la creación del usuario en la base de datos. Y vimos que se pueden ejecutar después de haber iniciado sesión con un proveedor de identidad externo y antes de crear el usuario.

Descubrimos además que sólo se ejecutan durante el registro de nuevos usuarios. Veamos entonces los aspectos técnicos más relevantes para poder completar nuestra implementación.

Casos de uso

Los conectores nos permiten extender la experiencia de registro e integrarla con sistemas externos:

  • Validación de datos: podemos validar determinados datos de entrada como puede ser el formato correcto de de identificación personal o cuenta bancaria.
  • Aprobación: en algunos casos prevenir la creación del usuario si no fue autorizado aún en una plataforma interna.
  • Agregar o sobrescribir atributos: podríamos sobrescribir algunos atributos, ya sea para darle un formato específico (Camel case). También podemos agregar o auto completar atributos.
  • Lógica de negocio: por ejemplo, notificar a otros sistemas externos.

En nuestro caso, validaremos contra Microsoft Graph si existe un usuario con ese email.

Solicitud (Request)

Cuando un conector es ejecutado envía una solicitud HTTP POST a la REST API que hemos configurado oportunamente. El cuerpo de la solicitud será enviado en formato JSON (Content-type: application/json), por ejemplo:

{
 "email": "johnsmith@facutherock.net",
 "identities": [
     {
     "signInType":"federated",
     "issuer":"github.com",
     "issuerAssignedId":"0123456789"
     }
 ],
 "displayName": "John Smith",
 "givenName":"John",
 "lastName":"Smith",
 "extension_<extensions-app-id>_Atributo1": "Atributo personalizo 2",
 "extension_<extensions-app-id>_Atributo2": "Atributo personalizo 2",
 "ui_locales":"es-ES"
}

Los atributos o claims que no tengan valor (null or undefined) no serán informados en el JSON enviado como solicitud.

Tipo de respuesta (Response)

Nuestra REST API debe devolver una respuesta al conector de Azure AD B2C que luego será utilizada para continuar con el flujo de usuario. La respuesta debe estar en formato JSON (Content-type: application/json).

Hay tres tipos de respuesta:

  • Respuesta de continuación:
    Indica que el flujo debe continuar a la siguiente etapa. Si estamos ejecutando un conector luego del inicio de sesión con un proveedor externo, la siguiente etapa será la recolección de atributos adicionales. Si el conector ejecutado es antes de crear el usuario, la etapa siguiente es la creación del usuario.
    El código de estado de la respuesta debe ser 200 - OK y debe contener un JSON con un elemento "action" cuyo valor debe ser "Continue", como el siguiente:
{
    "version": "1.0.0",
    "action": "Continue",
    "postalCode": "12349", // atributo adicional o auto-completado
    "extension_<extensions-app-id>_CustomAttribute": "value" // Atributo personalizado adicional o auto-completado
}
  • Respuesta de bloqueo:
    Detiene el flujo de usuario y muestra un mensaje al usuario. El código de estado de la respuesta debe ser 200 - OK y debe contener un JSON con un elemento "action" cuyo valor debe ser "ShowBlockPage", como el siguiente:
{
    "version": "1.0.0",
    "action": "ShowBlockPage",
    "userMessage": "Hubo un error.",
}
  • Respuesta de validación:
    Esta respuesta sólo es válida en la recolección de atributos adicionales y muestra un error al usuario en relación a la información ingresada. Por ejemplo, "Apellido es obligatorio".
    El código de estado de la respuesta debe ser 400 - Bad Request, debe contener un JSON con un elemento "action" cuyo valor debe ser "ValidationError" y otro elemento "status" cuyo valor debe ser 400 o "400", como el siguiente:
{
    "version": "1.0.0",
    "status": 400,
    "action": "ValidationError",
    "userMessage": "Apellido es obligatorio."
}

Definiciones

Para la implementación que necesitamos, donde sólo queremos evitar usuarios repetidos con el mismo email pero usando diferentes proveedores de identidad, usaremos respuestas de continuación y respuestas de bloqueo.

La lógica responderá de la soguiente forma:

  • Si existe un usuario con el email indicado, devolveremos "ShowBlockPage".
  • Si no existe un usuario con el email indicado, devolveremos "Continue".

Manos a la obra

En este post nos concentraremos sólo en los conectores y dejaremos para el próximo la lógica necesaria para interactuar con Microsoft Graph API.

  1. Crearemos una Azure Function para atender la petición del conector.
  2. Crearemos un conector y lo asociaremos a la Azure Function.
  3. Configuraremos el flujo de usuario para utilizar el conector.

Azure Function

Para no extender demasiado el texto ni desviar el foco, obviaré la creación y publicación de un proyecto de Azure Functions. Si necesitas ayuda con eso, podrás encontrarlo aquí.

Utilizaremos una función del tipo HttpTrigger. Por el momento la lógica de la función será muy simple:

  • Si el dominio del email es "gmail.com" entonces devolvemos "ShowBlockPage" con el mensaje adicional “Usuario duplicado".
  • En cualquier otro caso devolvemos "Continue".
[FunctionName("PreventUserDuplication")]
public static IActionResult Run(
    [HttpTrigger(AuthorizationLevel.Anonymous, "post")] dynamic req)
{
    if (req.email.EndsWith("gmail.com"))
    {
        return new OkObjectResult(
            new
            {
                version = "1.0.0",
                action = "ShowBlockPage",
                userMessage = $"Email {req.email} is duplicated."
            });
    }
    return new OkObjectResult(
        new
        {
            version = "1.0.0",
            action = "Continue"
        });
}

Finalmente debemos publicar el código y obtener la URL correspondiente ya que la necesitaremos en el siguiente paso.

La implementación que estamos realizando es solo “de muestra” y no es la implementación final. La idea es entender como funcionan los conectores.

Crear conector

Desde la sección Conectores de API agregaremos un nuevo conector.

Conectores de API
Conectores de API
Configuración de conector
Configuración de conector

En la pantalla de configuración del nuevo conector elegiremos un nombre para mostrar y luego completaremos el campo Dirección URL del punto de conexión con la URL de la Azure Function del punto anterior.

Tipo de autenticación usaremos Básico y para Nombre de Usuario y Contraseña pondremos cualquier valor , más adelante veremos por qué.

Al finalizar guardamos los cambios y terminamos.

Flujo de usuario

Flujo de usuario - Conectores
Flujo de usuario – Conectores

La configuración del flujo de usuario es bastante simple, solo debemos seleccionar que conector usar y en qué parte del flujo.

Siguiendo con nuestro, vamos a utilizar el mismo conector en ambas instancias, luego del inicio de sesión con un proveedor externo y antes de la ceación del usuario.

Pruebas

Para las pruebas intentaremos registrar un nuevo usuario con una cuenta de email terminada en “gmail.com” y otra terminada con cualquier dominio.

El flujo de usuario debería bloquear al usuario si la cuenta de email es de “gmail.com” y debería continuar con otras cuentas.

Usuario duplicado
Usuario duplicado

Para proveedores de identidad externos el comportamiento será el mismo.

Seguridad

Al momento de escribir este post, los conectores aceptan como mecanismo de seguridad autenticación básica o certificados (preview).

El mecanismo que elegimos anteriormente es Básico, el cuál requiere Usuario y Contraseña.

Es responsabilidad de la API validar correctamente el usuario y contraseña al recibir el request.

La ventaja de utilizar Azure Functions es que podemos utilizar la seguridad integrada que el servicio ofrece mediante llaves de función (Function Keys)

Conclusión

Hemos implementado en forma satisfactoria nuestra primera integración a través de Conectores de API, y si bien la implementación es solo “de muestra”, nos permitió entender como funcionan.

Para poder completar la implementación del requerimiento sólo nos falta completar la implementación de la Azure Function para integrarnos con Microsoft Graph API, te lo cuento en el próximo post!

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.

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.

Protegiendo Web API .Net 5 con Azure AD B2C

Uno de los requerimientos más comunes cuándo utilizamos Azure AD B2C es que sólo usuarios autenticados de nuestro tenant puedan acceder a nuestras APIs.

En este artículo veremos como configurar Azure AD B2C y como integrar una Web API .Net 5 para aceptar peticiones de usuarios autenticados.

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

Muy frecuentemente, encontramos como parte de nuestras aplicaciones componentes del tipo API REST para exponer funcionalidades específicas.

Suele ser habitual que queramos proteger dichas APIs de accesos a usuarios no autorizados o que no forman parte de nuestra aplicación.

Requerimiento

Tenemos una aplicación Web API .Net 5 la cuál queremos integrar con Azure AD B2C, de forma que solo usuarios autenticados puedan acceder.

Esta aplicación todavía no implementa ningún mecanismo de autenticación, con lo cual veremos también los pasos necesarios para configurar autenticación.

Microsoft Identity Web

Microsoft ha estado mejorando y simplificando la forma en la que se integran aplicaciones web con Azure AD, no solo soportando estándares como OAuth2 y OpenID Connect, sino también reduciendo la cantidad de código necesario para implementar la solución.

Para nuestra integración utilizaremos la librería Microsoft.Identity.Web. Estas librerías están construidas sobre la Biblioteca de Autehticación de Microsoft o MSAL.

  • Microsoft.Identity.Web
    Esta librería proporciona los mecanismos necesarios para interactuar con Azure AD de una forma simple, segura y estándar. Por ejemplo, los manejadores para las URL de redirección para el inicio de sesión y el cierre de sesión.

Paso 1: Solución, proyecto y librerías

Comenzaremos creando una solución y un proyecto Web API. Luego instalaremos la librería mencionada en la sección anterior y para validar que todo esté funcionando correctamente compilaremos y ejecutaremos la solución.

# Crear solución y projecto API
dotnet new sln --name AzureAdB2C
dotnet new webapi --name AzureAdB2C.API --output AzureAdB2C.API
dotnet sln add .\AzureAdB2C.API\AzureAdB2C.API.csproj

# Instalar la librería necesaria
dotnet add .\AzureAdB2C.API\AzureAdB2C.API.csproj package Microsoft.Identity.Web

# Restaurar y compilar
dotnet restore
dotnet build

# Ejecutar
dotnet run --project .\AzureAdB2C.API\AzureAdB2C.API.csproj

Deberíamos ver algo similar al siguiente resultado desde la consola, donde se proporcionará la URL local para poder acceder a la documentación y corroborar que esta funcionando.

Dotnet run desde la línea de comandos
Dotnet run desde la línea de comandos

Por defecto, .Net 5 incluye Swagger como mecanismo de documentación de APIs. Para acceder al mismo, usaremos la URL provista en la línea de comandos (en este caso https://localhost:5001) y agregaremos como parte de la ruta /swagger.

https://localhost:5001/swagger

Documentación con Swagger
Documentación con Swagger

Paso 2: Configuración de servicios y pipeline

Vamos a configurar los servicios necesarios para la integración con Azure AD B2C. Además configuraremos el pipeline para utilizar Autenticación.

Para este realizaremos los cambios detallados a continuación en la clase Startup.cs del proyecto AzureAdB2C.API.

Como paso preliminar agregaremos el siguiente using a la clase Startup.cs:

using Microsoft.Identity.Web;
using Microsoft.AspNetCore.Authentication.JwtBearer;

ConfigureServices

En el método ConfigureServices configuraremos los servicios necesarios para la integración con Azure AD B2C.

Microsoft.Identity.Web incluye un método de extensión muy conveniente para configurar la integración llamado AddMicrosoftIdentityWebApi().

public void ConfigureServices(IServiceCollection services)
{
    services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
            .AddMicrosoftIdentityWebApi(options =>
            {
                Configuration.Bind("AzureAdB2C", options);

                options.TokenValidationParameters.NameClaimType = "name";
            },
            options => { Configuration.Bind("AzureAdB2C", options); });

    services.AddControllers();
    services.AddSwaggerGen(c =>
    {
        c.SwaggerDoc("v1", new OpenApiInfo { Title = "AzureAdB2C.API", Version = "v1" });
    });
}

El método AddMicrosoftIdentityWebApi() nos permite utilizar la configuración de nuestra aplicación mediante el objeto IConfiguration indicando el nombre de la sección a utilizar, en este caso "AzureAdB2C". Agregaremos esta sección de configuración mas adelante en archivo appsettings.json.

Configure

El único requisito a nivel de pipeline, es incluir el middleware de autenticación con el método UseAuthentication(). Debido a que estamos trabajando con el pipeline, es muy importante respetar el orden en el que llamamos al método.

Tiene que ser después de UseRouting() y antes de UseAuthorization().

app.UseRouting();
app.UseAuthentication();
app.UseAuthorization();

Paso 3: Registrar la API en Azure AD B2C

Para que nuestra API pueda interactuar con Azure AD B2C es necesario generar un registro de aplicación previamente.

Para poder registrar una nueva aplicación, debemos navegar a la sección de Registros de aplicaciones situada sobre el panel de la izquierda y luego ir a Nuevo Registro.

Registro de aplicaciones
Registro de aplicaciones

En formulario de registro solo vamos a completar el campo Nombre y dejaremos el resto de los campos con sus valores por defecto. En este caso elegí como nombre “API”.

Nuevo registro de aplicación
Nuevo registro de aplicación

Ya finalizado el registro de aplicación para la API, en la sección de Información general vamos a tomar nota del Id de aplicación, ya que lo vamos a necesitar para la configuración de la API.

Id de aplicación o Client Id
Id de aplicación o Client Id

Paso 4: Exponer un ámbito o scope

Parte del requerimiento que estamos implementando implica que solo usuario autorizados puedan acceder a la API. A su vez los usuarios tienen acceso a determinadas APIs o recursos.

Esos recursos (o grupos de recursos) se representan a través de lo que se denomina ámbito o scope.

Cada API o recurso expone la lista de scopes que maneja de forma que puedan ser asignados a los usuarios en función de los roles que asignados.

A modo de ejemplo y para clarificar un poco más que es un scope, una API para gestión de Posts de un Blog, podría exponer la siguiente lista:

  • Lector: este scope habilita el acceso al los posts recomendados que un usuario puede tener en base a sus etiquetas preferidas.
  • Escritor: este scope habilita el acceso en modo edición a los posts que un usuario que ha escrito.
  • Moderador: este scope habilita la eliminación de posts que no cumplen con las reglas del blog

Exponer un ámbito o scope

Para exponer un scope vamos a ir al registro de aplicación que creamos en el paso anterior para nuestra API y luego a la sección Exponer una API. Finalmente vamos a clicar la opción Agregar un ámbito.

Exponer una API
Exponer una API

Establecer URI de Identificador

La primera vez que agregamos un scope vamos a tener que definir la URI con la cuál se identificará a todos los scopes expuestos.

URI de identitificación
URI de identitificación

Azure AD B2C sugerirá un valor aleatorio, sin embargo es recomendable asignar un valor que tenga sentido y represente la API.

Siguiendo con el ejemplo, posts es un buen nombre.

De esta forma, los scopes Lector, Escritor y Moderador se verían así:

  • https://linkedinazureb2c.onmicrosoft.com/posts/Lector
  • https://linkedinazureb2c.onmicrosoft.com/posts/Escritor
  • https://linkedinazureb2c.onmicrosoft.com/posts/Moderador

Agregar Scope

Una vez establecida la URI, continuamos con la creación del scope.

Agregar scope
Agregar scope

Paso 5: Configuración de la aplicación Web API

En este punto solo nos falta recolectar algunas piezas de información y configurar la aplicación Web API para que se integre correctamente con Azure AD B2C. La información que necesitamos es la siguiente:

  • Instancia
  • Dominio
  • Id de Cliente
  • Id de flujo de usuario

El Id de Cliente lo obtuvimos en el Paso 3 cuando registramos la API, para obtener la Instancia, Dominio y Id del flujo de Usuario te dejo esta breve sección del artículo que escribí sobre integración con aplicaciones Web MVC.

En el archivo de configuración appsettings.json agregaremos una nueva sección llamada “AzureAdB2C” con las cuatro piezas de información del paso anterior.

"AzureAdB2C": {
  "Instance": "https://linkedinazureadb2c.b2clogin.com",
  "ClientId": "f4ad0000-0000-0000-0000-000000004aec",
  "Domain": "linkedinazureadb2c.onmicrosoft.com",
  "SignUpSignInPolicyId": "B2C_1_InicioSesionConRegistro"
}

Conclusión

En este post vimos cómo proteger una Web API con Azure AD B2C de forma que sólo usuario autenticados mediante un flujo de usuario de Azure AD B2C puedan acceder a la API.

Sin embargo, todavía no hemos podido probar la integración ya que para eso necesitamos poder autenticar un usuario.

En el próximo artículo compartiré como integrar una aplicación Web MVC con aplicaciones Web API utilizando Azure AD B2C como mecanismo de autenticación.

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

Integración de Azure AD B2C con MVC .Net 5

Hace unas semanas escribí una serie de artículos donde compartí paso a paso como dar los primeros pasos con Azure AD B2C y cómo configurar el servicio de forma correcta.

En este artículo veremos como realizar la integración de Azure AD B2C con aplicaciones Web MVC .Net 5 de forma fácil y rápida.

IMPORTANTE: trabajaremos sobre la base construida en los artículos anteriores, con lo cual es recomendable tener claros los conceptos y pasos allí detallados.

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 la actualidad, casi cualquier aplicación requiere que ciertas partes o componentes estén restringidas a usuarios autenticados de la aplicación.

Habitualmente la autenticación se realiza presentando al usuario un formulario de Inicio de sesión donde debe ingresar el nombre de usuario o email y una contraseña.

Es aquí donde entra Azure AD B2C y los flujos de usuario.

Requerimiento

Tenemos una aplicación Web MVC .Net 5 la cual queremos integrar con nuestro Azure AD B2C. Esta aplicación todavía no implementa ningún tipo de autenticación.

La idea principal es que no sólo aprendamos a integrar Azure AD B2C si no que además veamos los requerimientos mínimos para comenzar a utilizar Autenticación.

Microsoft Identity Web

Microsoft ha estado mejorando y simplificando la forma en la que se integran aplicaciones web con Azure AD, no solo soportando estándares como OAuth2 y OpenID Connect, sino también reduciendo la cantidad de código necesario para implementar la solución.

Para nuestra integración utilizaremos las librerías Microsoft.Identity.Web y Microsoft.Identity.Web.UI. Estas librerías están construidas sobre la Biblioteca de Autehticación de Microsoft o MSAL.

  • Microsoft.Identity.Web
    Esta librería proporciona los mecanismos necesarios para interactuar con Azure AD de una forma simple, segura y estándar. Por ejemplo, los manejadores para las URL de redirección para el inicio de sesión y el cierre de sesión.
  • Microsoft.Identity.Web.UI
    Esta librería proporsiona los componentes visuales (controladores y vistas) necesarias para la integración, como pantallas de consentimiento, cierre de sessión, etc.

Paso 1: Solución, proyecto y librerías

Comenzaremos creando una solución y un proyecto Web MVC. Luego instalaremos las dos librerías mencionadas en la sección anterior y para validar que todo esté funcionando correctamente compilaremos y ejecutaremos la solución.

# Crear solución y projecto MVC
dotnet new sln --name AzureAdB2C
dotnet new mvc --name AzureAdB2C.MVC --output AzureAdB2C.MVC
dotnet sln add .\AzureAdB2C.MVC\AzureAdB2C.MVC.csproj

# Instalar las librerías necesarias
dotnet add .\AzureAdB2C.MVC\AzureAdB2C.MVC.csproj package Microsoft.Identity.Web
dotnet add .\AzureAdB2C.MVC\AzureAdB2C.MVC.csproj package Microsoft.Identity.Web.UI

# Restaurar y compilar
dotnet restore
dotnet build

# Ejecutar
dotnet run --project .\AzureAdB2C.MVC\AzureAdB2C.MVC.csproj

Deberíamos ver algo similar al siguiente resultado desde la consola, donde se proporcionará la URL local para poder acceder al sitio web y corroborar que esta funcionando.

Dotnet run desde la línea de comandos
Dotnet run desde la línea de comandos
Home aplicación web MVC
Home aplicación web MVC

Paso 2: Configuración de servicios y pipeline

Vamos a configurar los servicios necesarios para la integración con Azure AD B2C. Además configuraremos el pipeline para utilizar Autenticación.

Para este realizaremos los cambios detallados a continuación en la clase Startup.cs del proyecto AzureAdB2C.MVC.

Como paso preliminar agregaremos los siguientes usings a la clase Startup.cs:

using Microsoft.Identity.Web;
using Microsoft.Identity.Web.UI;

ConfigureServices

Por un lado tenemos que configurar los servicios necesarios relacionados a la interfaz de usuario, como por ejemplo las vistas de consentimiento y cierre de sesión.

Uno de los cambios interesantes en la nueva librería MSAL es que incluye todos los controladores y vistas necesarias en forma predeterminada. Esto quiere decir que si no tenemos requerimientos especiales, no necesitamos crear ningún controlador ni vista adicional.

Necesitamos incluir los metodos de extension AddMicrosoftIdentityUI() para la parte de la interfaz de usuario y AddMicrosoftIdentityWebAppAuthentication() para la integración con Azure AD B2C.

Además incluiremos los servicios necesarios para trabajar con Razor Pages, ya que son requeridos por AddMicrosoftIdentityUI()

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

    services.AddMicrosoftIdentityWebAppAuthentication(Configuration, "AzureAdB2C");

    services.AddRazorPages();
}

El método AddMicrosoftIdentityWebAppAuthentication() requiere como parámetro inicial el objeto de configuración IConfiguration y como segundo parámetro el nombre de la sección de configuración a utilizar, en este caso "AzureAdB2C". Agregaremos esta sección de configuración mas adelante en archivo appsettings.json.

Configure

El único requisito a nivel de pipeline, es incluir el middleware de autenticación con el método UseAuthentication(). Debido a que estamos trabajando con el pipeline, es muy importante respetar el orden en el que llamamos al método.

Tiene que ser después de UseRouting() y antes de UseAuthorization().

app.UseRouting();
app.UseAuthentication();
app.UseAuthorization();

Por último, incluiremos el pipeline para utilizar Razor Pages.

app.UseEndpoints(endpoints =>
{
    endpoints.MapControllerRoute(
        name: "default",
        pattern: "{controller=Home}/{action=Index}/{id?}");

    endpoints.MapRazorPages();
});

Paso 3: Vistas para inicio y cierre de sesión

Ya que partimos de una aplicación Web MVC base, el sitio todavía no ofrece las acciones para inicio y cierre de sesión correspondientes. Esta es una tarea que tendremos que hacer nosotros.:

La implementación consiste en

  • Agregar una vista parcial incluyendo las acciones para inicio y cierre de sesión, habitualmente llamada _LoginPartial.cshtml.
  • Modificar la vista parcial _Layout.cshtml para incluir la vista del punto anterior.

_LoginPartial.cshtml

Esta vista se encargara de mostrar la acción para inicio de sesión en el caso de que el usuario no haya iniciado sesión aún, o mostrar el nombre del usuario junto con la acción de cerrar sesión en caso contrario.

@using Microsoft.Identity.Web
@if (User.Identity.IsAuthenticated)
{
    <ul class="nav navbar-nav navbar-right">
        <li class="navbar-text">Hello @User.GetDisplayName()!</li>
        <li><a asp-area="MicrosoftIdentity" asp-controller="Account" asp-action="SignOut">Sign out</a></li>
    </ul>
}
else
{
    <ul class="nav navbar-nav navbar-right">
        <li><a asp-area="MicrosoftIdentity" asp-controller="Account" asp-action="SignIn">Sign in</a></li>
    </ul>
}

Algo destacable son las acciones para inicio de sesión (Sign in) y cierre de sesión (Sign out). Ambas utilizan el controlador Account dentro del área MicrosoftIdentity.

Este controlador forma parte de la librería Microsoft.Identity.Web.UI. Este uno de los mejores cambios que esta librería nos ofrece, ya que nos evita tener que crear controladores y vistas.

_Layout.cshtml

Esta vista contiene, entre otras cosas, la cabecera (header) con la barra de navegación (navbar) o menú. Agregaremos como parte de la cabecera la vista parcial que creamos en la sección anterior.

<header>
    <nav class="navbar navbar-expand-sm ...">
        <div class="container">
            <a class="navbar-brand" asp-area="" asp-controller="Home" asp-action="Index">AzureAdB2C.MVC</a>
            <button class="navbar-toggler">...            </button>
            <div class="navbar-collapse collapse ...">
                <ul class="navbar-nav flex-grow-1">...</ul>
                <partial name="_LoginPartial" />
            </div>
        </div>
    </nav>
</header>

Si ejecutamos la aplicación ahora veremos disponible la acción Sign in en la barra de menú sobre la parte de arriba a la derecha.

Home aplicación web MVC con Inicio de Sesión
Home aplicación web MVC con Inicio de Sesión

Paso 4: Agregar URLs de redirección en Azure AD B2C

Ya con nuestra aplicación funcionando, configuraremos la URL de redirección hacia nuestro sitio web local para el inicio de sesión y para el cierre de sesión. Como vimos anteriormente, Microsoft.Identity.Web incluye ambos manejadores.

  • El manejador de inicio de sesión responde a la URL /signin-oidc, que en nuestro ambiente de desarrollo local sería https:localhost:5001/signin-oidc.
  • El manejador de cierre de sesión responde a la URL /signout-oidc, que en nuestro ambiente de desarrollo local sería https:localhost:5001/signout-oidc.

Cuando realizamos la configuración inicial del tenant, registramos una nueva aplicación llamada Sitio Web Increíble donde agregamos una URL de redirección de prueba.

Para agregar la URL de redirección, desde el registro de aplicación Sitio Web Increíble en la sección Autenticación, tendremos la lista de URLs. Haciendo clic en Agregar un URI podremos agregar el nuestro.

Más abajo, agregaremos también la URL de cierre de sesión del canal frontal. Importante siempre guardar los cambios.

Configuración URL de retorno Azure AD B2C
Configuración URL de retorno Azure AD B2C

Paso 5: Recolectar información de Azure AD B2C

Para finalizar la integración necesitamos disponer de los siguientes datos:

  • Instancia
  • Dominio
  • Id de Cliente
  • Id del flujo de Inicio de Sesión y Registro

Instancia y Dominio

Si bien el nombre de la instancia y el nombre del dominio son diferentes, en ambas requerimos el subdominio. El subdominio lo podemos obtener desde el panel de Información General del tenant a partir del Nombre de Dominio.

Panel de información general Azure AD B2C
Panel de información general Azure AD B2C

Ya con el nombre de dominio completo, vamos a extraer la primer parte, y ese será el subdominio que usaremos para construir el nombre de la instancia. En el ejemplo anterior el nombre de dominio es linkedinazureadb2c.onmicrosoft.com, nos quedaremos con linkedinazureadb2c.

El nombre de instancia responde al siguiente formato https://{subdominio}.b2clogin.com, donde reemplazaremos {subdominio} por linkedinazureadb2c.

Estos son los valores que necesitamos:

  • Instancia: https://linkedinazureadb2c.b2clogin.com
  • Dominio: linkedinazureadb2c.onmicrosoft.com

Id de Cliente

El Id de Cliente o Client Id es el Id de registro de aplicación (Sitio Web Increíble). Y lo podemos obtener desde la lista de registros de aplicaciones bajo la columna Id de aplicación (cliente).

Registros de aplicaciones Azure AD B2C
Registros de aplicaciones Azure AD B2C

Id del flujo de Inicio de Sesión y Registro

El último dato que necesitamos es el id del flujo de usuario para inicio de sesión y registro, el cual obtendremos desde la sección de flujos de usuarios bajo la columna Nombre.

Flujos de usuario Azure AD B2C
Flujos de usuario Azure AD B2C

Paso 6: Configuración de la aplicación Web MVC

En este punto solo nos falta tomar la información que recolectamos anteriormente y configurar la aplicación Web MVC para que se integre correctamente con Azure AD B2C.

En el archivo de configuración appsettings.json agregaremos una nueva sección llamada “AzureAdB2C” con las cuatro piezas de información del paso anterior.

"AzureAdB2C": {
  "Instance": "https://linkedinazureadb2c.b2clogin.com",
  "ClientId": "f4ad0000-0000-0000-0000-000000004aec",
  "Domain": "linkedinazureadb2c.onmicrosoft.com",
  "SignUpSignInPolicyId": "B2C_1_InicioSesionConRegistro"
}

Paso 7: Pruebas

Si realizamos todos los pasos correctamente, al clicar en la acción Sign In seremos redireccionados a Azure AD B2C para iniciar sesión. Una vez el usuario ha sido autenticado exitosamente, veremos el nombre del usuario junto con la acción Sign Out.

Home aplicación web MVC con Cierre de Sesión
Home aplicación web MVC con Cierre de Sesión

Si ahora clicamos en la acción Sign out seremos redireccionados primero a Azure AD B2C, donde limpiaran las cookies de sesión y finalmente a la página de confirmación de cierre de sesión.

Home aplicación web MVC confirmación de Cierre de Sesión
Home aplicación web MVC confirmación de Cierre de Sesión

El redireccionamiento hacia Azure AD B2C y posteriormente hacia la página de confirmación de cierre de sesión suele ser muy rápido, en términos prácticos es imperceptible.

Conclusión

En este post vimos cómo integrar Azure AD B2C con aplicaciones Web MVC .Net 5 en forma fácil y rápida, incluyendo inicio y cierre de sesión.

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

Azure AD B2C + .Net 5 – Global Azure 2021 Latam

Como suele suceder todos los años, a mediados de Abril se celebra uno de los eventos más importantes a nivel global de la comunidad de Azure: el Global Azure.

Durante 3 días, comunidades de todo el mundo organizan en forma local charlas y workshops totalmente abiertos y gratuitos, donde los participantes pueden aprender y conocer más sobre el mundo Azure de la mano de distintos Líderes y expertos.

Este año tuve el placer (y por partida doble) de participar en la edición Latinoamérica con un colega y amigo experto en la materia, Jorge Levy.

Hemos compartido nuestra experiencia sobre el poder y simpleza de Azure AD B2C y cuál fácil es integrarlo con aplicaciones Web MVC .Net 5 y Web API .Net 5.

Configuración e Implementación de Azure AD B2C con .Net 5

En la actualidad, casi cualquier aplicación requiere que los usuarios puedan autenticarse, sin embargo, implementar un mecanismo de autenticación seguro y confiable requiere mucho conocimiento y tiempo, incluso teniendo experiencia previa.

En esta sesión, te cuento como gracias a este espectacular servicio B2C o Business-To-Clients, podemos ahorrar innumerables horas de desarrollo en implementación y despliegue de soluciones de Autenticación.

Veremos como construir y desplegar, sin necesidad de escribir código y en forma segura, confiable y escalable, un sistema de Inicio de Sesión y Registro de Usuario, incluyendo integración con Redes Sociales y proveedores externos.

Además haremos una integración punta a punta con una aplicación Web MVC .Net 5, Web API .Net 5 e integraremos nuestra Web MVC para poder consumir nuestra Web API en forma rápida y sencilla.

https://www.youtube.com/watch?v=rrJeS2N0X-I&t=14370s

Si quieres ver el código completo de los ejemplos que utilizamos durante la sesión, te dejo el repo de GitHub.

Azure AD B2C – Global Azure 2021 Verona

Como suele suceder todos los años, a mediados de Abril se celebra uno de los eventos más importantes a nivel global de la comunidad de Azure: el Global Azure.

Durante 3 días, comunidades de todo el mundo organizan en forma local charlas y workshops totalmente abiertos y gratuitos, donde los participantes pueden aprender y conocer más sobre el mundo Azure de la mano de distintos Líderes y expertos.

Este año tuve el placer de participar en la edición Verona, donde estuve hablando sobre el poder y simpleza de Azure AD B2C.

Azure AD B2C: una verdadera bala de plata

En la actualidad, casi cualquier aplicación requiere que los usuarios puedan autenticarse, sin embargo, implementar un mecanismo de autenticación seguro y confiable requiere mucho conocimiento y tiempo, incluso teniendo experiencia previa.

En esta sesión, te cuento como gracias a este espectacular servicio B2C o Business-To-Clients, podemos ahorrar innumerables horas de desarrollo en implementación y despliegue de soluciones de Autenticación.

Veremos como construir y desplegar, sin necesidad de escribir código y en forma segura, confiable y escalable, un sistema de Inicio de Sesión y Registro de Usuario, incluyendo integración con Redes Sociales y proveedores externos, soporte para múltiples idiomas, personalización de marca y mucho más.

Azure AD B2C: Areal silver bullet by Facu The Rock

Si querés conocer un poco más sobre este servicio, podes ver una serie de artículos que escribí en forma de tutorías muy detalladas y paso a paso.

Azure AD B2C: Configuración de JWT tokens

Este post forma parte de una serie de artículos donde estaré compartiendo todo lo necesario para utilizar, configurar y sacar el mayor provecho de Azure AD B2C.

En el artículo anterior terminamos de configurar los idiomas Inglés y Español de nuestro flujo de usuario y finalmente tenemos una versión productiva inicial.

En este post compartiré los detalles para configurar los JWT tokens e incluir los atributos de usuario, de forma que nuestros sitios web puedan obtener la información que necesitan y así tener una experiencia de usuario completa.

IMPORTANTE: vamos a construir sobre la base del post anterior, con lo cual es recomendable tener claros los conceptos y pasos allí detallados.

¿Qué es un JWT token?

Cuando desarrollamos aplicaciones (ya sea web, móviles o de escritorio) habrá ciertas funcionalidades que sólo usuarios autorizados pueden acceder, por ejemplo, el estado del carrito de compras en un e-Commerce.

También es habitual mostrar algunos datos del usuario autenticado, como puede ser el nombre y el apellido o la imagen de perfil en la barra de estado, o todos los atributos del usuario como por ejemplo en la pantalla de perfil de usuario.

Un JWT token es un mecanismo que permite resolver los dos puntos anteriores a la vez. Es una cadena de caracteres codificada en un sistema conocido como Base64 que está firmado digitalmente (lo cual garantiza que es auténtico y no ha sido adulterado) y además contiene información del usuario.

¿Cómo obtenemos un JWT token con Azure AD B2C?

Azure AD B2C - Diagrama de secuencia
Azure AD B2C – Diagrama de secuencia

Una vez el usuario completa el flujo de inicio de sesión o de registro en forma satisfactoria, Azure AD B2C recopila los atributos de usuario configurados para ser incluidos en el JWT token (Nombre, apellido, etc.) y genera un JSON (además contiene información adicional como expiración, fecha y hora de emisión del token, etc.).

Ese JSON se codifica en Base64 y se firma digitalmente. El resultado final es un JWT token que luego se retorna a la URI de redirección que configuramos cuando dimos los primeros pasos. En ese momento elegimos como URI de redirección https://jwt.ms.

No hay texto alternativo para esta imagen
Token – Atributos de usuario

Parte superior, el JWT token con su cabecera(información sobre el tipo de token y como fue firmado), cuerpo (información relacionada a la sesión y al usuario) y la firma digital.

Parte inferior, el JWT token decodificado en forma de JSON

En ambientes productivos o incluso en ambientes de pruebas, la URI de redirección debe ser una ruta válida dentro de nuestra aplicación web. Por el momento estamos utilizando https://jwt.ms solo con fines de demostración.

Configuración del JWT token

Cuándo realizamos las primeras configuraciones sobre nuestro flujo de usuario (Azure AD B2C: Primeros pasos y Azure AD B2C: Configuración de usuarios) seleccionamos qué atributos de usuario recolectar y cuáles incluir en el JWT token que se retorna a nuestra aplicación cliente.

No hay texto alternativo para esta imagen
Flujo de usuario – Configuración

Azure AD B2C nos permite tener un control muy granular sobre qué atributos de usuario exponer en los JWT tokens. Puede haber determinado tipo de información que si bien queremos recolectar, no queremos exponer en el token.

En aquel momento, bajo la columna Notificación de Devolución, sólo seleccionamos los atributos Nombre y Apellido.

Luego agregamos como nuevos atributos de usuario experienciahabilidadesinglésintereses relocalización, sin embargo no los hemos incluido en los tokens.

Incluir atributos de usuario en los JWT tokens

En el panel de configuración del flujo de usuario encontraremos dos secciones:

  • Atributos de Usuario: aquí podremos elegir qué atributos deben ser recolectados. Solo debemos seleccionar (o deseleccionar) los atributos deseados.
  • Notificación de la aplicación: en esta sección es donde vamos a elegir qué atributos de usuario deben ser incluidos en los JWT tokens.

Navegamos hasta la sección Notificaciones de la Aplicación y seleccionaremos los 5 atributos de usuario personalizados que creamos. Al finalizar guardamos los cambios.

No hay texto alternativo para esta imagen
Flujo de usuario – Configuración de atributos para incluir en los JWT token

Validación del JWT token

Como paso final sólo nos queda ejecutar el flujo de usuario e iniciar sesión o registrar un nuevo usuario. Una vez que Azure AD B2C valide el usuario, seremos redireccionados a la URI de Redirección https://jws.ms.

No hay texto alternativo para esta imagen
Token – Url

Azure AD B2C incluirá el token como parte de la URL en un parámetro llamado id_token.

En la sección Decoded Token vamos a ver los 5 nuevos atributos con los valores que haya ingresado el usuario al momento de registrarse.

No hay texto alternativo para esta imagen
Token – Validación de nuevos atributos

Si notamos que algunos atributos no son informados, debemos verificar que el usuario haya informado un valor. Azure AD B2C no incluye los atributos de usuario si estos no tienen valor o están vacíos.

Conclusiones

  • Además de una breve introducción a los JWT tokens, vimos con qué simplicidad podemos controlar qué información del usuario compartimos con nuestras aplicaciones.
  • Ya estamos listos para integrar nuestro Azure AD B2C en nuestra aplicación web.

Próximos pasos…

En el próximo post veremos cómo integrar nuestro flujo de usuario de Azure AD B2C con nuestra Web App. Veremos como capturaremos el token y extraer la información necesaria para poder visualizarla, generando entonces un circuito completo, desde el inicio de sesión hasta la pantalla de bienvenida.

Si necesitas asesoramiento o ayuda, si tenés dudas o no sabes cómo comenzar, o te interesa conocer/aprender sobre otros servicios de Azure, contáctame y vemos juntos como encontrar la solución que necesitas.

Personalización de idiomas en Azure AD B2C (Parte 3)

Este post forma parte de una serie de artículos donde estaré compartiendo todo lo necesario para utilizar, configurar y sacar el mayor provecho de Azure AD B2C.

En el post anterior (parte 2) vimos cómo configurar las traducciones de los atributos de usuario simples con el atributo Intereses, incluyendo el texto que se muestra al usuario y el hint.

En esta tercera y última parte, veremos cómo configurar las traducciones para los atributos de usuario personalizados complejos o colecciones como es el caso de Nivel de Inglés.

IMPORTANTE: vamos a construir sobre la base del post anterior, con lo cual es recomendable tener claros los conceptos y pasos allí detallados.

Contexto

Algunos de los atributos de usuario que Azure AD B2C ofrece son sólo un texto libre, como en el caso de Intereses, en el cual el usuario simplemente ingresa una o varias palabras.

Sin embargo, algunos atributos de usuario, como es el caso de Nivel de Inglés, requieren que el usuario seleccione uno o varios valores de una lista finita de opciones, donde cada opción tiene su propia traducción.

Para estos casos, no sólo debemos proveer de la traducción para el texto de referencia y el hint, si no que también debemos proveer la traducción correspondiente a cada una de las opciones asociadas.

Cuando configuramos los atributos de usuario incluimos el atributo inglés con una lista de opciones disponibles con su respectiva descripción que luego se ve reflejada en la pantalla de registro de usuario. En la siguiente imagen vemos a la izquierda la lista de valores con sus descripciones y a la derecha como lo ve el usuario.

Atributo Inglés – Valores y ComboBox

NOTA: Usaremos el atributo ingles como ejemplo para el resto del artículo, pero el procedimiento aplica de igual manera para el resto de los atributos de usuario que implican una lista o colección de valores.

Requerimientos

Todas las descripciones y opciones que son visibles al usuario deben ser traducidas en función del idioma seleccionado. Así por ejemplo la descripción del atributo ingles para el idioma Español debería ser Nivel de Inglés, mientras que para el idioma Inglés debería ser English Level.

En la siguiente tabla vemos cómo queda cada valor con su correspondiente traducción:

Nivel de Inglés – Tabla de valores por idioma

Con los requerimientos claros y bien definidos estamos listos para la implementación.

Implementación

Comenzaremos con la descripción y el hint del atributo en primer lugar. En este caso es igual al procedimiento que implementamos con el atributo intereses en el post anterior

Descripción y hint

  1. En la sección de idiomas del flujo de usuario seleccionamos el idioma Inglés y descargamos el archivo de recursos Página de registro con cuenta local.
Flujo de Usuario – Pagina de registro con cuenta local
  1. Abrimos el archivo de recursos y buscamos “ingles”. Modificamos los valores acorde a la tabla anterior, asegurándonos de modificar solo la sección que se encuentra dentro de LocalizedStrings.
Archivo de Recursos - Modificación
Archivo de Recursos – Modificación
  1. Este paso es opcional, pero para validar que los cambios fueron correctos, podemos subir el archivo y ejecutar el flujo de usuario para verificar que el atributo ingles refleje los cambios esperados para el idioma Inglés. La descripción del atributo debe decir English Level, no así la lista de opciones.
Nivel de Inglés – Descripción

Lista de opciones

Ahora procedemos con la implementación de la lista de opciones disponibles, vamos a editar el mismo archivo de recursos y repetiremos el paso 2, solo que esta vez modificaremos los valores dentro de la sección LocalizedCollections.

Solo es necesario modificar la propiedad name de cada opción, la propiedad value se mantendrá sin modificaciones:

Archivo de Recursos - Modificación Colección
Archivo de Recursos – Modificación Colección

Subimos el archivo y ejecutamos el flujo de usuario para validar los cambios. Esta vez el combo de Nivel del Inglés debería verse de la siguiente forma:

Nivel de Inglés – Descripción de valores

Al editar las colecciones como lo hicimos en el paso anterior, también podemos agregar o eliminar ítems de la lista. Esto nos da la libertad de poder decidir qué opciones utilizar para cada idioma.

Este mismo procedimiento lo repetiremos también para el idioma Español, editando el archivo de recursos correspondiente. De esta forma el flujo de usuario quedará completo para ambos idiomas.

Azure AD B2C Localized Collections

La sección Localized Collections es un arreglo (array) JSON que contiene lista de elementos utilizados para crear los atributos de usuario del tipo colección. Tiene su contraparte en la sección Localized Strings identificado por la propiedad ElementId.

En esta sección encontraremos todas las listas correspondientes a los atributos usuarios del tipo colección.

¿Atributos del tipo booleanos con Azure AD B2C?

En algunos casos vamos a necesitar opciones del tipo Si o No o Verdadero o Falso cuyo valor debe ser tratado como booleano, es decir, independientemente de la descripción el valor debe ser “true” o “false”.

Esto es fácilmente realizable utilizando el siguiente procedimiento:

  1. Crear el atributo de usuario indicando como tipo de dato booleano (ver articulo Configuración de Usuarios).
  2. Configurar el flujo de usuario para mostrar el nuevo atributo como RadioSingleSelect.
  3. Modificar la sección LocalizedColleccions del atributo en cuestión de la siguiente forma:

Conclusiones

  • Si bien la configuración de idioma para atributos personalizados requiere un poco más de trabajo, no deja de ser simple.
  • No hay necesidad de utilizar herramientas adicionales, solo con un editor de texto es suficiente. Azure AD B2C ofrece un portal muy intuitivo que hace muy simple su configuración.

Próximos pasos…

En el próximo post veremos cómo configurar JWT tokens para incluir la información del usuario en forma de claims.

Si necesitas asesoramiento o ayuda, si tenés dudas o no sabes cómo comenzar, o te interesa conocer/aprender sobre otros servicios de Azure, contáctame y vemos juntos como encontrar la solución que necesitas.

Personalización de idiomas en Azure AD B2C (Parte 2)

Este post forma parte de una serie de artículos donde estaré compartiendo todo lo necesario para utilizar, configurar y sacar el mayor provecho de Azure AD B2C.

En el post anterior (parte 1) vimos los conceptos principales relacionados a la configuración de idiomas, pero nos quedó pendiente la configuración de aquellos atributos de usuarios personalizados.

En esta segunda parte, veremos cómo configurar las traducciones para todos los atributos de usuario personalizados simples.

IMPORTANTE: vamos a construir sobre la base del post anterior, con lo cual es recomendable tener claros los conceptos y pasos allí detallados.

Contexto

Como vimos en la parte 1, todas las configuraciones inherentes a idiomas corresponden al flujo de usuario. Cada flujo de usuario esta compuesto por una o más pantallas, por ejemplo:

  • Inicio de sesión + recupero de contraseña.
  • Inicio de sesión + registro de usuario + recupero de contraseña

Todas las palabras y atributos de usuario estándares tienen su correspondiente traducción en forma predeterminada, sin embargo los atributos de usuario personalizados deben ser traducidos manualmente. Lo mismo sucede en aquellos casos donde queremos utilizar una traducción diferente a la estándar por cuestiones culturales idiomáticas.

Archivo de recursos de Azure AD B2C

Dentro de Azure AD B2C los archivos de recursos son archivos de texto en formato JSON donde se disponen todas las traducciones correspondientes a una pantalla para un idioma específico, es decir, cada idioma tiene un archivo de recursos por pantalla. Contiene generalmente dos secciones, LocalizedStrings LocalizedCollections

Archivo de recursos – Descripción
  • LocalizedStringslista de elementos individuales.
  • LocalizedCollectionslista de elementos que forman grupos, como por ejemplo,  ComboBox MultiSelect.

Veamos un ejemplo utilizando la pantalla de inicio de sesión para el idioma Inglés y para el idioma Español:

Personalización de Idiomas – Comparación Inglés
Personalización de Idiomas – Comparación Español

Como podemos apreciar, los atributos de cada elemento dentro del JSON son exactamente iguales para ambos idiomas, excepto el atributo Value, el cual contiene la traducción correspondiente al idioma seleccionado.

Funcionamiento del archivo de recursos

Cada archivo de recursos contiene la lista de elementos completa necesaria para la traducción de toda la página. Para poder cambiar las traducciones debemos proceder de la siguiente forma:

  1. Descargar el archivos de recursos
  2. Editar los valores deseados
  3. Subir el archivo con las modificaciones

Cada elemento contiene, además del atributo Value (junto con otros más que no veremos en este artículo), un atributo Override, el cual indica que este elemento tiene un valor que debe ser actualizado al subirlo.

Si queremos cambiar el texto ¿No tiene una cuenta? por algo como ¿Quieres abrir una cuenta?, el elemento debería ser modificado de la siguiente forma:

Archivo de Recursos – Edición
Validaciones
Validaciones

Es muy importante no olvidar marcar las entradas modificadas como Override, caso contrario recibiremos un error.

Aplicando las traducciones para elementos simples

Siguiendo el procedimiento descrito anteriormente, el primer paso es descargar el archivo de recursos correspondiente a la pantalla e idioma que necesitamos modificar.

1- Descargar el archivo de recursos

Flujo de Usuario – Idiomas

Para descargar el archivo de recursos nos dirigimos al flujo de usuario y en la sección Idiomas seleccionamos el idioma deseado.

Debido a que los atributos de usuarios personalizados que agregamos cuando realizamos los primeros pasos estaban en castellano, como por ejemplo Intereses y Años de experiencia, necesitamos la correspondiente traducción al idioma Inglés. Es por eso que en este ejemplo seleccionamos el idioma Inglés.

Flujo de Usuario – Descarga de Archivo de Recursos

Se desplegará sobre el sector derecho una ventana con la lista de pantallas disponibles para el flujo de usuario. Buscamos y desplegamos la sección Página de registro con cuenta local.

Aquí podemos descargar el archivo de recursos completo haciendo clic en la opción Descargar valores predeterminados (en). El archivo descargado tendrá un nombre muy largo, que incluye el nombre del tenant, el nombre del flujo de usuario, el nombre de la pantalla y el idioma.

Si ya hemos subido algún archivo de recursos previamente, veremos también la opción Descargar invalidaciones, la cual nos permite obtener un archivo de recursos solo con los elementos que fueron modificados (con la propiedad Override: true), en lugar del archivos de recursos completo.

2- Editar el archivo de recursos

Como mencionamos en párrafos anteriores, generalmente sólo necesitamos concentrarnos en los atributos de usuarios personalizados, ya que los atributos de usuario estándares cuenta con traducción predeterminada. Para este ejemplo, vamos a trabajar con el atributo Intereses.

Abrimos el archivo de recursos que descargamos en el paso anterior y buscamos la palabra intereses. Encontraremos dos entradas como las siguientes:

Archivo de recursos - Original
Archivo de recursos – Original

El primer elemento es el texto visible sobre el campo cuando está vacío, el segundo es un texto de ayuda que se muestra cuando paramos el cursor por arriba, generalmente conocido como hint. Editamos los valores de la siguiente forma:

Archivo de recursos – Editado

3- Subir el archivo con las modificaciones

Subir archivo de recursos
Subir archivo de recursos

Ya con el archivo de recursos editado, volvemos a la lista de pantallas disponibles del flujo de usuario para el idioma Inglés, buscamos y desplegamos la sección Página de registro con cuenta local.

Finalmente clicamos en el botón para subir el archivo y seleccionamos el archivo que editamos.

Azure AD B2C validará y aplicará los cambios automáticamente si y solo si no detecta ningún error, caso contrario nos mostrará un error sin aplicar ningún cambio.

Prueba de los cambios

Para poder probar los cambios recién aplicados, solo debemos ejecutar el flujo de usuario, activar los ui_locales y seleccionar el idioma Inglés.

Si todo salió veremos el campo intereses, pero esta vez con la descripción Interests. Si paramos el mouse por sobre el campo durante unos segundos, veremos además el hint con el texto Something you are interested in.

Personalización de Idiomas – Antes y Después

Conclusiones

  • A pesar de ser un artículo un poco extenso, es realmente muy simple generar traducciones.
  • No requerimos habilidades ni conocimientos de programación, incluso si nunca antes hemos trabajado con JSON, solo necesitamos editar texto.

Próximos pasos…

En la parte 3 de este artículo te voy a contar cómo traducir atributos de usuario personalizados complejos (colecciones) como Listas de selección múltiple o ComboBox.

Si necesitas asesoramiento o ayuda, si tenés dudas o no sabes cómo comenzar, o te interesa conocer/aprender sobre otros servicios de Azure, contáctame y vemos juntos como encontrar la solución que necesitas.

Personalización de idiomas en Azure AD B2C (Parte 1)

Este post forma parte de una serie de artículos donde estaré compartiendo todo lo necesario para utilizar, configurar y sacar el mayor provecho de Azure AD B2C.

Continuando con la personalización de la marca e identidad que hicimos en el post anterior, donde configuramos y personalizamos los atributos de usuario, te contaré cómo hacer nuestra experiencia de usuario multi idioma.

En esta primera parte veremos los conceptos principales, aprenderemos cómo funciona y cómo utilizar múltiples idiomas. En la parte 2 nos enfocaremos en los atributos de usuario personalizados.

IMPORTANTE: vamos a construir sobre la base del post anterior, con lo cual es recomendable tener claros los conceptos y pasos allí detallados.

Contexto y Requerimientos

En un contexto totalmente globalizado como el actual, es habitual que las aplicaciones web crucen las fronteras para alcanzar usuarios cuyo idioma principal difiere del idioma original. Es por esto, que la mayoría de las aplicaciones de hoy en día se diseñan para soportar múltiples idiomas.

Azure AD B2C soporta 36 idiomas e incluye la posibilidad de configurar un idioma totalmente personalizado si fuese requerido. Además podemos agregar nuestras propias traducciones para todos aquellos atributos de usuario personalizados que hayamos agregado.

¿Cómo funcionan los idiomas en Azure AD B2C?

Al iniciar el flujo de usuario, podemos indicar como parte de los parámetros query-string el idioma que queremos utilizar, Azure AD B2C hará la traducción correspondiente. Si no se especifica en forma explícita un idioma entonces se utilizará el idioma requerido por el browser, si el browser utiliza un idioma no soportado, finalmente se utilizará el idioma configurado como predeterminado o de facto.

Tener en cuenta que cada idioma se configura a nivel de Flujo de Usuario y debe haber siempre un idioma predeterminado o de facto.

Todos los atributos de usuario estándares tienen su traducción correspondiente en todos los idiomas soportados. No obstante, tendremos que proveer traducciones manualmente para todos aquellos atributos de usuarios personalizados.

Configuración de idioma en Azure AD B2C

Lo primero que debemos realizar es navegar hasta nuestro flujo de usuario e ir a la sección Idiomas, una vez allí habilitar la personalización de idiomas.

Flujo de Usuario – Habilitar personalización de idiomas

Una vez habilitada la opción de personalización, podremos seleccionar la lista de idiomas disponibles. Como mencionamos anteriormente, siempre debe haber un idioma seleccionado como predeterminado, en este caso es el idioma Inglés.

Idioma – Habilitar idioma

Para habilitar y/o configurar otro idioma sólo basta con seleccionar el idioma deseado, en este caso Español, y marcar la opción Habilitado.

Tenemos la posibilidad de seleccionar este idioma como predeterminado o de facto y en la sección de Archivos de Recursos de nivel de página podemos personalizar como traducir cada elemento (lo veremos en la parte 2).

Una vez guardados los cambios, el idioma Español estará disponible.

Idioma – Habilitar ui_locales

Para probar o verificar esta configuración, tenemos que ejecutar el flujo de usuario. Esta vez la sección de localización estará disponible.

Activar la opción Especificar ui_locales nos permite seleccionar un idioma en forma explícita, caso contrario se utiliza el idioma predeterminado, en este caso Inglés.

Copiando y pegando en un block de notas la URL que se genera con cada idioma podemos comparar y analizar como funciona ui_locales.

¿Cómo funciona ui_locales?

ui_locales consiste en un parámetro que se adiciona a la URL de conexión del flujo de usuario que es usado por Azure AD B2C para traducir cada página al idioma correspondiente.

Comparando las URLs que copiamos y pegamos anteriormente podemos observar los distintos valores que va tomando el parámetro (generalmente es el último parámetro de la URL), incluso podemos modificar manualmente y utilizar un valor inexistente como en los siguientes ejemplos:

Flujo de Usuario – Comparación URLs

Debido a que el idioma predeterminado configurado hasta el momento es Inglés, tanto en el caso de un idioma inexistente como en el caso de un idioma deshabilitado se comportarán idénticamente al idioma Inglés.

Para en el caso implícito (donde no se incluye el parámetro ui_locales), depende del idioma configurado localmente para el usuario. En mi caso, el idioma configurado en mi computadora es Inglés.

Navegando a cada una de las URLs anteriores, podemos observar lo siguiente:

  • Español (ui_locales=es)
Inicio de sesión – Español
  • Inglés (ui_locales=en)
  • Inexistente o no habilitado (ui_locales=xx)
  • Implícito (sin ui_locales)
Inicio de sesión – Inglés y por defecto

Podemos apreciar como absolutamente todo el formulario se traduce sin ningún tipo de problemas en forma automática. Sin embargo, el Registro de usuario o Sign Up tiene una traducción parcial para el idioma Inglés:

Registro de Usuario – Sin configuración de traducción
  • Los atributos de usuario estándar (cómo Dirección de Email) aparecen correctamente traducidos al Inglés como es esperado
  • Los atributos de usuario personalizados (cómo habilidades) aparecen es Español incluso cuando el idioma seleccionado es Inglés.

Hemos hecho un muy buen progreso, y no sólo aprendimos como configurar distintos idiomas sino que también aprendimos como funciona la traducción de Azure AD B2C, pero todavía nos falta un paso más para poder tener una traducción completa.

Conclusiones

  • ¡Gran variedad de idiomas disponibles! 36 opciones a disposición cubren un espectro muy amplio de opciones listas para usar.
  • ¡Flexibilidad! Seleccionar entre un idioma u otro, o incluso utilizar el idioma configurado localmente para el usuario es tan simple como agregar un parámetro extra en la URL de conexión.

Próximos pasos…

En la parte 2 de este artículo te voy a contar cómo traducir atributos de usuario personalizados. ¡¡¡No te lo pierdas!!!

Si necesitas asesoramiento o ayuda, si tenés dudas o no sabes cómo comenzar, o te interesa conocer/aprender sobre otros servicios de Azure, contáctame y vemos juntos como encontrar la solución que necesitas.

Azure AD B2C: Personalizando nuestra marca

Este post forma parte de una serie de artículos donde estaré compartiendo todo lo necesario para utilizar, configurar y sacar el mayor provecho de Azure AD B2C.

Continuando con lo que vimos en el post anterior, donde configuramos y personalizamos los atributos de usuario, te contaré cómo personalizar el estilo del flujo de usuario para aplicarle nuestra marca y lucir nuestros logos y fondos de pantalla.

IMPORTANTE: vamos a construir sobre la base del post anterior, con lo cual es recomendable tener claros los conceptos y pasos allí detallados.

Contexto y Requerimientos

Cuando se trata de una plataforma web, ya sea un e-commerce, un blog o una página de presentación, uno de los aspectos más importantes es la identidad del sitio. Esto se suele ver reflejado a través de la paleta colores, logotipos y fondos de pantalla (backgrounds).

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

Hasta el momento las páginas de Inicio de Sesión y Registro tienen el estilo estándar que Azure AD B2C provee, el cual no tiene ninguna relación con la identidad de nuestro sitio web.

Es por eso que uno de los primeros requerimientos a satisfacer para una salida a producción aceptable es aplicar nuestros logos y fondos (backgrounds), de forma que los usuarios no perciban diferencia alguna entre Azure AD B2C y el sitio original.

En este post nos vamos a enfocar en los aspectos básicos del diseño, como son los logos y el fondo de pantalla. En futuros posts, veremos cómo podemos crear algo totalmente personalizado, incluyendo HTML y CSS.

Personalización

Ahora sí, hagamos lo que más nos gusta y pongamos las manos a trabajar.

Personalizar marca de empresa
Personalizar marca de empresa

Para comenzar debemos dirigirnos a la sección de Personalización de marca de empresa. Si es la primera vez que accedemos, veremos la opción Configurar. Si ya tenemos configuradas personalizaciones, veremos como opción Nuevo idioma. Esto se debe a que podemos tener tantas personalizaciones como idiomas disponibles, por ejemplo, el fondo de pantalla podría contener texto específico según el idioma del usuario.

Sobre la derecha veremos un panel para configurar cada elemento disponible. Veamos de que se trata cada uno.

Elementos

Configurar personalización de marca
  1. Idioma: Si es la primera personalización que realizamos esta opción estará deshabilitada con el texto Predeterminado, de lo contrario podremos seleccionar de una lista el idioma correspondiente.
  2. Imagen de fondo: Es el fondo de pantalla. Prestar especial atención a las características que debe tener: 1920 x 1080, tamaño máximo de 300 KB y en formato .png, .jpg o .jpeg.
  3. Logotipo/Banner: Imagen para mostrar en la pantalla de inicio de sesión y registro. Características: 280 x 60, tamaño máximo de 10 KB y en formato .png, .jpg o .jpeg.
  4. Sugerencia del nombre de usuario: Este campo lo dejaremos vacío ya que no lo usaremos, es de utilidad cuando utilizamos nombre de usuario en lugar de email para registrar usuario.
  5. Texto de la página de inicio de sesión: Este campo lo dejaremos vacío ya que no lo usaremos, es de utilidad para usuarios de Windows 10 y Azure AD.
  6. Color de fondo de la página de inicio de sesión: Es el color a utilizar en caso de que las imágenes no puedan ser cargadas (por ejemplo, por problemas de conexión).
  7. Imagen de logotipo cuadrado: Este campo lo dejaremos vacío ya que no lo usaremos, es de utilidad para usuarios de Windows 10 y Azure AD.
  8. Imagen de logotipo cuadrado, tema oscuro: Este campo lo dejaremos vacío ya que no lo usaremos, es de utilidad para usuarios de Windows 10 y Azure AD.
  9. Mostrar la opción para mantener la sesión iniciada: Este campo lo dejaremos con su valor por defecto, es de utilidad para usuarios de Windows 10 y Azure AD.

Validación

Flujo de validación de cambios
Flujo de validación de cambios

Ya estamos listos para validar los cambios que realizamos. Para esto tenemos que navegar hasta la sección Flujos de usuario, seleccionar el flujo de usuario que creamos cuando dimos los primeros pasos y finalmente ejecutar la opción Ejecutar flujo de usuario.

Sobre el panel que se despliega a la derecha, presionamos el botón para ejecutar con las opciones por defecto.

Inicio de sesión actualizado

¡¡¡Increíble!!! Nuestra página de inicio de sesión ahora luce con un estilo propio haciendo que la experiencia de usuario sea mucho más natural y fluida.

Estamos muy cerca de tener una versión productiva, con estilo propio y con atributos de usuario a nuestra medida y necesidad. Solo nos queda un sólo tópico para analizar (por ahora) y son las plantillas predeterminadas.

Plantillas predeterminadas

Azure AD B2C ofrece 3 plantillas predeterminadas listas para usar. Estas plantillas mantienen el mismo estilo (fondo de pantalla y logotipo) que vimos en el apartado anterior, pero cambian (sutilmente) cuestiones de diseño como la orientación y el estilo de los controles como cuadros de texto y botones.

Selección de plantilla
Selección de plantilla

Para seleccionar cambiar o configurar el estilo de plantilla predeterminado, debemos navegar hasta la sección Diseños de Página del Flujo de Usuario y luego clicar sobre la acción Plantilla. Sólo basta con seleccionar la plantilla deseada y esperar a que se apliquen los cambios.

Comparemos los 3 estilos disponibles:

Azul Océano
Azul Océano
  • Azul océano: Esta es la plantilla predeterminada y por consiguiente la más utilizada. Es posiblemente la más moderna.
Gris pizarra
  • Gris pizarra: Muy similar a la plantilla anterior, cambia un poco el ordenamiento y el estilo de los campos de entrada de texto.
Clásico
Clásico
  • Clásico: Esta plantilla fue la primera (y en un comienzo la única) disponible. Responde al antiguo estilo de las plataformas de Microsoft/Azure.

Estas tres plantillas son las que están disponibles al momento de escribir el artículo, pero como todos los productos de Azure, se encuentran en continua mejora. Es posible que se agreguen o eliminen plantillas en el futuro.

Conclusiones

  • ¡Diseños simples y aceptables! A pesar de que los cambios que realizamos son muy básicos, con solo unos clics podemos darle identidad a nuestra experiencia de usuarios.
  • ¡Sin necesidad de HTML ni CSS! Si bien en muchos casos vamos a necesitar aplicar un diseño mucho más personalizado utilizando HTML, CSS y hasta quizás JavaScript, solo con un par de imágenes son suficientes para tener un MVP (Mínimo Producto Viable) o incluso una primer versión productiva de nuestra aplicación

Próximos pasos…

En el próximo artículo te voy a contar cómo configurar distintos idiomas, incluyendo las traducciones para los atributos de usuario personalizados adicionales como Nivel de Inglés y Experiencia. ¡¡¡No te lo pierdas!!!

IMPORTANTE: a modo de ejemplo, tomé dos imágenes de la web que en principio son libres y no tienen derecho de autor. Si no es así y crees que el autor podría no autorizar su uso, te invito a que me dejes un mensaje para solicitar la autorización pertinente o indicarme dejar de utilizar las imágenes cuanto antes.

Azure AD B2C: Configuración de usuarios

Este post forma parte de una serie de artículos donde estaré compartiendo todo lo necesario para utilizar, configurar y sacar el mayor provecho de Azure AD B2C.

Continuando con lo que vimos en el post anterior, donde establecimos los tres primeros pasos necesarios para comenzar con Azure AD B2C, te contaré cómo configurar y modelar nuestro usuario para poder recolectar toda la información necesaria que nuestra app necesita. Como siempre, vamos a ir al detalle y paso a paso.

IMPORTANTE: vamos a construir sobre la base del post anterior, con lo cual es recomendable tener claros los conceptos y pasos allí detallados.

Contexto y Requerimientos

Antes de comenzar a realizar cualquier tipo de configuración, definamos con claridad cuál es la necesidad que buscamos satisfacer.

Estamos diseñando una aplicación para conectar empresas con personas del mundo IT, para esto, generaremos recomendaciones en base a la información del perfil del usuario, como años de experiencia y nivel de Inglés. Claro que en la vida real esto no es suficiente, pero a fines prácticos y en función del objetivo del artículo, estamos bien.

Necesitamos recolectar la siguiente información:

  • Nombre y apellido: estos campos serán de texto libre. Obligatorios.
  • Nivel de inglés: lista con las opciones No hablo, Escribo pero no hablo, Escribo y hablo un poquito, Me siento cómodo teniendo una conversación, Soy bilingüe. El usuario seleccionará una, y solo una, opción. Obligatorio.
  • Años de experiencia: lista con las opciones No tengo experienciaMenos de 1 añoEntre 1 y 5 añosMás de 5 años. El usuario seleccionará una, y solo una, opción. Obligatorio.
  • Habilidades: lista con las opciones Desarrollo FEDesarrollo BEIngeniero de DatosQAScrumManagement. El usuario podrá seleccionar mas de una opción. Obligatorio.
  • Abierto a relocalización: Si o No.
  • Intereses: Texto libre opcional.

Esta combinación de campos cubre todas las opciones que Azure AD B2C ofrece, de forma que podamos implementar prácticamente cualquier requerimiento que nuestra aplicación describa.

Implementación

Cabe destacar que la implementación puede dividirse en dos aspectos bien definidos:

  • Perfil del usuario: definición del perfil del usuario, que incluye los campos y sus valores. Estos valores pueden ser de tres tipos posibles: cadena de caracteres (string), booleanos (bool) o enteros (int)
  • Presentación del perfil del usuario: presentación de los distintos atributos que tiene un usuario.

Por ejemplo, cuando presentamos el atributo Nivel de Inglés en la pantalla de Registro, utilizaremos el valor No Hablo, sin embargo el valor que será guardado en la base de usuario será “nada”. Azure AD B2C será el encargado de realizar dicha traducción.

Perfil del Usuario

El primer paso es definir los atributos del perfil del usuario. Para esto, debemos navegar hacia la sección Atributos de Usuario de la pantalla de inicio de Azure AD B2C. Aquí veremos la lista completa de atributos del perfil del usuario, incluyendo los atributos base y los personalizados. También tendremos disponible la opción para agregar atributos nuevos.

Lista de atributos de usuario
Lista de atributos de usuario

Vamos a agregar todos los atributos que necesitamos. Nombre y Apellido son parte de los atributos base. No necesitamos volver a agregarlos.

Nuevo atributo de usuario
Nuevo atributo de usuario

Al presionar Agregar, se desplegará un formulario con tres propiedades:

  • Nombre: Es el nombre “interno” del atributo. No puede contener espacios en blanco ni caracteres especiales
  • Tipo de Datos: Cadena (string), Booleano (bool) o Int (integer)
  • Descripción: Una breve descripción, no será visible por los usuarios finales.

Para la implementación de nuestro perfil de usuario, agregaremos los siguientes atributos:

Tabla atributos de usuario
Tabla atributos de usuario

Veamos con un poco más de detalle la tabla anterior tomando como ejemplo los atributos Nivel de Inglés y Años de Experiencia:

Tabla valores atributos de usuario
Tabla valores atributos de usuario

Al finalizar, la lista de atributos debería verse de la siguiente forma:

Lista de atributos de usuario actualizada
Lista de atributos de usuario actualizada

Si ejecutamos el Flujo de Usuario que creamos en el post anterior (Azure AD B2C: Primeros Pasos) e intentamos registrarnos, notaremos que todavía no vemos los nuevos atributos disponibles. Eso se debe a que todavía nos falta configurar la presentación de dichos atributos, y eso es parte del Flujo de Usuario.

Presentación del perfil del usuario

La presentación del perfil del usuario es una responsabilidad del flujo de usuario. Podemos tener más de un flujo de usuario, en función de la necesidad, y cada flujo de usuario puede requerir un grupo diferentes de atributos.

Lista de flujos de usuario
Lista de flujos de usuario

El primer paso que debemos realizar es configurar los atributos de usuario que nuestro flujo debe solicitar. Para esto, debemos navegar hasta el flujo de usuario que creamos (si seguimos los pasos tal cual el post anterior el nombre del flujo de usuario B2C_1_InicioSesionConRegistro).

Luego, en la sección de Atributos de Usuario, solo tenemos que seleccionar los atributos que definimos como requerimiento.

Atributos de usuario por flujo de usuario
Atributos de usuario por flujo de usuario

¡¡¡Si ahora ejecutamos el flujo de usuario e intentamos hacer un registro veremos los nuevos atributos disponibles!!!

¡¡¡Increíble!!! Venimos progresando a pasos agigantados, solo nos falta un pequeño paso más.

Azure AD B2C - Formulario de registro
Diseño preliminar
Formulario de registro

Lo primero que podemos notar es que todos los campos son de texto libre. Además, ninguno de ellos es obligatorio. Enseguida nos vamos a meter de lleno para darle el estilo que estamos buscando, pero antes, veamos que opciones tenemos disponibles para darle estilo y diseño a nuestra página.

Diseño de Páginas (Look & Feel) en Azure AD B2C

En la sección Diseño de Página es donde podremos configurar cuestiones inherentes a como se visualiza el Registro de Usuario, incluyendo orden de los campos, obligatoriedad, etiquetas y tipo de entrada (texto, selección simple, etc.).

Azure AD B2C ofrece 4 tipos de entrada o input:

  • Cuadro de texto libre
  • Selección simple tipo radio-buttons. Permiten seleccionar una sola opción. Muy útiles para grupos de pocas opciones, como por ejemplo Si-No o Verdadero-Falso.
  • Selección múltiple tipo check-box. Permiten seleccionar cero, una o más opciones.
  • Selección simple tipo combo-box. Permiten seleccionar una sola opción de una lista desplegable. Ideales cuando la lista de opciones es extensiva.

A excepción del cuadro de texto, los otros tipos requieren una lista de opciones compuestas de un par texto-valor donde el texto es lo que será visible para el usuario y el valor será lo que finalmente se guarde como atributo del usuario.

Con estos tipos de entrada o inputs más un poco de imaginación vamos a armar nuestro formulario de registro. Veamos qué nos conviene utilizar en base a los requerimientos que tenemos.

  • Nombre, Apellido e Intereses son de texto libre, para lo cual usaremos el Cuadro de Texto.
  • Nivel de inglés y Años de experiencia son listas de selección simple. En este caso usaremos Selección simple tipo combo-box.
  • Habilidades es también una lista pero de selección múltiple. Para este caso usaremos Selección múltiple tipo check-box.
  • Abierto a relocalización es una lista con solo dos opciones, en este caso la opción más conveniente es Selección simple tipo radio-buttons.

¿Radio-buttons o Combo-box? Cuando la cantidad de opciones es mayor a 3 es recomendable utilizar el estilo Combo-box, de esa forma el diseño presenta una experiencia de usuario un poco más amigable.

Azure AD B2C - Diseño de pagina del flujo de usuario
Diseño de pagina del flujo de usuario

Configuración de página de registro

Para poder comenzar a configurar el diseño de página de nuestro flujo de usuario navegamos a la sección de Diseño de Página y luego seleccionaremos el diseño Página de registro con cuenta local. Podremos ver en el panel inferior la lista de los atributos de los atributos que configuramos para el flujo con sus valores por defecto. Para poder editarlos, solo tenemos que clicar en el valor que queremos modificar.

Atributos de usuario por flujo de usuario, Opcional
Atributos de usuario por flujo de usuario, Opcional

El primer cambio que realizaremos es hacer los atributos obligatorios, solo debemos hacer clic en la columna Opcional de cada atributo y cambiarlo por la opción Sí (Excepto Intereses).

Atributos de usuario por flujo de usuario, Etiqueta
Atributos de usuario por flujo de usuario, Etiqueta

El segundo cambio es editar las etiquetas con los valores que queremos que sean presentados al usuario. Nos enfocaremos solo en las etiquetas de los nuevos atributos y dejaremos con sus valores por defecto a Nombre, Apellido e Email. Todo esto lo veremos más en detalle y en forma uniforme cuando veamos cómo configurar múltiples idiomas.

Español vs Inglés: por cuestiones prácticas en este tutorial intenté usar 100% español. Pero debemos tener en cuenta que hay propiedades predefinidas que están en inglés, como el caso de Apellido, que internamente se guarda como Surname. Es recomendable mantener el inglés para los valores internos, y configurar mediante idiomas como mostramos la información al usuario

El último cambio (¡y el más divertido!) es configurar el tipo de entrada para cada atributo con sus respectivos valores. Los atributos que debemos modificar son Abierto a Relocalización, Nivel de Inglés, Años de Experiencia y Habilidades. A diferencia de los cambios anteriores, al hacer clic sobre la columna Tipo de entrada de usuario se desplegará una ventana sobre la derecha para editar el campo. A continuación tenemos una tabla ilustrativa que podemos usar como guía.

Atributos de usuario - Tabla de valores
Atributos de usuario – Tabla de valores

Ejecución y validación

¡¡¡Felicitaciones!!! Hemos terminado exitosamente de personalizar el diseño de la página de Registro de Usuario y estamos listos para ver cómo luce. En primer lugar, corroboramos que cada atributo tenga el tipo de entrada correcta, luego guardamos los cambios y finalmente ejecutamos el flujo de usuario.

Atributos de usuario por flujo de usuario, Tipo de Entrada
Atributos de usuario por flujo de usuario, Tipo de Entrada
Azure AD B2C - Formulario de registro
Diseño final
Formulario de registro – Diseño final

Si seguimos todos los pasos meticulosamente, así se verá el Registro de Usuario. ¿Increíble verdad?

Tenemos nuestros atributos personalizados obligatorios, con sus correspondientes descripciones y sus tipos de entradas acorde a los requerimientos definidos.

Un concepto que quiero reforzar es que no hemos necesitado escribir ni una sola línea de código para crear esta hermosa experiencia de usuario.

Y por supuesto, tampoco necesitamos ningún tipo de herramienta especial o ambiente de desarrollo. Solo desde el navegador. Este es uno de los puntos más destacables de Azure AD B2C, y es que podemos tener una experiencia de registro e inicio de sesión de usuarios totalmente personalizable sin necesidad de contar con grandes conocimientos en programación y utilizando sólo nuestro navegador, lo que hace una verdadera experiencia Business To Clients.

Conclusiones

  • ¡Listo para usar! Azure AD B2C nos ofrece un abanico muy amplio de opciones listas para usar, de forma que con solo unos clics tenemos lo que necesitamos
  • ¡Muy intuitivo! El portal ofrece descripciones y formularios muy simples y fáciles de entender.

Próximos pasos…

En el próximo artículo te voy a contar cómo darle el estilo y personalización de nuestra marca, incluyendo logos y fondos. ¡¡¡No te lo pierdas!!!

Si necesitas asesoramiento o ayuda, si tenés dudas o no sabes cómo comenzar, o te interesa conocer/aprender sobre otros servicios de Azure, contáctame y vemos juntos como encontrar la solución que necesitas.

Azure AD B2C: Primeros pasos y configuración inicial

Hace unas pocas semanas escribí este artículo contando como Azure AD B2C fue una pieza fundamental para lograr que vOpen Tech 2020 se transforme de ser una conferencia presencial a una conferencia totalmente virtual. El gran desafío era hacerlo en poco tiempo y a un bajo costo.

En este artículo te contaré, paso a paso (incluyendo capturas de pantalla), en forma simple y ágil, como comenzar a utilizar y configurar Azure AD B2C. Luego veremos en sucesivos artículos como ir personalizando nuestro Azure AD B2C para adaptarlo a nuestra marca y necesidad.

IMPORTANTE: para poder comenzar a utilizar cualquier recurso de Azure es necesario contar con una cuenta, incluso para utilizar servicios gratuitos. Si todavía no tienes una cuenta, puedes comenzar creando una cuenta gratis aquí.

Los pasos a seguir

Para poder comenzar a utilizar Azure AD B2C necesitamos realizar los siguientes 3 pasos:

  1. Crear una instancia
  2. Registrar una aplicación
  3. Crear un flujo de usuarios

Sin más preámbulos, comencemos a trabajar.

1. Crear la instancia

Lo primero que debemos hacer es crear una nueva instancia o tenant de Azure AD B2C, la cual albergará la base de datos de usuarios, configuraciones, aplicaciones, etc. Para esto hacemos clic en la opción Crear un recurso, el portal nos ofrecerá la opción de recorrer las diferentes categorías o podemos utilizar el buscador tipeando “b2c”.

Azure AD B2C – Creación de Recurso
  1. Azure Active Directory B2C será una de las primeras opciones, haremos clic en esta opción.
  2. Luego, en la página de bienvenida clicaremos en el botón crear.
  3. Antes de ir a pantalla de creación, el portal nos ofrecerá la opción de Crear un nuevo tenant o vincular uno existente a una suscripción. Tomamos la primer opción.

Dentro del ecosistema de Azure AD, una instancia se denomina tenant. Puede que se encuentre también como inquilino si el idioma es español.

Azure AD B2C – Creación y configuración de Instancia

Revisión y creación

Finalmente, en la pantalla de creación, completamos los datos requeridos y presionamos el botón para revisar y crear:

  • Nombre de la organización: es el nombre para mostrar e identificar el tenant fácilmente en caso de poseer más de uno.
  • Nombre de dominio inicial: es el nombre del subdominio dentro de Microsoft que formará parte de la ruta o DNS. En este caso, como se aprecia en la imagen, el dominio final será linkedinazureadb2c.onmicrosoft.com. Una vez creado el tenant, se puede configurar un dominio propio, como por ejemplo contoso.com.
  • País o región: centro de datos (data center) donde se desplegaran todos los recursos necesarios. Idealmente, se debe buscar la región mas cercana a los usuarios. Por ejemplo, si nuestra aplicación esta orientada a usuarios en Argentina, la recomendación es la región de Brasil.
  • Suscripción: nuestro tenant necesita estar asociado a una subscripción por temas de facturación, en caso de contar con mas de una, aquí es donde podemos elegir.
  • Grupo de recursos: el grupo de recursos para nuestro tenant. Los grupos de recursos son organizadores lógicos, no representan servicios ni recursos en si mismos, solo nos sirven para agrupar y organizar. Para crear un nuevo grupo de recursos podemos seguir este breve instructivo.

El proceso de creación puede demorar unos minutos, una vez finalizado, lo único que nos resta por hacer es navegar a nuestro nuevo tenant para comenzar a configurarlo. Para esto podemos navegar a la lista de recursos y hacer clic en nuestro tenant.

Azure AD B2C – Acceso a Instancia

La pantalla de inicio de Azure AD B2C se ve así.:

Azure AD B2C – Dashboard

2. Registrar una Aplicación

Para poder utilizar el tenant que acabamos de crear necesitamos registrar una aplicación. Pero, ¿Qué es una aplicación?

Azure AD B2C contiene información confidencial de nuestros usuarios que es utilizada por uno o más sistemas autorizados. Un requisito fundamental es que podamos compartir esta información entre el tenant y estos sistemas de forma segura, y para esto necesitamos asegurarnos que quién solicita dicha información es realmente un sistema autorizado y configurado por nosotros.

Una aplicación es la forma en la que configuraremos e identificaremos estos sistemas para garantizar un acceso seguro.

¿Cómo funciona?

Azure AD B2C – Diagrama de Secuencia

Cuando un usuario quiera registrarse o iniciar sesión en nuestro sitio web, será redireccionado a nuestro tenant. Azure AD B2C validará las credenciales del usuario (o lo registrará si fuese necesario) y luego devolverá un token JWT a nuestro sitio web para que luego sea usado para identificar al usuario. El token contiene la información del usuario que la aplicación esta autorizada a utilizar.

Nuevo registro de aplicación

Registros de Aplicaciones – Nuevo registro

Para poder registrar una nueva aplicación, debemos navegar a la sección de Registros de aplicaciones situada sobre el panel de la izquierda y luego ir a Nuevo Registro.

Registros de Aplicaciones – Registrar aplicación

Solo necesitamos completar el Nombre y vamos a agregar una URI de redirección, dejaremos los demás campos con sus valores por defecto.

En este caso elegí como nombre Sitio Web Increíble y como URI de redirección https://jwt.ms/.

La URI de redirección debe ser una dirección valida de nuestra aplicación. Estamos usando https://jwt.ms/ solo a fines prácticos hasta tanto integremos nuestras APIs y Apps.

Registros de Aplicaciones – Lista de aplicaciones

Por último, solo nos falta configurar nuestra aplicación para que retorne los tokens JWT que necesitamos, con la información del usuario o claims incluida. De lo contrario, el token estará vacío.

Para esto, tenemos que acceder a la opción de Registros de Aplicaciones y luego navegar a nuestra aplicación.

Registros de Aplicaciones – Authenticación

Una vez ahí, en la sección Autenticación, habilitamos las opciones de Access Tokens y ID Tokens que se encuentran casi al final.

Por último, guardamos los cambios.

Cuando se trata de tokens JWT, los atributos de un usuario, como nombre y apellido, se denominan Claims.

Ya tenemos nuestra aplicación con una configuración base. Más adelante volveremos para realizar configuraciones mucho mas específicas, pero para comenzar, la configuración que acabamos de realizar es suficiente.

3. Crear un flujo de usuario

Los flujos de usuario tienen un papel central dentro de Azure AD B2C ya que definen como validar la identidad de un usuario y/o registrar uno nuevo, es decir, que información se le solicita al usuario, que datos son obligatorios y cuales no, si debe ser un tipo de campo de selección múltiple, texto simple o selección simple, y todo lo relacionado a la experiencia de usuario en cuanto al proceso de autenticación. Azure AD B2C ofrece cinco flujos de usuario:

  • Registro
  • Inicio de Sesión
  • Registro e Inicio de sesión (es la combinación de los dos primeros)
  • Edición de perfil de usuario
  • Restablecimiento de contraseña
Flujo de Usuario – Nuevo flujo de usuario

Vamos a comenzar creando un nuevo flujo de usuario de Registro e Inicio de sesión.

Para esto, tenemos que ir a la sección de Flujos de Usuario sobre el panel de la izquierda y clicar sobre la opción Nuevo flujo de usuario.

Flujo de Usuario – Crear flujo de usuario

Para nuestro ejemplo usaremos el flujo Registrarse o iniciar sesión, el cual le dará al usuario la opción de registrarse en caso todavía no exista.

Muchas veces, Iniciar sesión y Registrarse se inician desde acciones separadas desde el Front End, es por eso que tenemos cada flujo en forma independiente.

Flujo de Usuario – Crear nuevo flujo de usuario

Revisión del flujo de usuario

Finalmente, llegamos a la pantalla de creación. Veamos que necesitamos en cada sección.

  • 1. Nombre – Además de ser único, debemos tener en cuenta que podemos tener mas de un flujo del mismo tipo. Por ejemplo, podemos tener dos flujos de registro.
  • 2. Proveedores de Identidad – Por el momento la única opción disponible será Email Sigup, pero aquí se listarán proveedores externos también (como LinkedIn, Google, etc.).
  • 5. Atributos de usuario – Aquí es donde incluiremos qué información del usuario recopilar y qué información incluir en los tokens. Por el momento incluiremos información básica como nombre y apellido
  • El resto de las opciones, los valores recomendados son suficiente.
Flujo de Usuario – Lista de flujos de usuario

Ya lo tenemos listo! Ya estamos en condiciones de comenzar a utilizar nuestro flujo y registrar un nuevo usuario. Navegando nuevamente a la sesión de Flujos de usuario, veremos nuestro nuevo flujo de usuario recientemente creado donde podremos hacer clic para ver el detalle y las opciones disponibles.

¿Cómo lo probamos?

Flujo de Usuario – Dashboard

Ahora nos toca la parte divertida y fascinante. Ya tenemos todo lo necesario configurado, vamos a ver cómo probarlo. Para esto debemos navegar hasta el flujo de usuario y veremos una acción Ejecutar flujo de usuario.

Flujo de Usuario – Ejecutar flujo de usuario

Al hacer clic se desplegará una nueva ventana sobre la derecha, por el momento utilizaremos todas las opciones recomendadas y presionaremos Ejecutar flujo de usuario.

Flujo de Usuario – Inicio de sesión

Al hacerlo, se abrirá en otra ventana nuestro nuevo y flamante inicio de sesión solicitando email y contraseña. Además tenemos disponible la opción para recupero de contraseña (Forgot your password?)

Si prestamos atención, debajo del botón Sign in veremos la opción para registrarse (Sign up now) que nos llevará al flujo de registro de usuario.

Flujo de Usuario – Registro de usuario

El flujo de registro de usuario, incluye validación de email con código de verificación. Azure AD B2C enviara un código al mail ingresado que luego será requerido antes de continuar con el registro, garantizando por un lado que no se trata de un bot, y por el otro que es un mail válido.

También requiere como información adicional al mail y la contraseña los dos atributos adicionales que seleccionamos cuando configuramos el flujo: Nombre y Apellido.

Felicitaciones!!! Acabamos de crear nuestra primer experiencia de usuario utilizando Azure AD B2C. Claro que todavía falta bastante. Seguramente queremos que el flujo funcione con el idioma que nuestros usuario hablan, incluso múltiples idiomas, y no solo en inglés (idioma por defecto), o queremos recolectar información personalizada como “Años de experiencia” y que la cantidad de opciones sea finita. Y por supuesto, queremos nuestra marca y estilo por sobre todas las cosas.

Todo eso es posible y lo iremos descubriendo en sucesivos artículos!

Conclusiones

  • El artículo es un poco extenso! Si, sé que se hizo largo, pero me pareció interesante que como primer paso tengamos algo limitado, pero funcional. Y para eso era necesario cubrir estos tres pasos básicos.
  • Cero código! Esto es importantísimo, no tuvimos la necesidad de escribir código e hicimos todo desde el mismo portal, sin requerir equipamiento especial. Solo con un navegador y conexión a internet.
  • Fácil y rápido! A pesar de lo extenso del articulo, no lleva más de 15 minutos seguir todos estos pasos para configurar todo. ¿Cuánto tiempo nos hubiera tomado hacer esto por nuestros propios medios?
  • Cero costo! No necesitamos hacer ninguna erogación de dinero. Con lo cual, tenemos un ambiente de desarrollo (y por qué no de pruebas también) virtualmente gratis.

Próximos pasos…

En el próximo articulo te voy a contar cómo configurar los atributos de usuario y cómo personalizarlos, veremos cómo crear atributos de selección múltiple (listas de check box), listas desplegables (combo box), selección simple (radio buttons), etc.

Si necesitas asesoramiento o ayuda, si tenés dudas o no sabes cómo comenzar, o te interesa conocer/aprender sobre otros servicios de Azure, contáctame y vemos juntos como encontrar la solución que necesitas.

Azure AD B2C: Una gran bala de plata

El 3 de Octubre de 2020 se llevó a cabo vOpen Tech 2020, la conferencia que antes era conocida como .NET Conf y tuvo sus orígenes en Uruguay por el año 2014. A diferencia de años anteriores, esta edición tuvo dos particularidades: la primera es que fue virtual, producto de la pandemia que está presente a nivel mundial desde Marzo de 2020; y por otro lado tuve el placer de formar parte del Equipo Organizador Global que la llevó adelante.

Mi participación estuvo muy orientada a los aspectos tecnológicos, y se centró en el siguiente desafío: ¿Cómo transformar una conferencia que hasta el momento se había desarrollado en forma presencial, para adaptar todos sus procesos y aplicación móvil a un contexto virtual?

En esta publicación te compartiré mi experiencia y contaré cómo llevamos adelante este desafío, como Azure AD B2C fue clave en la implementación de la solución.

Contexto: de lo presencial a lo virtual

Uno de los grandes desafíos que tuvimos en vOpen Tech 2020 implicó cambiar de forma completa la manera de registrar e interactuar con los participantes, comparado con las ediciones anteriores que eran presenciales y en múltiples países:

  • El registro se llevaba adelante con Eventbrite y el check-in con la lectura de un código QR.
  • Tanto los asistentes como los patrocinadores tenían una aplicación móvil multi-plataforma que les permitía interactuar: registrar visitas al stand, realizar sorteos, y obtener estadísticas.

¿Cómo transformar esta experiencia llevándola al 100% online? Teníamos poco tiempo: apenas un mes para poder resolver estos aspectos, antes de comenzar con la difusión y recepción de pre-registros.

Solución: Azure AD B2C + Azure Functions como base tecnológica

Es importante aclarar que el real desafío no era construir desde cero una experiencia de registro / inicio de sesión / interacción, dado que esto requeriría mucho tiempo (código) y en consecuencia, dinero. El verdadero desafío era hacerlo bueno, bonito y barato.

Elegimos Azure AD B2C + Azure Functions para construir esta experiencia:

  • Azure AD B2C: para todo el sistema de registro, inicio de sesión y perfiles de usuario.
  • Azure Functions: para todo el sistema de back-end de notificaciones y novedades en tiempo real durante el evento virtual.

Vamos a explorar, juntos, qué es Azure AD B2C (dejaremos Azure Functions para otra publicación) y cómo pudimos utilizarla con muy poco código y esfuerzo de configuración.

¿Qué es Azure AD B2C?

Azure AD B2C es un servicio en la nube IAM (Identity Access Management o Administrador de Identidades y Acceso) pero orientado al cliente. Esta construido sobre Azure AD (de aquí todas las funcionalidades especificas de IAM), pero agrega una capa de configuración y personalización de flujos de registro e inicio de sesión que podemos exponer de cara al usuario, sin necesidad de escribir nuestro propio back-end o front-end. En pocas palabras, nos brinda un flujo de registro/inicio de sesión listo para usar sin invertir esfuerzo en desarrollo.

Pantalla de inicio de sesión de vOpen Tech
Pantalla de inicio de sesión de vOpen Tech

Aquí podemos apreciar un inicio de sesión con redes sociales, completamente configurable desde el portal de Azure AD B2C.

Adicionalmente podemos incluir inicio de sesión con usuario y contraseña con tan solo un clic.

Azure AD B2C en acción: ¿Qué nos ofrece?

Una de las características más importantes de este increíble servicio que nos ofrece Azure es que, al estar orientado al cliente final (de ahí el B2C o Business-To-Client), no necesitamos escribir código y es todo configurable desde el mismo portal. Incluso, podemos testear los diferentes flujos de forma muy simple y rápida desde el navegador.

¿Qué mas nos ofrece?

  • Personalización de los atributos de usuarios, Azure AD B2C nos ofrece una lista extensiva de atributos estándar como nombre, apellido, país, etc., o la posibilidad de crear nuestros propios atributos, como Nivel de Inglés por citar un ejemplo. También nos ofrece la habilidad de personalizar la forma en la que mostramos esos atributos (texto libre, selección múltiple, combos, check-boxes, etc.).
  • Integración con redes sociales y servicios externos como Facebook, LinkedIn, Google, Twitter, Github y más. Además, soporta integraciones con cualquier servicio que soporte el protocolo OpenID Connect.
  • Internacionalización, más de 50 idiomas disponibles y la posibilidad de crear un diccionario a medida.
  • Identidad y estilo, diseño de la interfaz de usuario 100% personalizable. De este modo, no tenemos que sacrificar la identidad de nuestra marca o negocio.
  • Administración de perfiles de usuario, además del registro e inicio de sesión, existen flujos para que los usuarios puedan autogestionar la información de sus perfiles.
  • Seguridad, escalabilidad, resiliencia y robustez, ya que Azure AD B2C está montado sobre Azure AD, tenemos disponibles funcionalidades como MFA (Múltiple Factor de Autenticación o Multi-Factor Authentication), validación de correo electrónico, certificados, reportes, exportación a Excel y muchos etcéteras más.

Costos de Azure B2C

Este es quizás el tópico mas importante en lo que tiene que ver con Azure AD B2C, ya que no entender en profundidad como se factura el servicio puede generar gastos que perjudiquen de sobremanera el negocio.

Previo a Noviembre del 2019, el servicio se cobraba utilizando el modelo Por Autenticación, es decir, por cada inicio de sesión de cada usuario durante el mes en curso. Por ejemplo, si dos usuarios realizan 50 inicio de sesiones cada uno durante el mes, se facturan 100 unidades.

En Noviembre del 2019, Azure introdujo el concepto de MAU (Monthly Active Users o Usuarios Mensualmente Activos) para facturar el servicio. ¿Cómo funciona este nuevo modelo?

A diferencia del modelo Por Autenticación, el modelo MAU se factura por usuario activo durante el mes en curso. Siguiendo con el ejemplo anterior, si tenemos dos usuarios que realizan 50 inicio de sesiones cada uno durante un mes, se facturan 2 unidades.

El costo de cada MAU se calcula de la siguiente forma:

  • Los primeros 50000 son totalmente gratis
  • A partir de los 50000, USD 0.00325 por MAU

Como podemos apreciar, es un servicio de muy bajo costo, que incluso nos deja margen para pruebas e investigación. No solo es barato en términos de dinero, sino también en términos de desarrollo, ya que nos permite tener un login multi idioma con registro de usuario, gestión de perfiles e integración con redes sociales en menos de una hora. Si!!! En menos de una hora!!!

Les comparto el webinar “Azure AD B2C para mortales” que realicé en Viernes de Azure para Azure en Español gracias a los genios de Pablo Ariel Di Loreto y Guillermo Bellmann.

Próximos pasos…

En el próximo artículo compartiré un paso a paso de como configurar y comenzar a utilizar nuestro Azure AD B2C, como personalizar nuestros usuarios, idiomas y como implementar nuestro propio estilo y así mantener nuestra identidad intacta.

Eso sí, te pido un poco de paciencia.

Si necesitas asesoramiento o ayuda, si tenés dudas o no sabes cómo comenzar, o te interesa conocer/aprender sobre otros servicios de Azure, contáctame y vemos juntos como encontrar la solución que necesitas.

© 2021 Facu The Rock

Tema por Anders NorenArriba ↑