Última hora: Keyfactor adquiere InfoSec Global y CipherInsights | Soluciones integrales para descubrimiento, control y agilidad

  • Inicio
  • Blog
  • Directorio activo de Microsoft Windows Azure

Directorio activo de Microsoft Windows Azure

Microsoft Windows Azure Active Directory abre oportunidades para que personas y organizaciones utilicen aplicaciones en cualquier lugar basándose en la conectividad ubicua en la nube y en protocolos estándar abiertos como OAuth, SAML-P, WS-Federation y el paradigma REST API.

Es posible realizar el siguiente escenario de caso de uso combinando los paquetes de vista previa de Azure Active Directory (AAD) con las tecnologías de habilitación integradas.

Supongamos que el proveedor de identidades utiliza AAD como almacén de identidades con puntos finales de URL de federación, inicio de sesión y OAuth.

1. El usuario de este proveedor de identidades intenta acceder al proveedor de servicios.

2. El Proveedor de Servicios presenta una página Home Realm Discovery para que el usuario seleccione Home.

3. El usuario selecciona este proveedor de identidades y es redirigido al proveedor de identidades con el flujo SAML-P.

4. El proveedor de identidades detecta que no existe sesión y delega el proceso de autenticación al punto final de inicio de sesión de AAD (con la vista previa, puede aprovechar la página de inicio de sesión de Office 365).

5. AAD presenta la página de inicio de sesión para que el usuario proporcione las credenciales e inicia la sesión.

6. AAD POST el token de seguridad WS-Federation al proveedor de identidades que consume las reclamaciones que contienen la información del usuario autenticado.

7. El proveedor de identidades transforma el token de seguridad y lo envía por POST al proveedor de servicios.

8. Suponiendo que el proveedor de servicios no pueda asignar el autenticado a la cuenta de identidad.

9. El Proveedor de Servicios inicia el flujo OAuth 2.0 JWT hablando con AAD para extraer datos de usuario a través de la API Graph del directorio.

10. Ahora el proveedor de servicios aprovisiona la cuenta para el usuario autenticado.

 

Otro posible escenario de uso puede ser el siguiente:

1. El usuario de este proveedor de identidades intenta acceder al proveedor de servicios.

2. El Proveedor de Servicios presenta una página Home Realm Discovery para que el usuario seleccione Home.

3. El usuario selecciona este proveedor de identidades y es redirigido al proceso de inicio de sesión del proveedor de identidades con el flujo de concesión de código de autorización OAuth 2.0 estándar.

4. El proveedor de identidades comprueba que no existe sesión y delega el proceso de autenticación en el punto final de inicio de sesión de AAD.

5. AAD presenta la página de inicio de sesión para que el usuario proporcione las credenciales e inicia la sesión.

6. AAD POST el token de seguridad WS-Federation al proveedor de identidades que consume las reclamaciones que contienen la información del usuario autenticado.

7. El proveedor de identidades solicita el código de acceso OAuth en nombre del usuario autenticado delegando el proceso de autorización OAuth al endpoint OAuth de AAD.

8. Una vez que el Servidor de Identidad obtiene el código de acceso y redirige al URI de redirección pasado por el Proveedor de Servicios.

9. Ahora el Proveedor de Servicios solicita un token de acceso al Proveedor de Identidades utilizando el código de autorización.

10. El proveedor de identidades realiza un proceso similar delegando el proceso OAuth para solicitar el token de acceso.

11. Una vez que el proveedor de identidades obtiene el token de acceso y redirige al URI de redirección pasado por el proveedor de servicios.

12. El proveedor de servicios utiliza el token de acceso para comunicarse con el servidor de recursos del proveedor de identidades y obtener información sobre el usuario autenticado.