Cuando una empresa desarrolla una aplicación para sus clientes, externos
a su organización, uno de los puntos claves es el desarrollo que permitirá el
acceso a esta aplicación. ¿Qué puntos se deben tener en cuenta?
·
Permitir
varios proveedores de identidad:
o
Registro.
o
Proveedores de
terceros: Twitter, Facebook, LinkedIn, etc.
·
Permitir
autenticación multi factor.
·
Restablecimiento
de contraseña.
·
Posibilidad de
implementar políticas según los casos.
·
SSO entre
diferentes.
Para poder dar salida
a todos estos requerimientos tenemos dos opciones:
·
Implementamos
el servicio de identidad: ya sea uno custom, con identity server…
·
Utilizamos un
servicio ya implementado y preparado para ello.
En mi caso, a los clientes, es la segunda opción la que les aconsejo, y
además les aconsejo utilizar Azure AD B2C. El objetivo de este artículo es explicar un
que es Azure AD B2C, que podemos hacer con él y de esta forma entender porque
utilizarlo.
Pilares de Azure AD B2C
Los pilares sobre los
que se basa Azure AD B2C son cinco:
·
Cuentas
locales y sociales.
·
Autenticación
Multi-Factor.
· Políticas de: sign up, sign in, sign up o sign in,
password reset y profile editing.
·
Customización
de la experiencia de usuario: Pantalla login, registro, edición perfil usuario
y reseteo de password.
·
Fácil
integración en el desarrollo de aplicaciones que utilicen Azure AD B2C.
Cuentas locales y sociales
Si queremos dar un buen servicio a nuestros usuarios, una de las
opciones que debemos darle es que pueda realizar el login en nuestra aplicación
mediante alguna de sus cuentas de redes sociales que ya utilicé. Hay muchos
usuarios que prefieren utilizar una única identidad en todas las aplicaciones
para no tener infinitas cuentas, otros utilizar varias y otros que prefieren
tener una por sistema.
Resumiendo, Azure AD B2C brinda a los usuarios finales la posibilidad de elegir
entre:
·
"Traer su
propia identidad" (BYOI) mediante el uso de una de sus cuentas sociales como
Amazon, Facebook, Google+, LinkedIn, cuenta de Microsoft (MSA), etc.
·
Crear una nueva cuenta local (dirección de
correo electrónico arbitraria).
Por defecto cuando creas una cuenta de Azure AD B2C solo tienes la
opción de crear cuentas locales:
Para dar la opción de poder interactuar con cuentas externas, hay que
darle a la opción Add y activar el proveedor deseado. Actualmente las opciones son: Microsoft Account, Google, Faebook,
LinkdIn, Amazon, Weibo (Preview), QQ (Preview), WeChat (Preview), Twitter
(Preview), GitHub (Preview).
Para cada una de ellas deberás introducir el ClientId y el ClientSecret
obtenido de la plataforma de origen. Una vez habilitadas a nivel de Tenant,
cuando creemos o editamos una política podremos seleccionar que tipo de cuenta
se requiere para esa política concreta.
Autenticación Multi-Factor
Azure AD B2C permite una segunda capa de seguridad a la hora de
registrarse o logarse. Actualmente esta segunda capa solo se puede hacer
mediante llamadas de teléfono y mensajes de texto. La autenticación
Multi-Factor se activa o desactiva cuando se crea o edita una política. La
razón por la que se hace a nivel de políticas es porque de esta forma se puede
administrar el Multi-Factor por aplicación, no todas nuestras aplicaciones
tienen porque realizar Multi-Factor, o incluso a nivel de partes concretas de
una aplicación.
Políticas
Las políticas son la parte más importante de Azure AD B2C. En ellas se
definen cuál será la experiencia del usuario cuando inicie una sesión, edite su
perfil, se registre en la aplicación o cambié su contraseña. Cuando creamos una
política, está nos permite configurar los siguientes puntos:
·
Tipo de cuenta
que se puede usar para el registro: local o alguna de terceros permitida
(Facebook, Twitter…).
·
Atributos que
son necesarios para identificar a los clientes: Nombre, dirección, teléfono.
·
Uso de
autenticación Multi-Factor.
·
URL de la
página customizada.
·
Claims: La
información que se añadirán a los claims cuando el usuario esté logado.
¿Y cómo Azure B2C sabe que política aplicar en cada momento? Cuando se
hace la llamada https uno de los campos que se deben enviar es la política a
aplicar. Por ejemplo, si tuviéramos una policita de Sign-in con el nombre de
siginpolice la llamada https de login de usuario sería:
https://login.microsoftonline.com/contosob2c.onmicrosoft.com/oauth2/v2.0/authorize?client_id={El
id de tu aplicación registrada}&redirect_uri={url registrada de respuesta}&response_mode=form_post&response_type=id_token&scope=openid&nonce=dummy&&p=siginpolice(que
es nuestra política definida)
Se pueden definir las siguientes políticas:
·
Sign-up or
Sign-in à Política que nos sirve tanto para cuando un usuario haga
login como si se registra.
Los campos que
rellenar son:
o
Proveedor de
identidad à las opciones que se nos mostrarán serán aquellas que
habremos definido con anterioridad a nivel de servicio.
o
Los atributos à Campos que queremos que se muestren en el formulario,
las opciones que se nos mostrarán son todos los que hay por defecto más
aquellos que hayamos creado de forma custom.
o
Claims à Una vez el usuario se haya logado que atributos
queremos que aparezcan en los claims.
o
Autenticación
multifacotr à Si queremos activar la autenticación multifactor o
no.
o
Page UI Custom
à Si queremos utilizar una página customizada, la URL
de la página cusmtomizada que será la que aparezca tanto en el login como en el
registro.
·
Profile editing
à Nos servirá para configurar la experiencia que tendrá
el usuario cuando edite su perfil.
Los campos a
rellenar son los mismos que en la política anterior, excepto que no existe la
opción de autenticación multifactor porque no es una política de autenticación.
·
Password reset
à Nos servirá para configurar la experiencia que tendrá
el usuario cuando quiera hacer el reset de su password.
Como se puede ver en
la imagen anterior se pueden configurar todos los campos de Signin-Signup excepto
la configuración de los atributos a mostrar, en este caso son por defecto.
·
Sign-Up à Nos servirá para configurar la experiencia que tendrá
el usuario cuando quiera registrarse en la aplicación.
Los campos que se
mostrarán para ser configurados son los mismos que en Sign-up or Sign-in
·
Sign-In à Nos servirá para configurar la experiencia que tendrá
el usuario cuando quiera hace el login en la aplicación.
Como podemos observar
los campos son los mismos excepto que en este caso no tiene sentido que podamos
configurar los atributos que saldrán en pantalla.
·
Resource Owner
Policies à Esta política nos permitirá definir los claims que
queremos devolver cuando se ejecutar cuando se esté ejecutando el Flow de resource owner password credentials
(ROPC).
A continuación, vamos a ver un ejemplo de customización Sign-Up y
Sign-In. En la siguiente imagen se puede ver el resumen de la configuración:
Para finalizar vamos a
ver cómo sería el flujo en una aplicación:
1.
El usuario
realiza un Sign-up en la aplicación, y es redireccionado al proveedor de
identidad configurado, en este caso Facebook. Si la autenticación tiene éxito,
se cachea el token recibió y se continua con el segundo paso de autenticación
como sea definido en la política.
2.
Una vez el
usuario ha finalizado el ciclo de la doble autenticación, el orquestador inicia
el proceso de registro donde el usuario verifica la información.
Como podemos ver Azure AD B2C es una opción muy a tener en cuenta ya que
nos da una gran variedad de opciones para que nuestros clientes puedan usar
nuestras aplicaciones.
Más información en: https://docs.microsoft.com/es-es/azure/active-directory-b2c/
Robert Bermejo
Cloud Specialist Consultant en
TOKIOTA | Microsoft Azure MVP
bermejoblasco@live.com
@robertbemejo
www.robertbermejo.com
