2009-08-23 13 views
6

Używam usługi WCF, która, między innymi, jest używana jako back-end dla witryny sieci Web. Ponieważ zarówno strona internetowa, jak i usługa WCF działają na tym samym komputerze, i w interesie wydajności, ustawiłem go za pomocą netTcpBinding.Jaka jest najszybsza możliwa konfiguracja zabezpieczeń dla netTcpBinding?

W tej chwili, ponieważ istnieją one w tym samym pudełku, nie obchodzi mnie ani bezpieczeństwo na poziomie transportu, ani szyfrowanie na poziomie wiadomości; jedynym możliwym sposobem przechwycenia wiadomości jest, jeśli ktoś dostanie się do serwera sieciowego, a jeśli to zrobi, mam już większe problemy.

Moje pytanie brzmi: kiedy klient i serwer są już w zaufanym podsystemie, jakiej konfiguracji można użyć, aby zapewnić, że usługa netTcpBinding działa tak szybko, jak to możliwe?

Oczywiście odpowiedzią może być użycie zabezpieczenia "brak". Ale w moim przypadku nadal potrzebuję używać uwierzytelniania UserName przeciwko niestandardowej bazie danych. Czy można go skonfigurować tak, aby nadal korzystał z uwierzytelniania UserName, ale nie zawracał sobie głowy certyfikatami lub zabezpieczał dane między punktami końcowymi? Czy może powinienem zaimplementować niestandardowe zachowanie z niestandardowym nagłówkiem SOAP do przechowywania nazwy użytkownika/hasła, a następnie naprawdę mogę ustawić bezpieczeństwo na "none"?

Server Config

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

Używa uwierzytelniania nazwa_użytkownika niestandardowe - w zasadzie każde połączenie uwierzytelnia & zezwala na bazie niestandardowej. Bok serwis wykorzystuje również certyfikat do negocjacji z klientami, np

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

Odpowiedz

4

"None" będzie najszybciej, tak :-)

Na z drugiej strony, jeśli twoje usługi i zaplecze działają na tej samej maszynie, powinieneś również poważnie spojrzeć na powiązanie netNamedPipe, co jest absolutnym optymalnym, jeśli masz komunikację "na komputerze". Jest jeszcze szybszy i bardziej wydajny niż netTcp.

W celu uwierzytelnienia osoby dzwoniącej w związku z usługą, należy użyć pewnej metody zabezpieczeń - ponieważ netNamedPipe obsługuje tylko "brak" lub "Windows", wybrałbym system Windows. Jeśli nie używasz żadnego, nie masz możliwości identyfikacji (uwierzytelnienia) dzwoniącego, a zatem nie możesz mieć autoryzacji (kto może zrobić co) na podstawie tożsamości dzwoniącego.

Po uwierzytelnieniu osoby dzwoniącej (która do mnie dzwoni) można użyć grup systemu Windows lub wbudowanego podsystemu członkostwa/dostawcy roli ASP.NET do autoryzowania opartego na rolach, aby pewien, kto może robić, co robi. Można to skonfigurować za pomocą zachowania usługi o nazwie <serviceAuthoritzation> w sekcji zachowania konfiguracji usługi.

Marc

Powiązane problemy