Udostępnij za pomocą

Niestandardowy zabezpieczony punkt końcowy metadanych

W przykładzie CustomMexEndpoint pokazano, jak zaimplementować usługę z bezpiecznym punktem końcowym metadanych, który używa jednego z powiązań wymiany nienależących do metadanych oraz jak skonfigurować narzędzie ServiceModel Metadata Tool (Svcutil.exe) lub klientów w celu pobrania metadanych z takiego punktu końcowego metadanych. Dostępne są dwa powiązania dostarczone przez system na potrzeby uwidaczniania punktów końcowych metadanych: mexHttpBinding i mexHttpsBinding. mexHttpBinding służy do uwidaczniania punktu końcowego metadanych za pośrednictwem protokołu HTTP w sposób niezabezpieczony. mexHttpsBinding służy do uwidaczniania punktu końcowego metadanych za pośrednictwem protokołu HTTPS w bezpieczny sposób. W tym przykładzie pokazano, jak uwidocznić bezpieczny punkt końcowy metadanych przy użyciu elementu WSHttpBinding. Należy to zrobić, gdy chcesz zmienić ustawienia zabezpieczeń w powiązaniu, ale nie chcesz używać protokołu HTTPS. Jeśli używasz elementu mexHttpsBinding, punkt końcowy metadanych będzie bezpieczny, ale nie ma możliwości modyfikowania ustawień powiązania.

Uwaga / Notatka

Procedura instalacji i instrukcje kompilacji dla tego przykładu znajdują się na końcu tego tematu.

Usługa

Usługa w tym przykładzie ma dwa punkty końcowe. Punkt końcowy aplikacji obsługuje kontrakt ICalculator na WSHttpBinding z włączoną obsługą ReliableSession oraz zabezpieczeniami Message przy użyciu certyfikatów. Punkt końcowy metadanych używa również WSHttpBinding z tymi samymi ustawieniami zabezpieczeń, ale bez elementu ReliableSession. Oto odpowiednia konfiguracja:

<services>
    <service name="Microsoft.ServiceModel.Samples.CalculatorService"
             behaviorConfiguration="CalculatorServiceBehavior">
     <!-- use base address provided by host -->
     <endpoint address=""
       binding="wsHttpBinding"
       bindingConfiguration="Binding2"
       contract="Microsoft.ServiceModel.Samples.ICalculator" />
     <endpoint address="mex"
       binding="wsHttpBinding"
       bindingConfiguration="Binding1"
       contract="IMetadataExchange" />
     </service>
 </services>
 <bindings>
   <wsHttpBinding>
     <binding name="Binding1">
       <security mode="Message">
         <message clientCredentialType="Certificate" />
       </security>
     </binding>
     <binding name="Binding2">
       <reliableSession inactivityTimeout="00:01:00" enabled="true" />
       <security mode="Message">
         <message clientCredentialType="Certificate" />
       </security>
     </binding>
   </wsHttpBinding>
 </bindings>

W wielu innych przykładach punkt końcowy metadanych używa wartości domyślnej mexHttpBinding, która nie jest bezpieczna. W tym miejscu metadane są zabezpieczone przy użyciu WSHttpBinding z zabezpieczeniem Message. Aby klienci metadanych mogli pobierać te metadane, muszą być skonfigurowani z pasującym powiązaniem. W tym przykładzie pokazano dwóch takich klientów.

Pierwszy klient używa Svcutil.exe do pobierania metadanych i generowania kodu klienta i konfiguracji w czasie projektowania. Ponieważ usługa używa powiązania innego niż domyślne dla metadanych, narzędzie Svcutil.exe musi być specjalnie skonfigurowane, aby można było pobrać metadane z usługi przy użyciu tego powiązania.

Drugi klient używa elementu MetadataResolver , aby dynamicznie pobierać metadane dla znanego kontraktu, a następnie wywoływać operacje na dynamicznie generowanym kliencie.

Klient Svcutil

Jeśli używasz domyślnego powiązania do hostowania IMetadataExchange punktu końcowego, możesz uruchomić Svcutil.exe z adresem tego punktu końcowego:

svcutil http://localhost/servicemodelsamples/service.svc/mex

i to działa. Jednak w tej próbce serwer używa niestandardowego punktu końcowego do hostowania metadanych. Dlatego Svcutil.exe należy poinstruować, aby użył poprawnego połączenia. Można to zrobić przy użyciu pliku Svcutil.exe.config.

Plik Svcutil.exe.config wygląda jak normalny plik konfiguracji klienta. Jedynymi nietypowymi aspektami są nazwa i kontrakt punktu końcowego klienta:

<endpoint name="http"
          binding="wsHttpBinding"
          bindingConfiguration="Binding1"
          behaviorConfiguration="ClientCertificateBehavior"
          contract="IMetadataExchange" />

Nazwa punktu końcowego musi być nazwą schematu adresu, w którym są hostowane metadane, a kontrakt punktu końcowego musi mieć wartość IMetadataExchange. W związku z tym, gdy Svcutil.exe jest uruchamiany za pomocą polecenia w wierszu polecenia, takiego jak poniżej:

svcutil http://localhost/servicemodelsamples/service.svc/mex

Szuka punktu końcowego o nazwie "http" i kontraktu IMetadataExchange , aby skonfigurować powiązanie i zachowanie wymiany komunikacji z punktem końcowym metadanych. Pozostała część pliku Svcutil.exe.config w przykładzie określa konfigurację i parametry zachowania połączenia, aby dopasować się do konfiguracji serwera punktu końcowego metadanych.

Aby Svcutil.exe pobrać konfigurację w Svcutil.exe.config, Svcutil.exe musi znajdować się w tym samym katalogu co plik konfiguracji. W związku z tym należy skopiować Svcutil.exe z lokalizacji instalacji do katalogu zawierającego plik Svcutil.exe.config. Następnie z tego katalogu uruchom następujące polecenie:

.\svcutil.exe http://localhost/servicemodelsamples/service.svc/mex

Wiodący plik ".\" gwarantuje, że zostanie uruchomiona kopia Svcutil.exe w tym katalogu (która ma odpowiedni Svcutil.exe.config).

Klient MetadataResolver

Jeśli klient zna kontrakt i jak komunikować się z metadanymi w czasie projektowania, klient może dynamicznie znaleźć powiązanie i adres punktów końcowych aplikacji przy użyciu elementu MetadataResolver. Ten przykładowy klient demonstruje to, pokazując, jak skonfigurować powiązanie i poświadczenia używane przez MetadataResolver poprzez utworzenie i skonfigurowanie MetadataExchangeClient.

Te same informacje o powiązaniu i certyfikacie, które zostały wyświetlone w Svcutil.exe.config, można określić imperatywnie w pliku MetadataExchangeClient:

// Specify the Metadata Exchange binding and its security mode
WSHttpBinding mexBinding = new WSHttpBinding(SecurityMode.Message);
mexBinding.Security.Message.ClientCredentialType = MessageCredentialType.Certificate;

// Create a MetadataExchangeClient for retrieving metadata, and set the // certificate details
MetadataExchangeClient mexClient = new MetadataExchangeClient(mexBinding);
mexClient.SoapCredentials.ClientCertificate.SetCertificate(    StoreLocation.CurrentUser, StoreName.My,
    X509FindType.FindBySubjectName, "client.com");
mexClient.SoapCredentials.ServiceCertificate.Authentication.CertificateValidationMode = X509CertificateValidationMode.PeerOrChainTrust;
mexClient.SoapCredentials.ServiceCertificate.SetDefaultCertificate(    StoreLocation.CurrentUser, StoreName.TrustedPeople,
    X509FindType.FindBySubjectName, "localhost");

Po skonfigurowaniu mexClient możemy wymienić kontrakty, które nas interesują, i użyć MetadataResolver do pobrania listy punktów końcowych z tymi kontraktami.

// The contract we want to fetch metadata for
Collection<ContractDescription> contracts = new Collection<ContractDescription>();
ContractDescription contract = ContractDescription.GetContract(typeof(ICalculator));
contracts.Add(contract);
// Find endpoints for that contract
EndpointAddress mexAddress = new EndpointAddress(ConfigurationManager.AppSettings["mexAddress"]);
ServiceEndpointCollection endpoints = MetadataResolver.Resolve(contracts, mexAddress, mexClient);

Na koniec możemy wykorzystać informacje z tych punktów końcowych, aby zainicjować wiązanie i adres ChannelFactory, który jest używany do tworzenia kanałów do komunikacji z punktami końcowymi aplikacji.

ChannelFactory<ICalculator> cf = new ChannelFactory<ICalculator>(endpoint.Binding, endpoint.Address);

Kluczowym celem tego przykładowego klienta jest zademonstrowanie, że jeśli korzystasz z `MetadataResolver` i musisz określić niestandardowe powiązania lub zachowania dla komunikacji wymiany metadanych, możesz użyć elementu `MetadataExchangeClient`, aby określić te niestandardowe ustawienia.

Aby skonfigurować i skompilować przykład

  1. Upewnij się, że wykonano procedurę instalacji One-Time dla przykładów programu Windows Communication Foundation.

  2. Aby skompilować rozwiązanie, postępuj zgodnie z instrukcjami w temacie Building the Windows Communication Foundation Samples (Tworzenie przykładów programu Windows Communication Foundation).

Aby uruchomić przykład na tej samej maszynie

  1. Uruchom Setup.bat z folderu instalacji przykładowej. To instaluje wszystkie certyfikaty wymagane do uruchomienia próbki. Należy pamiętać, że Setup.bat używa narzędzia FindPrivateKey.exe, które jest instalowane przez uruchomienie setupCertTool.bat z procedury instalacji programuOne-Time dla przykładów programu Windows Communication Foundation.

  2. Uruchom aplikację klienta z folderu \MetadataResolverClient\bin lub \SvcutilClient\bin. Działanie klienta jest wyświetlane w aplikacji konsolowej klienta.

  3. Jeśli klient i usługa nie mogą się komunikować, sprawdź sekcję „Wskazówki dotyczące rozwiązywania problemów z przykładami programu WCF”.

  4. Usuń certyfikaty, uruchamiając Cleanup.bat, gdy zakończysz pracę z próbką. Inne przykłady zabezpieczeń używają tych samych certyfikatów.

Aby uruchomić program próbny na różnych maszynach

  1. Na serwerze uruchom polecenie setup.bat service. Uruchomienie setup.bat z argumentem service powoduje utworzenie certyfikatu usługi z w pełni kwalifikowaną nazwą domeny maszyny i eksportuje certyfikat usługi do pliku o nazwie Service.cer.

  2. Na serwerze edytuj Web.config, aby odzwierciedlić nową nazwę certyfikatu. Oznacza to, że zmień findValue atrybut w elemencie <serviceCertificate> na w pełni kwalifikowaną nazwę domeny maszyny.

  3. Skopiuj plik Service.cer z katalogu usługi do katalogu klienta na komputerze klienckim.

  4. Na kliencie uruchom setup.bat client. Uruchomienie setup.bat z argumentem client powoduje utworzenie certyfikatu klienta o nazwie Client.com i wyeksportowanie certyfikatu klienta do pliku o nazwie Client.cer.

  5. W pliku MetadataResolverClient App.config na komputerze klienckim zmień wartość adresu punktu końcowego mex, aby był zgodny z nowym adresem usługi. Aby to zrobić, zastąp "localhost" w pełni kwalifikowaną nazwą domeny serwera. Zmień również wystąpienie "localhost" w pliku metadataResolverClient.cs na nową nazwę certyfikatu usługi (w pełni kwalifikowaną nazwę domeny serwera). Wykonaj to samo dla App.config projektu SvcutilClient.

  6. Skopiuj plik Client.cer z katalogu klienta do katalogu usługi na serwerze.

  7. Na kliencie uruchom ImportServiceCert.bat. Spowoduje to zaimportowanie certyfikatu usługi z pliku Service.cer do magazynu CurrentUser - TrustedPeople.

  8. Na serwerze uruchom polecenie ImportClientCert.bat. Spowoduje to zaimportowanie certyfikatu klienta z pliku Client.cer do magazynu LocalMachine — TrustedPeople.

  9. Na maszynie usługi skompiluj projekt usługi w programie Visual Studio i wybierz stronę pomocy w przeglądarce internetowej, aby sprawdzić, czy jest uruchomiona.

  10. Na komputerze klienckim uruchom element MetadataResolverClient lub SvcutilClient z programu VS.

    1. Jeśli klient i usługa nie mogą się komunikować, sprawdź sekcję „Wskazówki dotyczące rozwiązywania problemów z przykładami programu WCF”.

Aby posprzątać po próbie

  • Uruchom Cleanup.bat w folderze próbek po zakończeniu uruchamiania próbki.

    Uwaga / Notatka

    Ten skrypt nie usuwa certyfikatów usługi na kliencie podczas uruchamiania tego przykładu na maszynach. Jeśli uruchomiłeś przykłady programu Windows Communication Foundation (WCF), które korzystają z certyfikatów na wielu komputerach, pamiętaj, aby wyczyścić certyfikaty usługi zainstalowane w magazynie CurrentUser - TrustedPeople. W tym celu użyj następującego polecenia: certmgr -del -r CurrentUser -s TrustedPeople -c -n <Fully Qualified Server Machine Name>. Na przykład: certmgr -del -r CurrentUser -s TrustedPeople -c -n server1.contoso.com.

  • Last updated on