Cómo redirigir un servicio WCF a un HTTPS punto final con credencial de Windows

Question

Aquí es la situación que estoy tratando de hacer frente a:

Tenemos un cliente WCF que trabaja con un punto final de http y https punto final, pero no cuando se es redireccionado (302) de http a https. Tenemos un equilibrador de carga F5 que está ejecutando el redireccionamiento y la funcionalidad SSL, pero hasta donde puedo decir, no está haciendo nada inesperado para las solicitudes. El redireccionamiento parece ser el culpable de que WCF no desee proporcionar la información de autenticación Kerberos de Windows una vez que se realiza la redirección.

La secuencia para una llamada con éxito (es decir, http sin redirección) dice así:

• Client - envía solicitud POST para el servicio con el esquema http
• Servidor - responde con 401 no autorizado
• Client - Envia Negociar POST con autorización
• Servidor - Responde con 100 Continuar
• Cliente - Envía datos de jabón y completa con éxito

Cuando se redirige la llamada y no va así:

• Cliente - Envía solicitud POST para el servicio con el esquema http
• Servidor - Devuelve 302 con redirección a https esquema para la misma dirección
• Cliente - Envía GET dirección https (no puedo entender por qué esto es un GET y no un POST)
• servidor - Responde con 401 autorizado
• Cliente: lanza la excepción "La solicitud HTTP no está autorizada con el esquema de autenticación del cliente 'Negociar'. El encabezado de autenticación recibido del servidor fue 'Negotiate, NTLM'."

Es similar a this problem pero no exactamente el mismo (y en realidad no hay una respuesta no hace referencia a pesar de que 'romper el protocolo WCF' en el que puedo encontrar documentación). Si desactivamos la regla de redirección F5, el tráfico http y https funciona bien. ¿WCF realmente no maneja este simple redireccionamiento? ¿Hay alguna solución o documentación sobre este error?

Client config (tenga en cuenta que al probar esto con https, cambio TransportCredentialOnly a Transport):

<client> 
     <endpoint address="http://fooserver/MyService.svc/" binding="basicHttpBinding" bindingConfiguration="clientBinding" contract="Contracts.IMyService" /> 
</client> 
<bindings> 
<basicHttpBinding> 
    <binding name="clientBinding"> 
     <security mode="TransportCredentialOnly"> 
      <transport clientCredentialType="Windows" proxyCredentialType="Windows" /> 
     </security> 
    </binding> 
</basicHttpBinding> 

de configuración del servidor se ve así:

<system.serviceModel> 
    <serviceHostingEnvironment multipleSiteBindingsEnabled="true" /> 
    <services> 
     <service behaviorConfiguration="MyServiceBehavior" name="MyService"> 
      <endpoint address="" binding="basicHttpBinding" bindingConfiguration="securedBinding" contract="Contracts.IMyService"> 
      </endpoint> 
     </service> 
    </services> 
    <bindings> 
     <basicHttpBinding> 
      <binding name="securedBinding"> 
       <security mode="TransportCredentialOnly"> 
        <transport clientCredentialType="Windows" proxyCredentialType="Windows"/> 
       </security> 
      </binding> 
     </basicHttpBinding> 
    </bindings> 
    <behaviors> 
     <serviceBehaviors> 
      <behavior name="MyServiceBehavior"> 
       <serviceMetadata httpGetEnabled="true"/> 
       <serviceDebug includeExceptionDetailInFaults="true"/> 
       <useRequestHeadersForMetadataAddress> 
        <defaultPorts> 
         <add scheme="http" port="80" /> 
         <add scheme="https" port="443" /> 
        </defaultPorts> 
       </useRequestHeadersForMetadataAddress> 
      </behavior> 
     </serviceBehaviors> 
    </behaviors> 
</system.serviceModel> 

Answer 1

No puedo entender por qué esto es un GET y POST no

Esa es la causa de su problema. Después de recibir una respuesta 302 a un POST, se espera que el comportamiento de un cliente OBTENGA la nueva URL.Ver lo siguiente en http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

Si el código de estado 302 se recibe en respuesta a una solicitud que no sea GET o HEAD, el agente de usuario no debe redirigir automáticamente la solicitud a menos que pueda ser confirmado por el usuario, ya que esto podría cambiar las condiciones bajo las cuales se emitió la solicitud.

Además, los siguientes SO entrada no tiene buena información: Response.Redirect with POST instead of Get?

Así WCF está haciendo lo que debe hacer al negarse a volver a colocar después de una redirección 302. Lamentablemente, no estoy seguro de qué se puede hacer para resolver su problema, salvo especificar el protocolo correctamente la primera vez para evitar el 302.

Answer 2

Acabo de hacer algo similar y puedo confirmar que esto no funciona. Lo que es aún peor, probablemente no sea posible cambiar sin reemplazar la implementación de transporte HTTP de WCF predeterminada.

Tanto la redirección como la autenticación se manejan directamente dentro del procesamiento HTTP de WCF que es interno. No puede manejar la redirección de forma manual, lo que causa un problema si obtiene 301 Se movió permanentemente y WCF no usa sus credenciales de cliente configuradas después de la redirección.

El problema con el envío de GET en vez del poste después de redirección debe resolverse teóricamente mediante la devolución de 307 redirección temporal en lugar de 302 Found.