Error de seguridad Silverlight WCF+SSL-crossdomain.xml nunca solicitado

silverlight-4.0 https

Question

(Veo varias preguntas relacionadas con mi problema, pero ninguna de las soluciones me funciona, ya que encuentro este problema en la producción, no durante el desarrollo local, y ya he probado todas las soluciones propuestas).

Tengo una aplicación Silverlight 4 que utiliza servicios WCF alojados por IIS. En producción, se accede a estos servicios a través de HTTPS. A pesar de tener un archivo crossdomain.xml válido , sigo recibiendo el famoso "Error de seguridad" al acceder al servicio:

An error occurred while trying to make a request to URI ''https://MYDOMAIN/MYSERVICE.svc''. This could be due to attempting to access a service in a cross-domain way without a proper cross-domain policy in place, or a policy that is unsuitable for SOAP services. You may need to contact the owner of the service to publish a cross-domain policy file and to ensure it allows SOAP-related HTTP headers to be sent. This error may also be caused by using internal types in the web service proxy without using the InternalsVisibleToAttribute attribute. Please see the inner exception for more details. ---> System.Security.SecurityException ---> System.Security.SecurityException: Security error...

Usando Fiddler puedo ver que no se realiza ninguna solicitud para crossdomain.xml o clientaccesspolicy.xml. Hay una solicitud CONEXIÓN para el servidor, pero eso es todo.

He leído que este error, aunque indica un problema con crossdomain.xml / clientaccesspolicy.xml, también se puede generar cuando el servidor emite un certificado no válido. Esto no parece ser el caso en mi escenario.

Estoy seguro de que lo siguiente está configurado correctamente:
1. crossdomain.xml es válido y está alojado en la raíz del sitio
2. Los servicios sí funcionan (tenemos otros clientes en diversas tecnologías que los utilizan, incluido Adobe Flex que se basa en crossdomain.xml).
3. La aplicación Silverlight funciona (Funciona perfectamente con los servicios y servicios locales en un servidor de desarrollo compartido ***)
4. La aplicación Silverlight ni siquiera intenta solicitar crossdomain.xml o clientaccesspolicy.xml (según lo confirmado por Fiddler)
5. La aplicación Silverlight usa la configuración adecuada para acceder a WCF en lugar de https. Debajo está la configuración:

<configuration>
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_IMyServices" maxBufferSize="2147483647" maxReceivedMessageSize="2147483647">
<security mode="Transport" />
</binding>
</basicHttpBinding>
</bindings>
<client>
<endpoint address="https://MYDOMAIN/MYSERVICE.svc" binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IMyServices" contract="Services.IMyServices" name="BasicHttpBinding_IMyServices" />
</client>
</system.serviceModel>
</configuration>

¿Qué más puede causar este tipo de problema? ¿Podría ser porque los servidores web están balanceados de carga? ¿O hay algún problema con el certificado que no haya notado? Si al menos puede señalarme en la dirección correcta, sería muy apreciado.

(*** Algo que vale la pena señalar: me encontré con un problema similar en nuestro entorno de desarrollo. La aplicación Silverlight no pudo acceder a los servicios de WCF en un servidor de desarrollo compartido, a pesar de tener un crossdomain.xml apropiado y no usar HTTPS. añadiendo el servidor de desarrollo como un sitio de confianza en IE. Sin embargo, esta misma solución no funciona para la producción, y aun así no sería una solución aceptable. Pero el hecho de que tuve que hacer esto en el entorno de desarrollo me hace preocupado de que me haya perdido algo en el camino ...)

Answer 1

El problema era que me faltaba clientaccesspolicy.xml. Tener crossdomain.xml no fue suficiente en este caso. Creo que esto se debe a que la invocación de WCF no fue solo un navegador cruzado sino también un protocolo cruzado (la aplicación de Silverlight se sirvió a través de http, pero los servicios se prestaron a través de https).

Además, mi clientaccesspolicy.xml tuvo que permitir explícitamente el acceso a http de la siguiente manera:

<?xml version="1.0" encoding="utf-8"?>
<access-policy>
<cross-domain-access>
<policy>
<allow-from http-request-headers="SOAPAction">
<!-- IMPORTANT! Include these lines -->
<domain uri="http://*"/>
<domain uri="https://*"/>
</allow-from>
<grant-to>
<resource path="/" include-subpaths="true"/>
</grant-to>
</policy>
</cross-domain-access>
</access-policy>

Ahora funciona como un encanto.

Un par de cosas que me hicieron tropezar en el camino:
* Mi navegador estaba almacenando en caché clientaccesspolicy.xml y crossdomain.xml. Tendría que borrar mi caché cada vez que cambiara uno de esos archivos o no reconocería la versión más reciente, a pesar de que IIS está configurado para evitar el almacenamiento en memoria caché del cliente de este archivo.
* Las solicitudes de clientaccesspolicy.xml y crossdomain.xml no siempre aparecían en Fiddler. A menudo veía las solicitudes CONNECT. No entiendo el motivo, pero he aprendido a no confiar en Fiddler para confirmar que se están realizando estas solicitudes. Tal vez tengo algún ajuste deshonesto en algún lugar (y no, no es la configuración "Descifrar el tráfico HTTPS" que ya deshabilité).

Answer 2

Tengo el mismo error, cuando trato de realizar una llamada a mi sitio a través de http y mi servicio superó https, falló. Este error se produjo porque mi ISS no tenía certificado, por lo tanto, cuando la aplicación intentó descargar la política de acceso público, falló.

Eche un vistazo a cualquier herramienta de depuración en su navegador y busque el archivo clientacccesspolicy, luego verifique si se está descargando.