Al principio, esta pregunta puede parecer una situación de manzanas contra naranjas. Descubriremos que en algunos casos no es así, y que elegir la mejor opción estratégica para sus necesidades depende de varios factores.
A menudo, en el desarrollo de la empresa software y la estrategia corporativa, cogemos nuestra bolsa de martillos y percibimos todo como un clavo. Puede ser la familiaridad, el coste percibido o las promesas de compatibilidad. Estas tres soluciones tienen diferentes casos de uso primario, pero no deberíamos coger una y luego descartar las otras dos opciones sin considerar cómo encajan en su estrategia IAM más amplia.
Para la federación empresarial con plataformas SaaS, SAML 2.0 a través de AD FS 3.0 es casi siempre la opción adecuada. SAML 2.0 es un protocolo muy seguro, muy bien soportado, y con AD FS presente como Role en Windows Server, el precio es "gratis", con un coste de implementación muy bajo. La federación a través de Azure ACS proporciona una puerta de entrada a un gran número de proveedores de SaaS, simplificando la complejidad presente en las asociaciones de federación de uno a muchos. (Si su organización tiene que dar soporte a una asociación de federación para cada proveedor o servicio, esto aumenta tanto la complejidad como el nivel de esfuerzo de soporte y mantenimiento. Con la entrada en juego de concentradores de federación como Azure ACS, las cosas son mucho más sencillas en las instalaciones).
Aunque Azure Active Directory tiene soporte OAuth, on-premise o personalizado, la integración OAuth puede ser importante para obtener el beneficio de este protocolo. OAuth es ampliamente utilizado y soportado en aplicaciones no empresariales, "Todo Internet". Si su organización pretende desplegar servicios accesibles para "todo el mundo", en lugar de sólo para empleados, socios y proveedores, la estrategia OAuth merece una seria consideración. Del mismo modo, si tiene previsto publicar una aplicación móvil, para plataformas móviles, OAuth es el protocolo típico. Aunque podemos conseguir que SAML 2.0 funcione con su aplicación como agente de usuario activo, las bibliotecas comunes para OAuth probablemente tengan más sentido.
Puede que digas "Lee, ¿por qué mencionas siquiera Workplace Join en este artículo?". Bueno, es probable que tengas usuarios que quieren "traer su propio dispositivo" (BYOD) y aún así acceder fácilmente a los recursos de la empresa, y archivos. Esta opción es posiblemente la que menos esfuerzo requiere. Si sólo necesita que los dispositivos ajenos al dominio puedan acceder a los recursos del dominio para usuarios conocidos, esta vía es mucho más sencilla que las otras dos. Por supuesto, si ya dispone de AD FS 2.0 o 3.0, tendrá que realizar algunos cambios en la configuración para admitir el registro de dispositivos y Workplace Join.
Como hemos visto, la implementación de OAuth como interfaz de autenticación para dispositivos no pertenecientes a un dominio y recursos proporcionados por SaaS es comparativamente compleja y requiere desarrollo. El desarrollo llevará tiempo y esfuerzo. Por supuesto, no hay coste de licencia. Además, tener la capacidad de OAuth puede ser muy valioso, de cara al futuro.
En resumen: Para la federación con aplicaciones empresariales y los principales proveedores de SaaS, vas a utilizar SAML 2.0. Para el despliegue de aplicaciones móviles o aplicaciones de Internet que necesitan integrarse con sitios como Twitter, Google y aplicaciones Azure personalizadas, vas a utilizar OAuth. Y si todo lo que necesitas es que los usuarios BYOD con iPads, otros dispositivos iOS o usuarios de dispositivos Windows 8.1 accedan a recursos específicos de la empresa, echa un vistazo a la implementación de Workplace Join.
