Información general sobre seguridad

El marco de seguridad de la API de servicios web de Windows (WWSAPI) proporciona:

• Integridad de mensajes, confidencialidad, detección de reproducción y autenticación del servidor mediante la seguridad de transporte.
• Autenticación de cliente, como la validación de tokens de seguridad, las comprobaciones de confianza y revocación de certificados, etc. mediante la seguridad de los mensajes SOAP o la seguridad de transporte.

El modelo de programación de seguridad

La seguridad está asociada a los canales de comunicación. La protección de un canal consta de los pasos siguientes.

• Cree e inicialice uno o varios enlaces de seguridad adecuados para los requisitos de seguridad de la aplicación.
• Cree una descripción de seguridad que contenga esos enlaces de seguridad.
• Cree un proxy de servicio o canal (en el lado cliente) o cree un agente de escucha o host de servicio (en el lado servidor) pasando esa descripción de seguridad.
• Realice los pasos de programación de canales normales de Open, Accept, Send, Receive, Close, etc.

El tiempo de ejecución protege automáticamente los mensajes enviados y recibidos en el canal según la descripción de seguridad proporcionada. Opcionalmente, estos pasos se pueden ajustar especificando una o varias opciones de seguridad para todo el canal en la descripción de seguridad o la configuración de seguridad de enlace en un enlace de seguridad.

La aplicación debe realizar cualquier autorización necesaria de identidades de remitente mediante los resultados de procesamiento de seguridad adjuntos a cada mensaje recibido. Los pasos de autorización no se especifican en la descripción de seguridad, ni los realiza automáticamente el tiempo de ejecución.

Los errores en la descripción de seguridad, como enlaces no admitidos, propiedades o campos inaplicables, faltan propiedades o campos obligatorios o valores de propiedad o campo no válidos, harán que se produzca un error en la creación del canal o del agente de escucha.

Selección de enlaces de seguridad

Al diseñar la seguridad para una aplicación, la decisión principal es la selección de los enlaces de seguridad que se incluirán en la descripción de seguridad. A continuación se muestran algunas instrucciones para elegir enlaces de seguridad adecuados para el escenario de seguridad de una aplicación. Una heurística útil es comprender primero qué tipos de credenciales de seguridad (como certificados X.509, nombre de usuario y contraseñas de dominio de Windows, nombre de usuario y contraseñas definidos por la aplicación) estarán disponibles para la aplicación y, a continuación, elegir un enlace de seguridad que pueda usar ese tipo de credencial.

• Seguridad de transporte, donde la seguridad se aplica en el nivel de flujo de bytes de transporte (por debajo de los límites del mensaje SOAP), es la primera opción que se debe tener en cuenta.

  • En escenarios de Internet y en aquellos escenarios de intranet en los que se puede implementar un certificado X.509 en el servidor, la aplicación puede usar WS_SSL_TRANSPORT_SECURITY_BINDING. En el ejemplo siguiente se muestra esta opción. Cliente: HttpClientWithSslExample Server: HttpServerWithSslExample.

    Si se desea la autenticación de cliente a través de la autenticación de encabezado HTTP, se puede agregar un WS_HTTP_HEADER_AUTH_SECURITY_BINDING para proporcionar esa funcionalidad.

  • En escenarios de intranet en los que los protocolos de autenticación integrada de Windows, como Kerberos, NTLM y SPNEGO son adecuados, la aplicación puede usar WS_TCP_SSPI_TRANSPORT_SECURITY_BINDING. En el ejemplo siguiente se muestra esta opción: Client: RequestReplyTcpClientWithWindowsTransportSecurityExample Server: RequestReplyTcpServerWithWindowsTransportSecurityExample.

    Cliente sobre canalizaciones con nombre: RequestReplyNamedPipesClientWithWindowsTransportSecurityExample

    Servidor sobre canalizaciones con nombre: RequestReplyNamedPipesServerWithWindowsTransportSecurityExample

  • En escenarios de máquina local en los que los protocolos de autenticación integrada de Windows, como Kerberos, NTLM y SPNEGO son adecuados, la aplicación puede usar WS_TCP_SSPI_TRANSPORT_SECURITY_BINDING o WS_NAMEDPIPE_SSPI_TRANSPORT_SECURITY_BINDING. LaWS_NAMEDPIPE_CHANNEL_BINDING es preferible en estos escenarios porque garantiza que el tráfico no salga de la máquina (esta es la propiedad de WS_NAMEDPIPE_CHANNEL_BINDING).

• Seguridad en modo mixto, donde la seguridad de transporte protege la conexión y un encabezado WS-Security en el mensaje SOAP proporciona autenticación de cliente, es la siguiente opción que se debe tener en cuenta. Los siguientes enlaces se usan junto con uno de los enlaces de seguridad de transporte descritos en la sección anterior.

  • Cuando un par de nombre de usuario y contraseña de nivel de aplicación autentica el cliente, la aplicación puede usar un WS_USERNAME_MESSAGE_SECURITY_BINDING para proporcionar los datos de autenticación. En los ejemplos siguientes se muestra el uso de este enlace junto con un WS_SSL_TRANSPORT_SECURITY_BINDING:

    • Cliente: HttpClientWithUsernameOverSslExample
    • Servidor: HttpServerWithUsernameOverSslExample

  • Cuando un vale kerberos autentica al cliente, la aplicación puede usar un WS_KERBEROS_APREQ_MESSAGE_SECURITY_BINDING para proporcionar los datos de autenticación.

  • Al usar un contexto de seguridad, el cliente establece primero un contexto de seguridad con el servidor y, a continuación, usa ese contexto para autenticar los mensajes. Para habilitar esta funcionalidad, la descripción de seguridad debe contener un WS_SECURITY_CONTEXT_MESSAGE_SECURITY_BINDING. Una vez establecido, los contextos de seguridad se pueden transmitir mediante tokens ligeros, lo que evita tener que enviar las credenciales de cliente potencialmente grandes y costosas a nivel computacional con cada mensaje.

  • En un escenario de seguridad federado , el cliente obtiene primero un token de seguridad emitido por un servicio de token de seguridad (STS) y, a continuación, presenta el token emitido a un servicio. Lado cliente: para obtener el token de seguridad del STS, la aplicación puede usar WsRequestSecurityToken. Como alternativa, la aplicación puede usar una biblioteca de proveedores de tokens de seguridad del lado cliente, como CardSpace o LiveID, y luego usar su salida para crear localmente un token de seguridad mediante WsCreateXmlSecurityToken. En cualquier caso, una vez que el token de seguridad está disponible para el cliente, se puede presentar al servicio mediante una descripción de seguridad que contiene un WS_XML_TOKEN_MESSAGE_SECURITY_BINDING. Servidor: si el token de seguridad emitido por el STS es un token SAML, el servidor puede usar una descripción de seguridad con un WS_SAML_MESSAGE_SECURITY_BINDING.

    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.

     

• La última opción que se debe tener en cuenta es usar enlaces de autenticación sin usar un enlace de protección como WS_SSL_TRANSPORT_SECURITY_BINDING. Esto dará lugar a que las credenciales se transmitan en texto no cifrado y pueden tener implicaciones de seguridad. El uso de esta opción debe evaluarse cuidadosamente para asegurarse de que no hay vulnerabilidades como resultado. Un ejemplo de uso potencial es intercambiar mensajes entre servidores back-end a través de una red privada segura. Las siguientes configuraciones admiten esta opción.

  • WS_HTTP_HEADER_AUTH_SECURITY_BINDING admite esta opción en todas las configuraciones.
  • WS_USERNAME_MESSAGE_SECURITY_BINDING admite esta opción en el servidor cuando se usa HTTP como transporte.
  • WS_KERBEROS_APREQ_MESSAGE_SECURITY_BINDING admite esta opción en el servidor cuando se usa HTTP como transporte.
  • WS_SECURITY_CONTEXT_MESSAGE_SECURITY_BINDING admite esta opción en el servidor cuando se usa HTTP como transporte.
  • WS_SAML_MESSAGE_SECURITY_BINDING admite esta opción en el servidor cuando se usa HTTP como transporte.

  La habilitación de esta opción requiere establecer explícitamente el WS_PROTECTION_LEVEL en un valor distinto de WS_PROTECTION_LEVEL_SIGN_AND_ENCRYPT.

Canales y seguridad

Como se indicó anteriormente, la seguridad se limita a los canales. Además, las operaciones de canal se asignan a los pasos de seguridad de forma coherente en todos los enlaces de seguridad.

• Creación de canal: el conjunto de enlaces de seguridad especificados en la descripción de seguridad se valida y permanece fijo para el canal a partir de entonces. También se determina la forma de la pila de canales, incluidos los canales laterales que se van a usar para WS-Trust negociaciones basadas.
• Canal abierto: se cargan todas las credenciales proporcionadas como parte de los enlaces de seguridad y se establecen sesiones de seguridad. En general, un canal abierto contiene el estado de seguridad "live". La apertura de un canal de cliente también especifica la dirección del punto de conexión del servidor en la que el tiempo de ejecución realizará la autenticación del servidor.
• Entre el canal abierto y el cierre: los mensajes se pueden enviar y recibir de forma segura durante esta fase.
• Envío de mensajes: los tokens de contexto de seguridad se obtienen o renuevan según sea necesario y la seguridad se aplica a cada mensaje transmitido según la descripción de seguridad. Los errores que se producen al aplicar la seguridad se devuelven a la aplicación como errores de envío.
• Recepción de mensajes: la seguridad se comprueba en cada mensaje recibido según la descripción de seguridad. Los errores de comprobación de seguridad de los mensajes se devuelven a la aplicación como errores de recepción. Estos errores por mensaje no afectan al estado del canal ni a las recepciones posteriores. La aplicación puede descartar una recepción con errores y reiniciar una recepción para otro mensaje.
• Anulación del canal: el canal se puede anular en cualquier momento para detener todas las E/S en el canal. Al anular, el canal pasará a un estado defectuoso y no permitirá más envíos ni recepciones. Sin embargo, el canal todavía puede conservar algún estado de seguridad "activo", por lo que será necesario cerrar un canal posterior para eliminar todo el estado de forma limpia.
• Cierre del canal: el estado de seguridad creado en la apertura se elimina y se eliminan las sesiones. Los tokens de contexto de seguridad se cancelan. La pila del canal permanece, pero no contiene ningún estado de seguridad "activo" ni credenciales cargadas.
• Canal gratis: la pila de canales creada en la creación, junto con todos los recursos de seguridad, se libera.

API de seguridad

La documentación de la API para la seguridad se agrupa en los temas siguientes.

• Descripción de la seguridad
  • Configuración del canal de seguridad
  • Enlaces de seguridad
    • Credenciales de seguridad
    • Configuración de enlace de seguridad
• Federación
• Contexto de seguridad
• Identidad de extremo
• Resultados del procesamiento de seguridad

Seguridad

Al usar la API para seguridad WWSAPI, las aplicaciones se enfrentan a varios riesgos de seguridad:

Configuración incorrecta accidental

WWSAPI admite una variedad de opciones de configuración relacionadas con la seguridad. Consulte, por ejemplo , WS_SECURITY_BINDING_PROPERTY_ID. Algunas de estas opciones, como WS_SECURITY_BINDING_PROPERTY_ALLOW_ANONYMOUS_CLIENTS permiten que la aplicación reduzca el nivel predeterminado de seguridad proporcionado por los distintos enlaces de seguridad. El uso de estas opciones debe evaluarse cuidadosamente para asegurarse de que no haya vectores de ataque resultantes.

Además, como se ha descrito anteriormente, WWSAPI permite que una aplicación deshabilite deliberadamente ciertos pasos necesarios para proteger completamente un intercambio de mensajes, como permitir deshabilitar el cifrado aunque se transmitan las credenciales de seguridad. Esto puede habilitar determinados escenarios específicos y no debe usarse para la comunicación general. El WS_PROTECTION_LEVEL debe reducirse específicamente para habilitar estos escenarios y las aplicaciones no deben cambiar ese valor a menos que sea absolutamente necesario, ya que, al hacerlo, se deshabilitarán muchas comprobaciones diseñadas para garantizar una configuración segura.

Almacenamiento de información confidencial en memoria

La información confidencial, como las contraseñas, que se almacena en memoria es vulnerable a ser extraída por un atacante con privilegios mediante, por ejemplo, el archivo de página. WWSAPI realiza una copia de las credenciales proporcionadas y cifra esa copia, dejando los datos originales desprotegidos. Es responsabilidad de la aplicación proteger la instancia original. Además, la copia cifrada se descifra brevemente mientras se usa, abriendo una ventana para extraerla.

Denegación de servicio

El procesamiento de seguridad puede consumir recursos significativos. Cada enlace de seguridad adicional aumenta esos costos. WWSAPI anula el procesamiento de seguridad en cuanto se detecta un error de comprobación de seguridad, pero ciertas comprobaciones, como las decisiones de autorización, pueden no tener lugar hasta después de que se haya realizado un trabajo significativo.

Mientras se procesa un mensaje en el servidor, el estado de seguridad se almacena en el montón de mensajes. La aplicación puede limitar el consumo de memoria durante el procesamiento de seguridad reduciendo el tamaño de ese montón a través de WS_MESSAGE_PROPERTY_HEAP_PROPERTIES. Además, algunos enlaces de seguridad como el WS_SECURITY_CONTEXT_MESSAGE_SECURITY_BINDING pueden hacer que el servidor asigne recursos en nombre del cliente. Los límites de esos recursos se pueden configurar mediante los siguientes valores de WS_SECURITY_BINDING_PROPERTY_ID :

• WS_SECURITY_BINDING_PROPERTY_SECURITY_CONTEXT_MAX_PENDING_CONTEXTS
• WS_SECURITY_BINDING_PROPERTY_SECURITY_CONTEXT_MAX_ACTIVE_CONTEXTS
• WS_SECURITY_BINDING_PROPERTY_SECURITY_CONTEXT_RENEWAL_INTERVAL
• WS_SECURITY_BINDING_PROPERTY_SECURITY_CONTEXT_ROLLOVER_INTERVAL

Establecer esos límites en valores bajos reduce el consumo máximo de memoria, pero puede provocar que se rechacen clientes legítimos cuando se alcanza la cuota.