Quelle est la configuration de sécurité la plus rapide possible pour netTcpBinding?

Question

J'utilise un service WCF qui, entre autres, est utilisé comme backend pour un site web. Parce que le site Web et le service WCF s'exécutent sur la même machine, et dans l'intérêt de la performance, je l'ai configuré avec netTcpBinding. Maintenant, la chose est, car ils existent sur la même boîte, je ne me soucie pas vraiment de la sécurité au niveau du transport ou du cryptage au niveau du message; La seule façon possible d'intercepter les messages est de savoir si quelqu'un entre dans le serveur Web lui-même, et s'ils le font, j'ai déjà de plus gros problèmes. Donc, ma question est la suivante: lorsque le client et le serveur sont déjà sur un sous-système de confiance, quelle configuration peut-on utiliser pour s'assurer que netTcpBinding est aussi rapide que possible?

Bien sûr, la réponse pourrait être d'utiliser la sécurité de "none". Mais dans mon cas particulier, j'ai toujours besoin d'utiliser l'authentification UserName par rapport à une base de données personnalisée. Peut-il être configuré pour qu'il utilise toujours l'authentification UserName, mais ne dérange pas avec des certificats ou la sécurisation des données entre les points de terminaison? Ou dois-je peut-être mettre en œuvre un comportement personnalisé avec un en-tête SOAP personnalisé pour stocker le nom d'utilisateur/mot de passe, puis je peux vraiment définir la sécurité sur "none"?

serveur Config

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

Il utilise l'authentification UserName personnalisée - essentiellement chaque appel authentifie & autorise contre une base de données personnalisée. Le côté service utilise également un certificat de négocier avec ses clients, par exemple:

<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> 

client Config

<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

"Aucun" serait le plus rapide, oui :-)

Sur la D'autre part, si votre service et votre backend sont exécutés sur la même machine, vous devriez également avoir un regard sérieux sur la liaison netNamedPipe, qui est l'optimum absolu si vous avez une communication "sur machine". C'est encore plus rapide et plus efficace que netTcp. Pour authentifier l'appelant par rapport au service, vous devez utiliser une méthode de sécurité - puisque netNamedPipe ne supporte que «none» ou «Windows», je choisirais Windows. Si vous n'en utilisez aucun, vous n'avez aucun moyen d'identifier (authentifier) ​​l'appelant, et ainsi, vous ne pouvez pas avoir d'autorisation (qui peut faire quoi) en fonction de l'identité de l'appelant. Une fois que vous avez authentifié l'appelant (qui m'appelle), vous pouvez utiliser des groupes Windows ou le sous-système d'appartenance/de rôle ASP.NET intégré pour effectuer l'autorisation basée sur les rôles, afin de sûr qui peut faire quelles opérations. Cela peut être configuré en utilisant un comportement de service appelé <serviceAuthoritzation> dans votre section de comportement de la configuration du service.

Marc