GuilleSQL :: Microsoft SQL Server, SSIS, y más !!

Azure Active Directory (Azure AD)


Azure Active Directory (Azure AD) es la solución de Directorio y el Sistema de Gestión de Identidades de Microsoft en Azure, a través del cual, se puede gestionar la identidad y acceso de usuarios a las Aplicaciones, sean On-Premise on en Azure, independientemente del tipo de dispositivo (iOS, Android, Windows, MacOS, etc.).  Permite tanto la Sincronización de Usuarios (Same Sign-On) como la Federación de Usuarios (Single Sign-On: SSO), así como la integración con Proveedores de Identidad externos (ej: Facebook, Google, Linkedin, Amazon, etc.). Todo esto lo convierte en una solución flexible e ideal para facilitar la autenticación en nuestras Aplicaciones.

Hoy en día, cuando hablamos de Identidades corporativas, podemos pensar principalmente en tres escenarios:

  • Identidades en Azure AD. Es posible tener nuestro Directorio sólo y exclusivamente en la Nube. Si bien es un escenario poco habitual, puede resultar especialmente útil para pequeñas empresas que no tienen una infraestructura local, y para las cuales, tener un servicio de Directorio en la Nube como Azure AD, sería más que suficiente (ej: acceder a Office 365, y otras soluciones SaaS).
  • Identidades On-Premise (Directorio Activo en nuestro DataCenter). Quizás el escenario más habitual hasta ahora, es tener nuestro servicio de Directorio Activo en nuestro DataCenter, a través del cual no sólo gestionamos Usuarios, sino también Dispositivos, y mucho más.
  • Identidades en ambos sitios: Azure AD + On-Premise (entorno híbrido). Esta es la tendencia para compañías de medio y gran tamaño, que tienen su infraestructura local de Directorio Activo con miles o millones de usuarios, y desean poder disfrutar de las ventajas de Azure AD.

En estos escenarios, oiremos hablar también del Single Sign-On (SSO), un término que es importante matizar, para diferenciarlo del Same Sign-On:

  • Same Sign-On. Significa que se nos pedirá credenciales en cada Aplicación a la que accedemos, pero al menos, nos podremos validar con el mismo usuario y contraseña, por lo que se evita el problema de tener que memorizar y custodiar múltiples usuarios y contraseñas.
  • Single Sign-On (SSO). Significa que podemos logarnos una única vez, tras la cual, podemos saltar de Aplicación en Aplicación sin que se nos vuelvan a solicitar credenciales de acceso, realizándose en todos los casos accesos autenticados y autorizados correctamente.

Azure Active Directory (Azure AD): Sincronización y Federación

Es posible gestionar (leer y escribir) la información de Azure Active Directory desde el Azure Management Portal, Office 365 Admin Center, Windows Intune Account Portal, y desde PowerShell con el módulo de Microsoft Azure Active Directory. Sin embargo, en un entorno de Azure AD, quizás lo que más nos interesará serán las opciones que tenemos para la Sincronización y Federación de Usuarios.

La Sincronización de Usuarios es la opción más utilizada, al ser más rápida, simple, y fácil de configurar, pero sólo podremos conseguir Same Sign-On. La Federación de Usuarios es algo más compleja, pero nos permitirá conseguir el ansiado Single Sign-On (SSO): acceder a recursos locales y externos (ej: Office 365) con las credenciales del Directorio Activo On-Premise.

Podríamos diferenciar tres tipos de Sincronización de Usuarios:

  • Sincronización de Identidades (Identity Sync). Es el escenario más simple, en el que las propiedades del usuario son gestionadas On-Premise, y sincronizadas con Azure AD. La contraseña no se sincroniza, por lo que el usuario tendrá dos contraseña (una On-Premise y otra en Azure).
  • Sincronización de Contraseñas (Password Sync). Las propiedades y contraseña del usuario son gestionadas On-Premise, y sincronizadas con Azure AD. De este modo, el usuario puede acceder con la misma contraseña a los recursos de la compañía y a los recursos externos (ej: Office 365, CRM Online, etc).
  • Sincronización de Contraseñas con Escritura (Password Sync with WriteBack). Permite que los usuarios puedan resetear su contraseña desde cualquier lugar, validarlas inmediatamente contra las políticas del Directorio Activo On-Premise, almacenarlas como un hash, y sincronizarlas con el Directorio Activo On-Premise. Se utiliza Azure Service Bus Relay para implementar el WriteBack, evitando tener que publicar Directorio Activo a Internet.

Hay varias formas (o herramientas) de realizar la Sincronización de Usuarios entre Directorio Activo y Azure:

  • DirSync (Azure Active Directory Sync Tool). Fué la primera herramienta.
  • AADSync (Azure Active Directory Synchronization Services). Incluye características avanzadas, como sincronización desde múltiples Bosques, y Password Write-Back.
  • Azure AD Connect. Realiza tanto Sincronización como Federación de Directorios, con un esfuerzo de configuración mínimo.
  • FIM (ForeFront Identity Manager). Es el hermano mayor de DirSync y AADSync. Permite sincronizar información desde múltiples Bosques y también desde otros orígenes como SQL.
  • MIM (Microsoft Identity Manager). Es el sucesor de FIM.

Igualmente, tenemos varias opciones o herramientas para realizar la Federación de Usuarios:

  • AD FS (Active Directory Federation Services). Requiere un mínimo de infraestructura (una base de datos SQL y un servidor Windows) y algo de esfuerzo de configuración.
  • Azure AD Connect.

La Federación y el Single Sign-On (SSO) es posible gracias a Secure Token Service (STS).

Usuarios y Proveedores de Identidad Externos

En Azure AD es posible añadir usuarios de otro Directorio de Azure AD (ej: de otra empresa o partner) así como también usuarios con cuentas de Microsoft. Estos usuarios serán autenticados contra sus propios Directorios al logarse.

Al añadir un usuario de Azure AD dentro de otro Azure AD, se copian las propiedades del usuario, como el Display Name y el User Name. Sin embargo, a partir de ese momento, los futuros cambios no son propagados entre ambos Directorios.

Otra opción que tenemos es utilizar Azure Active Directory B2C, disponible en el Marketplace, y que nos permite conectar proveedores de identidad externos (ej: Facebook, Google, Linkedin, Amazon, etc.) a nuestro Azure AD, de tal modo que sea posible logarse en nuestras aplicaciones con estos usuarios, de una forma fácil y sencilla. Puede utilizarse Azure AD Graph API para obtener propiedades de los usuarios como el nombre y la dirección de correo.

Poco más por hoy. Como siempre, confío que la lectura resulte de interés.


[Fecha del Artículo (UTC): 12/12/2017]
[Autor: GuilleSQL]



Escribir un Comentario

Para poder escribir un comentario, debe Iniciar Sesión con un usuario.

Si no dispone de un usuario, puede Registrarse y hacerse miembro.

Si dispone de un usuario, pero no recuerda sus credenciales de acceso, puede Restablecer su Contraseña.

Miembros de
Miembros de GITCA (Global IT Community Association)

Menu de Usuario
  Iniciar Sesión
  Registrarse
  Restablecer Contraseña
  Ventajas de Registrarse

Acerca de
  Contigo desde Oct 2007
  771 usuarios registrados
  86146 pageloads/mes
  Ranking Alexa 498160

Social Networks
Sigue a Portal GuilleSQL en Linkedin !!
Sigue a Portal GuilleSQL en Twitter !!



Archivo

Diciembre de 2017 (15)
Noviembre de 2017 (7)
Junio de 2017 (3)
Mayo de 2017 (1)
Marzo de 2017 (3)
Enero de 2017 (4)
Junio de 2016 (1)
Mayo de 2016 (2)
Abril de 2016 (2)
Septiembre de 2015 (2)
Agosto de 2015 (2)
Junio de 2015 (10)
Mayo de 2015 (4)
Abril de 2015 (8)
Marzo de 2015 (11)
Octubre de 2014 (3)
Septiembre de 2014 (7)
Agosto de 2014 (5)
Julio de 2014 (2)
Mayo de 2014 (4)
Abril de 2014 (4)
Marzo de 2014 (4)
Febrero de 2014 (1)
Enero de 2014 (5)
Diciembre de 2013 (8)
Noviembre de 2013 (2)
Octubre de 2013 (7)
Septiembre de 2013 (6)
Agosto de 2013 (1)
Julio de 2013 (6)
Junio de 2013 (11)
Mayo de 2013 (7)
Abril de 2013 (6)
Febrero de 2013 (5)
Enero de 2013 (7)
Diciembre de 2012 (12)
Noviembre de 2012 (13)
Octubre de 2012 (5)
Septiembre de 2012 (3)
Agosto de 2012 (6)
Julio de 2012 (4)
Junio de 2012 (1)
Mayo de 2012 (2)
Abril de 2012 (7)
Marzo de 2012 (16)
Febrero de 2012 (9)
Enero de 2012 (5)
Diciembre de 2011 (10)
Noviembre de 2011 (10)
Octubre de 2011 (4)
Septiembre de 2011 (5)
Agosto de 2011 (2)
Julio de 2011 (2)
Junio de 2011 (4)
Mayo de 2011 (2)
Abril de 2011 (6)
Marzo de 2011 (4)
Febrero de 2011 (10)
Enero de 2011 (5)
Diciembre de 2010 (6)
Noviembre de 2010 (4)
Octubre de 2010 (8)
Septiembre de 2010 (4)
Agosto de 2010 (1)
Julio de 2010 (3)
Mayo de 2010 (5)
Abril de 2010 (6)
Marzo de 2010 (8)
Febrero de 2010 (3)
Enero de 2010 (1)
Diciembre de 2009 (9)
Noviembre de 2009 (14)
Octubre de 2009 (2)
Septiembre de 2009 (8)
Agosto de 2009 (2)
Julio de 2009 (10)
Junio de 2009 (9)
Mayo de 2009 (10)
Abril de 2009 (9)
Marzo de 2009 (3)
Febrero de 2009 (2)
Enero de 2009 (3)
Noviembre de 2008 (2)
Octubre de 2008 (2)
Septiembre de 2008 (2)
Agosto de 2008 (5)
Julio de 2008 (5)
Junio de 2008 (1)
Mayo de 2008 (3)
Abril de 2008 (2)
Marzo de 2008 (2)
Febrero de 2008 (2)
Enero de 2008 (5)
Noviembre de 2007 (2)
Octubre de 2007 (2)






Esta información se proporciona "como está" sin garantías de ninguna clase, y no otorga ningún derecho.
This information is provided "AS IS" with no warranties, and confers no rights.

Copyright © 2007 GuilleSQL, todos los derechos reservados.
GuilleSQL.com y GuilleSQL.net son también parte de Portal GuilleSQL.

Visitas recibidas (Page Loads) en GuilleSQL (fuente: StatCounter):

screen resolution stats
Visitas