¿Cuál es la configuración de seguridad más rápida posible para netTcpBinding?

Question

Estoy ejecutando un servicio WCF que, entre otras cosas, se utiliza como back-end para un sitio web. Debido a que tanto el sitio web como el servicio WCF se ejecutan en la misma máquina, y en aras del rendimiento, lo configuré con un netTcpBinding.

Ahora, la cosa es que, como existen en la misma caja, realmente no me importa ni la seguridad a nivel de transporte ni la encriptación a nivel de mensaje; la única forma posible de interceptar los mensajes es si alguien entra al servidor web, y si lo hacen, ya tengo problemas mayores.

Así que mi pregunta es: cuando el cliente y el servidor ya están en un subsistema confiable, ¿qué configuración se puede usar para asegurar que netTcpBinding sea lo más rápido posible?

Por supuesto, la respuesta podría ser utilizar la seguridad de "ninguno". Pero en mi caso particular, todavía necesito usar la autenticación UserName contra una base de datos personalizada. ¿Se puede configurar para que siga usando la autenticación de Nombre de usuario, pero no se moleste con los certificados o la seguridad de los datos entre los puntos finales? ¿O quizás necesito implementar un comportamiento personalizado con un encabezado SOAP personalizado para almacenar el nombre de usuario/contraseña, y luego realmente puedo establecer la seguridad en "ninguno"?

de configuración del servidor

<netTcpBinding> 
    <binding name="Net_Tcp_Binding"> 
     <security mode="Message"> 
      <message clientCredentialType="UserName" /> 
     </security> 
    </binding> 
    </netTcpBinding> 

Utiliza Nombre de usuario personalizada - básicamente cada llamada autentica & autoriza contra una base de datos personalizada. El lado del servicio también utiliza un certificado para negociar con sus clientes, por ejemplo:

<serviceBehaviors> 
    <behavior name="MyBehavior"> 
    <serviceMetadata httpGetEnabled="true" /> 
    <serviceDebug includeExceptionDetailInFaults="true" /> 
    <serviceAuthorization principalPermissionMode="Custom"> 
     <authorizationPolicies> 
     <add policyType="MyAssembly.CustomAuthorizationPolicy,MyAssembly" /> 
     </authorizationPolicies> 
    </serviceAuthorization> 
    <serviceCredentials> 
     <userNameAuthentication userNamePasswordValidationMode="Custom" customUserNamePasswordValidatorType="MyAssembly.CustomCredentialValidator,MyAssembly" /> 
     <serviceCertificate x509FindType="FindBySubjectName" findValue="CN=servercert" storeLocation="LocalMachine" storeName="My" /> 
    </serviceCredentials> 
    </behavior> 
</serviceBehaviors> 

configuración del cliente

<netTcpBinding> 
    <binding name="Net_Tcp_Endpoint"> 
    <reliableSession ordered="true" inactivityTimeout="00:10:00" enabled="false" /> 
    <security mode="Message"> 
     <message clientCredentialType="UserName" /> 
    </security> 
    </binding> 
</netTcpBinding> 

Answer 1

"Ninguno" sería más rápido, sí :-)

Por Por otro lado, si su servicio y servidor se ejecutan en la misma máquina, también debe considerar seriamente el enlace netNamedPipe, que es el óptimo absoluto si tiene una comunicación "en la máquina". Es incluso más rápido y más eficiente que netTcp.

Para autenticar a la persona que llama contra el servicio, necesitaría usar algún método de seguridad, ya que netNamedPipe solo admite "ninguno" o "Windows", elegiría Windows. Si no usa ninguno, no tiene forma de identificar (autenticar) a la persona que llama y, por lo tanto, no puede tener autorización (quién puede hacer qué) según la identidad de la persona que llama.

Una vez que hayas autenticado a la persona que llama (quién me llama), puedes usar grupos de Windows o el subsistema ASP.NET integrado/proveedor de roles para hacer una autorización basada en roles, para poder hacer seguro de quién puede hacer qué operaciones. Esto se puede configurar usando un comportamiento de servicio llamado <serviceAuthoritzation> en su sección de comportamiento de la configuración del servicio.

Marc