Office 365 y ADFS: autenticación activa y pasiva

Si vas a implementar Office 365 en tu organización, tendrás muy presente que hay dos temas capitales sobre los que debes meditar: cómo vas a aprovisionar tus usuarios y cómo van autenticar estos. Cuando hablo con mis clientes sobre autenticación y estos desean Single Sign On, casi siempre entramos en conversaciones de federación y proveedores de identidad (IdP). Los IdP más habituales para federar con Azure Active Directory –que como sabéis es la base de identidad de Office 365- son ADFS y Shibboleth, cada uno de los cuales soporta unos determinados protocolos de autenticación basada en claims.

Las características soportadas según el protocolo de federación empleado cambias, aunque Microsoft está haciendo un importante esfuerzo por dar buen soporte a SAML 2, como se puede apreciar en esta tabla:

Característica Soportada con ADFS Soportada con SAML 2
Acceso web
Clientes IMAP Sólo Shibboleth con ECP
Clientes Exchange Active Sync Sólo Shibboleth con ECP
Clientes Outlook Anywhere Sólo Shibboleth con ECP
Cliente Lync Próximamente
Office Pro Plus Próximamente

¿Cómo funciona la autenticación federada en Office 365? – Autenticación Pasiva

Llamamos autenticación pasiva a aquella que es llevada fundamentalmente por el usuario y por tanto todos los elementos involucrados esperan a ser llamados por el mismo. Esta autenticación es la que usamos al autenticar desde un navegador web. Este esquema ilustra cómo funciona:

Office 365 - Autenticación Pasiva

  1. Entramos en el webiste correspondiente de Office 365, por ejemplo: https://portal.office.com
  2. Office 365 nos redirige a nuestro ADFS, que nos muestra una web para autenticarnos. La URL será de nuestra red, como https://adfs.contoso.com
  3. Tras autenticarnos correctamente volvemos a la web de Office 365 a la que queríamos acceder, como en este caso https://portal.office.com

Como podéis ver, todos los procesos los lleva a cabo el navegador del usuario que es redirigido al lugar correspondiente.

¿IMAP con identidad federada?

Una de las características de protección de datos de la solución de Microsoft es que Azure Active Directory (y por tanto Office 365) no almacena contraseñas de usuarios en caso de estar usando identidad federada. Toda la autenticación se lleva a cabo a través del IdP que tenemos funcionando en nuestras infraestructuras. Este hecho desconcierta mucho a nuestros clientes cuando les aseguramos que es posible usar –por ejemplo- el protocolo IMAP con identidad federada.

El Internet Message Access Protocol (IMAP) es un protocolo de acceso y almacenamiento de correo electrónico desarrollado en el año 1986 como alternativa al POP y que se convirtió en un estándar en la década de los 90, estando soportado por casi la totalidad de clientes de correo electrónico. Sin embargo, IMAP no sabe nada de IdP ni federación de identidad, utilizando sus propios mecanismos integrados de autenticación. ¿Cómo es posible entonces que entremos a nuestro correo IMAP teniendo federación de identidad y sin que Microsoft tenga nuestra contraseña en la nube? La respuesta es mediante autenticación activa.

Siempre que iniciamos sesión en Office 365 mediante un programa que no es un navegador, el mecanismo de autenticación es muy distinto:

Office 365 - Autenticación Activa

Veamos como funciona en este caso, siendo una autenticación IMAP la que está sucediendo:

  1. Usuario autentica mediante su cliente de correo (ej: Thunderbird) con Office 365. En este proceso está enviando ya el nombre de usuario y la contraseña.
  2. Office 365 se da cuenta de que no está en posesión de la contraseña e inicia una conexión con nuestros servidores de federación.
  3. Los servidores de federación autentican al usuario y así se lo comunican a Office 365.
  4. Office 365 permite la conexión al usuario, pudiendo este operar con el sistema.

Así hemos podido ver cómo Office 365 ha jugado un papel activo, conectándose con nuestros servidores de federación, en lugar de ser el propio usuario el que lleva a cabo la operación mediante su navegador.

Espero que este artículo os haya servidor para conocer con más detalle en qué consisten ambos modelos de autenticación y los pasos que estos realizan, ya que es vital para poder depurar cualquier problema que pueda producirse en el contexto de identidad y autenticación federada de usuarios con Office 365 o incluso cualquier aplicación integrada con Azure Active Directory.

Happy authentication!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *