Compartir a través de

Federación

  • Artículo

La federación permite la delegación de autoridad de autorización a otros miembros de una interprise. Por ejemplo, considere el siguiente problema empresarial: La empresa de fabricación de piezas automáticas Contoso Ltd desea permitir que los empleados autorizados de su cliente Fabrikam Inc accedan de forma segura al servicio web de pedidos de piezas de Contoso. Una solución de seguridad para este escenario es que Contoso configure un mecanismo de confianza con Fabrikam para delegar la decisión de autorización de acceso a Fabrikam. Este proceso podría funcionar de la siguiente manera:

  • Fabrikam, cuando se convierte en asociado de Contoso, configura un contrato de confianza con Contoso. El objetivo de este paso es aceptar el tipo de token de seguridad y el contenido que representará la autorización de Fabrikam y será aceptable para Contoso. Por ejemplo, puede decidirse que un certificado X.509 de confianza con el nombre de sujeto "CN=Fabrikam Inc Supplier STS" debe firmar un token SAML para que el servicio web contoso acepte ese SAML. Además, puede decidirse que la notificación de seguridad del token SAML emitido debe ser "https://schemas.contoso.com/claims/lookup" (para la autorización de búsqueda de partes) o "https://schemas.contoso.com/claims/order" (para la autorización de ordenación de partes).
  • Cuando un empleado de Fabrikam usa la aplicación de pedidos de piezas internas, primero se pone en contacto con un servicio de token de seguridad (STS) dentro de Fabrikam. Ese empleado se autentica mediante el mecanismo de seguridad interno de Fabrikam (por ejemplo, nombre de usuario o contraseña de dominio de Windows), se comprueba su autorización para ordenar elementos y se emite un token SAML de corta duración que contiene las notificaciones adecuadas y firmadas por el certificado X.509 decidido anteriormente. A continuación, la aplicación de ordenación de elementos se pone en contacto con el servicio Contoso que presenta el token SAML emitido para autenticar y realizar la tarea de ordenación.

Aquí, el STS de Fabrikam actúa como "parte emisora" y el servicio de piezas de Contoso actúa como el "usuario de confianza". Diagrama que muestra un usuario emisor y un usuario de confianza en una federación.

Características de federación

A continuación se muestran las características de seguridad admitidas para las partes o roles implicados en un escenario de federación:

  • Lado cliente: para obtener el token de seguridad del STS, se puede usar la función WsRequestSecurityToken . Como alternativa, puede usar una biblioteca de proveedores de tokens de seguridad del lado cliente como CardSpace o LiveID y, a continuación, usar su salida para crear localmente un token de seguridad mediante WsCreateXmlSecurityToken. En cualquier caso, una vez que el cliente tiene el token de seguridad, puede crear un canal para el servicio que especifique WS_XML_TOKEN_MESSAGE_SECURITY_BINDING para presentar el token, junto con un enlace de seguridad de transporte, como WS_SSL_TRANSPORT_SECURITY_BINDING para proteger el canal.
  • Lado servidor: en un escenario de federación con un servicio de token de seguridad que emite tokens SAML, el servidor puede usar el WS_SAML_MESSAGE_SECURITY_BINDING, junto con un enlace de seguridad de transporte, como WS_SSL_TRANSPORT_SECURITY_BINDING para proteger el canal.
  • STS: tenga en cuenta que el STS es una aplicación de servicio web y puede especificar los requisitos de seguridad para aquellos que solicitan un token de seguridad mediante una estructura de descripción de seguridad en el momento de creación del agente de escucha, igual que cualquier otro servicio web seguro. A continuación, puede analizar las cargas de mensajes de solicitud entrantes para validar las solicitudes de token y enviar tokens emitidos como cargas de mensajes de respuesta. Actualmente, no se proporcionan características para ayudar a estos pasos de análisis y emisión.

Tenga en cuenta que el lado cliente puede controlar el token de seguridad emitido de forma genérica como un token de seguridad XML sin conocer el tipo de token o realizar un procesamiento específico del tipo de token. Sin embargo, el servidor tiene que comprender el tipo de token de seguridad específico para comprenderlo y procesarlo. Los pasos de solicitud y respuesta del token de seguridad usan las construcciones definidas en la especificación de WS-Trust.

Escenarios de federación más complejos

Un escenario de federación puede implicar varios STS que forman una cadena de federación. Considere el ejemplo siguiente:

  • El cliente se autentica en el STS de LiveID mediante un nombre de usuario o contraseña de LiveID y obtiene un token de seguridad T1.
  • El cliente se autentica en STS1 mediante T1 y obtiene un token de seguridad T2.
  • El cliente se autentica en STS2 mediante T2 y obtiene un token de seguridad T3.
  • El cliente se autentica en el servicio de destino S mediante T3.

Aquí, liveID STS, STS1, STS2 y S forman la cadena de federación. Los STS de una cadena de federación pueden realizar varios roles para el escenario general de la aplicación. Entre los ejemplos de estos roles funcionales de STS se incluyen el proveedor de identidades, el creador de decisiones de autorización, el anonimizador y el administrador de recursos.

Parámetros de solicitud STS y intercambio de metadatos

Para que el cliente realice una llamada de WsRequestSecurityToken correcta, debe conocer los parámetros de esa llamada (como el tipo de token y los tipos de notificación necesarios), los requisitos de descripción de seguridad del canal de solicitud al STS y la dirección del punto de conexión del STS. La aplicación cliente puede usar cualquiera de las técnicas siguientes para determinar esta información:

  • Codifique de forma rígida la información de la aplicación como parte de las decisiones en tiempo de diseño.
  • Lea esta información de un archivo de configuración de nivel de aplicación configurado por el implementador de aplicaciones local.
  • Detecte dinámicamente esta información en tiempo de ejecución mediante la característica de importación de metadatos con la estructura WS_ISSUED_TOKEN_MESSAGE_SECURITY_BINDING_CONSTRAINT .

Para ilustrar el uso de MEX dinámico con federación, considere el ejemplo 3 STS anterior. El cliente realizará primero un MEX dinámico con S para obtener información sobre T3 (es decir, qué pedir desde STS2), así como la dirección MEX dinámica STS2 (es decir, dónde encontrar STS2). A continuación, usará esa información para realizar una MEX dinámica con STS2 para descubrir información sobre T2 y STS1, etc.

Por lo tanto, los pasos dinámicos de MEX tienen lugar en el orden 4, 3, 2, 1 para crear la cadena de federación y los pasos de solicitud de token y presentación tienen lugar en el orden 1, 2, 3, 4 para desenredar la cadena de federación.

Nota

Windows 7 y Windows Server 2008 R2: WWSAPI solo admite Ws-Trust y Ws-SecureConversation, tal y como se define en El perfil de seguridad de servicios web ligeros (LWSSP). Para obtener más información sobre la implementación de Microsoft, consulte la sección Sintaxis message de LWSSP.