La federación de identidades se basa en la confianza. Como muestra el diagrama siguiente, todos los participantes en dicha federación de identidades forman un ciclo de confianzas. Se puede ampliar fácilmente la autenticación federada para Windows Azure Service Bus a comunidades de usuarios externas con identidad social, identidad en la nube del inquilino de Windows Azure Active Directory (WAAD) o identidad del socio empresarial. También es compatible con protocolos de federación como SAML-P, WS-Fed y OpenID.
En el escenario anterior, la aplicación cliente se implementa como claim-aware y accesible a los usuarios finales con la identidad federada mencionada anteriormente. Una vez que el usuario inicia sesión en la aplicación cliente, aprovecha el bus de servicios de Windows Azure para realizar tareas empresariales.
Active Directory Federation Service (ADFS) actúa como proveedor de identidad para usuarios internos (empleados) y como servicio de token de seguridad (STS) para usuarios externos con identidad federada. En este post, el STS se describe como un intermediario de autenticación que no sólo se encarga de la generación de tokens de seguridad, sino también del intercambio y la transmisión de tokens de seguridad. La relación entre WAAD y Windows Azure Access Control Service (ACS) es similar a ADFS como proveedor de identidad
y como rol de servicio de token de seguridad. Además, ACS también puede ser un rol de proveedor de identidad, uno de los roles STS, con sus propias identidades de servicio.
Para que un cliente pueda trabajar con Azure Service Bus, puede obtener un token SAML de ADFS. El cliente presenta el token SAML al ACS autocreado de Service Bus (SB ACS) para intercambiarlo como token SWT. A continuación, el cliente envía la solicitud a Service Bus junto con el token SWT.
En la implementación más sencilla, el cliente está asegurado por ADFS como parte de confianza y recibe reclamaciones una vez que el usuario está autenticado. A continuación, el cliente utiliza WS-Trust para obtener un token SAML aplicado a SB-ACS desde ADFS. Esta implementación desconecta la identidad del llamante (la identidad con credenciales utilizada en WS-Trust). Una vez más, es necesario mantener la integridad entre estas dos identidades separadas, si la información de la reclamación del sujeto es importante que sea conocida por el servicio.
Como alternativa, el cliente puede suplantar al usuario final utilizando la URL de retorno como medio para consumir un token SAML aplicado a SB-ACS o un token SWT aplicado a Azure Service Bus dentro del contexto de identidad de un único sujeto.
Recorramos el caso de uso del socio comercial con el proveedor de identidades SAML-P.
- El usuario intenta acceder a la aplicación cliente
- El cliente redirige la solicitud no autenticada a ADFS
- El usuario selecciona el IdP SAML-P durante el proceso Home Realm Discovery (HRD)
- ADFS envía un mensaje SAMLRequest al IdP SAML-P
- SAML-P IdP autentica al usuario
- SAML-P devuelve el token SAML a ADFS
- ADFS genera un nuevo token SAML basado en las reglas de reclamación
- El navegador envía automáticamente un nuevo token SAML al cliente
- El cliente presenta un nuevo token SAML al SB-ACS
- SB-ACS intercambia el token SAML como token SWT en función de las reglas de reclamación
- El cliente presenta el token SWT con la solicitud de servicio a Azure Service Bus
- Azure Service Bus valida el token y permite que la solicitud pase al servicio requerido
El proceso es similar desde otros proveedores de identidad como Social IdP o WAAD tenant instance a través de Windows Azure ACS como proveedor de federación a ADFS. WAAD también implementa SAML-P como proveedor de identidad, siempre que se admita RelayState. En estos casos, se puede establecer una relación de confianza de federación entre WAAD como proveedor de identidad y ADFS como proveedor de servicios utilizando el término SAML-P.
