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.
- ADFS. Incluido como rol de Windows Server 2012 (versión 2.1) y Windows Server 2012 R2 (versión 3.0), o bien descargable gratuitamente para Windows Server 2008 R2 (versión 2.0). Soporta, entre otros, los protocolos WS-Federation, WS-Trust y SAML 2.
- Shibboleth IdP. Proveedor de identidad de código abierto implementado como Java Servlet 2.4. Derivado de esto, es capaz de ejecutarse en una gran variedad de sistemas operativos, entre los que se encuentran Windows y GNU/Linux. Soporta únicamente el protocolo SAML 2.
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 | Sí | Sí |
| Clientes IMAP | Sí | Sólo Shibboleth con ECP |
| Clientes Exchange Active Sync | Sí | Sólo Shibboleth con ECP |
| Clientes Outlook Anywhere | Sí | Sólo Shibboleth con ECP |
| Cliente Lync | Sí | Próximamente |
| Office Pro Plus | Sí | 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:
- Entramos en el webiste correspondiente de Office 365, por ejemplo: https://portal.office.com
- 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
- 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:
Veamos como funciona en este caso, siendo una autenticación IMAP la que está sucediendo:
- 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.
- 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.
- Los servidores de federación autentican al usuario y así se lo comunican a Office 365.
- 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!