[ARTICULO] Office 365 – Comparativa entre Cloud Identity, Synchronized Identity y Federated Identity

Office 365 permite configurar tres modelos de identificación para el acceso a sus servicios. Estos modelos de identidad impactan en la experiencia que el usuario tenga y de las credenciales que utilizará al momento de ingresar a Exchange Online, SharePoint Online, Lync Online o inclusive otros servicios de Microsoft Online Services tales como Windows Intune.

En este artículo vamos a hacer el mejor esfuerzo por explicar los tres modelos existentes, cómo impactan en la experiencia del usuario y ventajas y desventajas de cada uno.

[toc]

Introducción

Objetivo y Alcance

Esta publicación tiene como objetivo mostrar qué alternativas tienen las organizaciones y administradores de IT en relación a configuraciones de Office 365 y gestión de identidades.

En este sentido, vamos a hacer una recorrida por los tres modelos existentes actualmente: Identidad en la nube [Cloud Identity], Identidad Sincronizada [Synchronized Identity] e Identidad Federada [Federated Identity].

Audiencia

Este documento está dirigido a Consultores, Profesionales IT y personas que desarrollan tareas de Consultoría, Administración y Soporte o que simplemente están interesados en aprender nuevas cosas.

Comentarios y Corrección de Errores

Hemos realizado nuestro mejor esfuerzo para no cometer errores, pero al fin y al cabo somos seres humanos. Si deseás reportar algún error o darnos feedback de qué te pareció esta publicación, por favor no dejes de comunicarte con nosotros a través de correo electrónico a la siguiente dirección: info@tectimes.net.

Desarrollo

En el momento de comenzar a trabajar en un proyecto de Office 365, uno de los temas centrales en el Planeamiento es la gestión de identidades. En este sentido surgen las siguientes preguntas:

• ¿Con que usuario y password se loguearán los usuarios?
• ¿Si cambio la contraseña en mi infraestructura de Active Directory se cambia en la “nube”?
• ¿Puedo utilizar funcionalidades de SSO, de modo tal que si inciaron sesión en la infraestructura local no deban poner usuario y password en la nube?
• ¿Debo sí o sí vincular mi infraestructura local con la nube?

Para poder aclarar todo esto, vamos a explicar las tres posibilidades de identidad que existen hoy con Office 365. Cuando hablamos de posibilidades de identidad, nos referimos a cómo Office 365 gestionará quién soy y que características tengo, no donde estoy autorizado a ingresar (eso sería gestión de la autorización).

Las actuales posibilidades de Office 365 en este sentido son actualmente las que están expresadas en el siguiente gráfico:

Por supuesto, seguramente para administradores que no están familiarizados con esto el gráfico producirá más dudas que certezas. No obstante, vamos a analizar por separado cada una de las posibilidades, contextualizarlas, y luego compararlas.

Opción 1: Identidad en la nube [Cloud Identity]

Esta opción de identidad es la que, por defecto, se habilita cuando creamos una cuenta en Office 365. En primera instancia, Office 365 tiene reservada una partición de Azure Directory Services aislada donde se alojarán los datos de nuestros usuarios, o más formalmente nuestros objetos usuario.

En este caso, la contraseña es gestionada por Azure Directory Services y no tiene relación absoluta con nuestra infraestructura on-promises. De hecho, tampoco nuestro UPN de usuario tiene relación con nuestra infraestructura on-promises, y de hecho (finalmente) debemos dar de alta los usuarios uno por uno, dado que por default nuestro espacio en Office 365 se crea sin usuarios (o con uno, que es el administrador).

Este escenario es muy comúnmente utilizado en organizaciones pequeñas y medianas que no tienen o no quieren utilizar su servicio de directorio local como autenticación, y tampoco les interesa brindarle a sus usuarios una experiencia consistente entre la contraseña utilizada en su infraestructura on-promises y la de los servicios en la nube.

Un aspecto importante, presente en las tres opciones, es que el usuario de la nube deberá tener formato de correo electrónico (UPN de usuario), y por defecto Microsoft nos proporciona uno válido públicamente como subdominio de “onmicrosoft.com”. Por ejemplo, si nuestra empresa es dada de alta como “MiEmpresa”, el UPN por defecto (salvo que lo cambiemos) será “MiEmpresa.onmicrosoft.com”, y los usuarios iniciarán sesión con el formato “usuario@MiEmpresa.onmicrosoft.com” para ingresar a los servicios en la nube. Esto no implica, sin embargo, que la infraestructura local deba sufrir cambios en el caso que se utilice un UPN local (MiEmpresa.local por ejemplo o uno no registrado en forma pública).

Opción 2: Identidad Sincronizada [Synchronized Identity]

Esta opción es la primera que, de alguna forma, relaciona nuestro servicio de directorio local (Active Directory Domain Services) con el servicio de directorio en la nube (Azure Directory Services).

Haciendo uso de un software proporcionado por Microsoft, llamado DirSync (Directory Sinchronization, que forma parte de la familia de productos FIM), podemos sincronizar objetos (usuarios, contactos y grupos) desde nuestro Active Directory Domain Services (local) hacia la partición del servicio de directorio en la nube (Azure Directory Services).

Como consecuencia, los objetos sincronizados estarán también presentes en Office 365 y podrán ser consumidos. Adicionalmente, el DirSync nos permite sincronizar las contraseñas de los usuarios, lo cual permite a los usuarios acceder a los servicios de Microsoft Online Services que utilicen Azure Directory Services (como Office 365, InTune, CRM Online, etc) puedan utilizar la misma contraseña de autenticación de usuario que se utilizan para acceder a la red local (Active Directory Domain Services).

En realidad, no se sincroniza la contraseña, sino los Password Hashes, lo cual permite en última instancia que los usuarios puedan utilizar la misma contraseña (que está sincronizada por su hash) en la infraestructura local como en la nube.

Por supuesto, el nombre del usuario deberá ser configurado con formato UPN, de modo tal que el login se realice con la dirección de correo electrónico principal. Y este UPN, además, deberá ser válido en forma pública (no se puede utilizar un dominio .local o no registrado en forma pública).

Es importante tener en cuenta que esta característica no proporciona una solución Single Sign-On (SSO), porque no hay intercambio de Tokens entre las infraestructuras que interactúan.

Opción 3: Identidad Federada [Federated Identity]

La tercera y última opción agrega la posibilidad de que el inicio de sesión se efectivice en nuestra infraestructura local. ¿Qué significa esto? ¿Qué en la nube no tendré un espacio aislado o partición de Azure Directory Services?

No, para nada. Este espacio es aún necesario y, de hecho, se debe seguir utilizando la herramienta anteriormente mencionada: DirSync. Lo adicional aquí es que ambas infraestructuras van a interactuar a través de los servicios de federación de Active Directory, de modo tal que cuando un usuario ingresa su login y password quien valide estos datos será nuestro servicio de directorio local, no el servicio de directorio de la nube. Una vez que nuestro servicio de directorio da el “ok” sobre la Identidad del usuario, el resto sigue como en las opciones anteriores: el usuario podrá consumir los servicios de la nube.

Adicionalmente, esta opción nos permite implementar una solución Single Sign-On (SSO), de modo tal que podremos consumir varios servicios en la nube de Microsoft no solo con la identidad de nuestro servicio de directorio y realizando la autenticación en la infraestructura local, sino que también una vez que estamos logueados en un equipo unido al dominio dentro de la red interna no vamos a tener que reingresar credenciales, dado que ya estamos logueados.

Esta última opción no es extendida a todos los productos, y en el próximo apartado vamos analizar cuándo y en qué circunstancias se puede aprovechar.

Comparativo de Experiencia entre las Opciones de Identidad

En base a la información oficial proporcionada por Microsoft, a continuación presentamos una tabla comparativa donde veremos cómo se comporta cada servicio, producto o protocolo de acceso a los servicios de Office 365 en las tres opciones de identidad.

Por último, vamos a incluir una columna llamada “Veredicto”, donde haremos el mayor esfuerzo para identificar objetivamente qué tipo de experiencia tendría el cliente comparativamente entre las opciones 2 y 3 (Identidad Sincronizada vs Identidad Federada).

Tengamos en cuenta un aspecto importante: el veredicto está relacionado únicamente con la experiencia del usuario final, y no con requerimientos de seguridad y auditoría. No olvidemos que en el caso de la Identidad Federada, la autenticación se realiza en nuestra infraestructura. En algunos casos puntuales, este es un aspecto decisivo al momento de elegir que opción de identidad elegir.

Sin mayor introducción, les mostramos la tabla:

Conclusiones

Como hemos podido analizar, Office 365 permite configurar tres modelos de identificación para el acceso a sus servicios. Cada modelo de identidad impacta en la experiencia que el usuario tenga, principalmente en lo relacionado con que usuario y password va a utilizar (el mismo o distinto que el local de AD DS). Adicionalmente, y como hemos visto, la Identidad Federada es la única que permite experiencia en algunos métodos de acceso de tipo SSO (Single Sign-On).

Por supuesto, la Identidad Federada requiere despliegue de los servicios de Active Directory Federation Services y de Web Application Proxy para funcionar, además de ubicar a nuestro Servicio de Directorio local (Active Directory Domain Services) como punto crítico (más aún de lo que normalmente es) para el acceso a los servicios. Esto último es por una simple razón: como nuestra autenticación se realiza allí, si no está disponible ningún usuario podrá iniciar sesión ni adentro o fuera de nuestra organización.

La elección del modelo de identidad estará relacionada a la experiencia que querramos darles a nuestros usuarios, como así también a las regulaciones de seguridad informática, requerimientos de negocio y posibilidades técnicas. El conjunto de todo ello deberá ser analizado cuidadosamente, sus pros y contras, antes de tomar una decisión a la ligera.

Este artículo se ha focalizado en identificar, desde el punto de vista de experiencia de usuario, las diferentes opciones y contextualizarlas para ayudar, de alguna forma (es nuestro deseo) al análisis objetivo.

¡Muchas gracias por leernos!

Referencias y Links

• Office 365 Single Sign-On with AD FS 2.0 whitepaper: http://www.microsoft.com/en-us/download/details.aspx?id=28971
• Directory synchronization roadmap: http://technet.microsoft.com/en-us/library/hh967642.aspx
• Single sign-on roadmap: http://technet.microsoft.com/en-us/library/hh967643.aspx
• Install or upgrade the Directory Sync tool: http://technet.microsoft.com/en-us/library/jj151800.aspx
• Implement Password Synchronization: http://technet.microsoft.com/en-us/library/dn246918.aspx
• Identity and Authentication in the cloud: Office 2013 and Office 365 (Poster): http://www.microsoft.com/en-us/download/details.aspx?id=38193

Sobre el Autor