2009-08-23 23 views
6

Tôi đang chạy một dịch vụ WCF, trong số những thứ khác, được sử dụng làm đầu cuối cho một trang web. Bởi vì cả trang web và dịch vụ WCF đang chạy trên cùng một máy, và vì lợi ích của hiệu suất, tôi thiết lập nó với một netTcpBinding.Cấu hình bảo mật có thể nhanh nhất cho netTcpBinding là gì?

Hiện tại, bởi vì chúng tồn tại trên cùng một hộp, tôi thực sự không quan tâm đến bảo mật cấp độ vận chuyển hoặc mã hóa cấp tin nhắn; cách duy nhất có thể các tin nhắn có thể bị chặn là nếu ai đó vào máy chủ web, và nếu họ làm điều đó tôi đã có vấn đề lớn hơn rồi. Vì vậy, câu hỏi của tôi là: khi khách hàng và máy chủ đã có trên một hệ thống phụ đáng tin cậy, cấu hình nào có thể được sử dụng để đảm bảo netTcpBinding càng nhanh càng tốt?

Tất nhiên, câu trả lời có thể là sử dụng bảo mật "không". Nhưng trong trường hợp cụ thể của tôi, tôi vẫn cần sử dụng xác thực UserName dựa vào cơ sở dữ liệu tùy chỉnh. Nó có thể được cấu hình để nó vẫn sử dụng xác thực UserName, nhưng không bận tâm với chứng chỉ hoặc bảo mật dữ liệu giữa các thiết bị đầu cuối? Hoặc tôi có lẽ cần phải thực hiện một hành vi tùy chỉnh với một tiêu đề SOAP tùy chỉnh để lưu trữ tên người dùng/mật khẩu, và sau đó tôi thực sự có thể thiết lập bảo mật để "không"?

server Config

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

Nó sử dụng xác thực UserName tùy chỉnh - về cơ bản tất cả các cuộc gọi xác nhận & cho phép chống lại một cơ sở dữ liệu tùy chỉnh. Phía dịch vụ cũng sử dụng chứng chỉ để đàm phán với khách hàng, ví dụ:

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

Khách hàng 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> 

Trả lời

4

"Không" sẽ là nhanh nhất, vâng :-)

Trên Mặt khác, nếu dịch vụ của bạn và backend đang chạy trên cùng một máy, bạn cũng nên có một cái nhìn nghiêm trọng về ràng buộc netNamedPipe, đó là tối ưu tuyệt đối nếu bạn có "trên máy" thông tin liên lạc. Nó thậm chí còn nhanh hơn và hiệu quả hơn netTcp.

Để xác thực người gọi đối với dịch vụ, bạn cần sử dụng một số phương thức bảo mật - vì netNamedPipe chỉ hỗ trợ "không" hoặc "Windows", tôi chọn Windows. Nếu bạn không sử dụng, bạn không có cách nào để xác định (xác thực) người gọi, và do đó, bạn không thể có ủy quyền (ai có thể làm gì) dựa trên danh tính của người gọi.

Khi bạn đã xác thực người gọi (người đang gọi cho tôi), bạn có thể sử dụng nhóm Windows hoặc hệ thống con thành viên/vai trò cung cấp dịch vụ thành viên ASP.NET để thực hiện ủy quyền dựa trên vai trò, để thực hiện chắc chắn ai có thể làm những gì hoạt động. Điều này có thể được cấu hình bằng cách sử dụng một hành vi dịch vụ được gọi là <serviceAuthoritzation> trong phần hành vi của bạn trong cấu hình của dịch vụ.

Marc

Các vấn đề liên quan