Conecte Azure Active Directory al AD del cliente local

Conecte Azure Active Directory al AD del cliente local

Tenemos una aplicación web que se ejecuta en Windows Azure donde una variedad de clientes pueden iniciar sesión. Últimamente, cada vez más de ellos han estado solicitando algún tipo de solución de inicio de sesión único, o al menos una sincronización de sus usuarios locales/de dominio con los presente en nuestra aplicación. He analizado varias opciones pero realmente no he encontrado ninguna que me parezca factible. A continuación enumero lo que he estado viendo, pero básicamente me gustaría recibir algún consejo sobre cómo abordar este problema.

Existen servicios de terceros que podrían hacer esto, pero generalmente su implementación requiere algo o mucho trabajo tanto para nosotros como para nuestros clientes. Esto también podría significar que tendríamos que implementar varias o muchas de estas soluciones según las preferencias del cliente.

La mayoría, si no todos, de nuestros clientes tendrán un Active Directory local y sería perfecto si de alguna manera pudiéramos usarlo también con nuestra aplicación. Conectar nuestra aplicación web a un AD local no es realmente una opción porque los administradores del sistema (comprensiblemente) no nos darán acceso a ella.

También podemos configurar un AD en Azure. Entonces pensé que tal vez podríamos sincronizar desde el AD local con nuestro AD en Azure y luego continuar desde allí. Sin embargo, al probar la herramienta Azure Active Directory Connect de Microsoft, me pidió un inicio de sesión de administrador para nuestro entorno Azure. Obviamente no queremos darles a nuestros clientes acceso a nuestro portal Azure, por lo que parece que esto no funcionará tan bien.

Otro problema en todo esto es que soy programador y todo el material de AD está un poco fuera de mi zona de confort y podría estar buscando en los lugares equivocados.

¿Alguien tiene alguna experiencia con algo de esto y puede indicarme la dirección correcta?

Respuesta1

ADConnect es la forma de sincronizar el directorio local con su nube. Solicita un nombre de usuario y contraseña para configurar la sincronización inicial y realizar cambios en la sincronización si vuelve a iniciar sesión con la herramienta. También necesitarás una cuenta DA para un administrador local mientras la configuras. Si no tiene ninguna o ninguna de las dos cuentas, no podrá completar la configuración.

Según lo que sugiere, Azure B2C es lo que desea configurar. De lo contrario, configure la federación ADFS entre sus dominios y los dominios de los clientes para que no tenga que preocuparse por solicitar ningún nombre de usuario/contraseña. Supongo que sus aplicaciones son compatibles con las reclamaciones y que tiene su propio Windows AD para permitir que se configure ADFS.

Si está intentando configurar un entorno de prueba ADFS, seguí el blog de 4 partes para crear mi primer laboratorio; espero que también funcione bien para usted.

http://blogs.technet.com/b/askpfeplat/archive/2013/12/09/how-to-build-your-adfs-lab-on-server-2012-part-1.aspx http://blogs.technet.com/b/askpfeplat/archive/2013/12/23/how-to-build-your-adfs-lab-on-server-2012-part2-web-sso.aspx

Respuesta2

Si configura la aplicación para admitir la autenticación SAML, un cliente podría configurar su ADFS (u otro) para que funcione con su AD. Normalmente, así es como se maneja el SSO para aplicaciones de terceros.

La forma en que funciona es que usted aún administra las identidades y el acceso a la aplicación, pero los clientes pueden tomar eso y vincularlo a su propio "reclamo" que puede contener nombres de usuario de AD. Esto es lo que hacen ADFS y otras plataformas de identidad federadas (la parte de federación). Sin embargo, es necesario proporcionar una manera de crear confianza entre los proveedores de identidad (el suyo y el de ellos).

Por su parte, puede crear un proveedor de identidad personalizado, utilizar un servicio de terceros o implementar un servidor de federación como ADFS. Pero también hay otros (tanto comerciales como de código abierto) como PingFederate y Shibboleth. Hay literalmente cientos de opciones allí. Si desea un SDK, Ping Identity (desarrolladores de PingFederate), ofrezca uno para varios idiomas (Java, C#, etc.). Estoy seguro de que también existen SDK de código abierto para ayudar.

La identidad es un tema complejo: cuanto más pueda transferirlo a una empresa o equipo dedicado, mejor estará (Azure B2C está en versión preliminar como se indica en otras respuestas, pero mire a terceros si desea avanzar más rápido).

información relacionada