Endpoint personalizzato dei metadati sicuri

L'esempio CustomMexEndpoint illustra come implementare un servizio con un endpoint di metadati sicuro che usa una delle associazioni di scambio di metadati non metadati e come configurare serviceModel Metadata Utility Tool (Svcutil.exe) o i client per recuperare i metadati da tale endpoint di metadati. Sono disponibili due associazioni fornite dal sistema per l'esposizione degli endpoint dei metadati: mexHttpBinding e mexHttpsBinding. mexHttpBinding viene usato per esporre un endpoint di metadati su HTTP in modo non sicuro. mexHttpsBinding viene usato per esporre un endpoint di metadati tramite HTTPS in modo sicuro. Questo esempio illustra come esporre un endpoint di metadati sicuro usando .WSHttpBinding È consigliabile eseguire questa operazione quando si desidera modificare le impostazioni di sicurezza nell'associazione, ma non si vuole usare HTTPS. Se si usa mexHttpsBinding l'endpoint dei metadati sarà sicuro, ma non è possibile modificare le impostazioni di associazione.

Annotazioni

La procedura di installazione e le istruzioni di compilazione per questo esempio si trovano alla fine di questo argomento.

Servizio

Il servizio in questo esempio ha due endpoint. L'endpoint dell'applicazione gestisce il ICalculator contratto su un WSHttpBinding con ReliableSession abilitato e la sicurezza Message utilizzando certificati. L'endpoint dei metadati usa WSHttpBindinganche , con le stesse impostazioni di sicurezza, ma senza ReliableSession. Ecco la configurazione pertinente:

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

In molti degli altri esempi, l'endpoint dei metadati usa il valore predefinito mexHttpBinding, che non è sicuro. In questo caso i metadati vengono protetti usando WSHttpBinding con Message sicurezza. Affinché i client di metadati recuperino questi metadati, devono essere configurati con un'associazione corrispondente. Questo esempio illustra due client di questo tipo.

Il primo client usa Svcutil.exe per recuperare i metadati e generare codice client e configurazione in fase di progettazione. Poiché il servizio usa un'associazione non predefinita per i metadati, lo strumento Svcutil.exe deve essere configurato in modo specifico in modo che possa ottenere i metadati dal servizio usando tale associazione.

Il secondo client usa il MetadataResolver per recuperare dinamicamente i metadati di un contratto noto e quindi invocare le operazioni sul client generato dinamicamente.

Client Svcutil

Quando si usa l'associazione predefinita per ospitare l'endpoint IMetadataExchange , è possibile eseguire Svcutil.exe con l'indirizzo dell'endpoint:

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

e funziona. In questo esempio, tuttavia, il server usa un endpoint non predefinito per ospitare i metadati. Pertanto, si deve istruire Svcutil.exe ad usare l'associazione corretta. Questa operazione può essere eseguita usando un file di Svcutil.exe.config.

Il file Svcutil.exe.config è simile a un normale file di configurazione client. Gli unici aspetti insoliti sono il nome e il contratto dell'endpoint client:

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

Il nome dell'endpoint deve essere il nome dello schema dell'indirizzo in cui sono ospitati i metadati e il contratto endpoint deve essere IMetadataExchange. Pertanto, quando Svcutil.exe viene eseguito con una riga di comando, ad esempio:

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

cerca l'endpoint denominato "http" e il contratto IMetadataExchange per configurare l'associazione e il comportamento dello scambio di comunicazioni con l'endpoint dei metadati. Il resto del file Svcutil.exe.config nell'esempio specifica le credenziali di configurazione e comportamento dell'associazione in modo che corrispondano alla configurazione del server dell'endpoint dei metadati.

Affinché Svcutil.exe possa prelevare la configurazione in Svcutil.exe.config, Svcutil.exe deve trovarsi nella stessa directory del file di configurazione. Di conseguenza, è necessario copiare Svcutil.exe dal relativo percorso di installazione alla directory contenente il file Svcutil.exe.config. Eseguire quindi il comando seguente da tale directory:

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

L'elemento ".\" iniziale garantisce che venga eseguita la copia di Svcutil.exe in questa directory (quella con un Svcutil.exe.configcorrispondente).

Client MetadataResolver

Se il client conosce il contratto e come comunicare con i metadati in fase di progettazione, il client può individuare dinamicamente l'associazione e l'indirizzo degli endpoint dell'applicazione usando MetadataResolver. Questo client di esempio dimostra questo, mostrando come configurare il binding e le credenziali utilizzati da MetadataResolver, creando e configurando un MetadataExchangeClient.

Le stesse informazioni di associazione e certificato visualizzate in Svcutil.exe.config possono essere specificate in modo imperativo in 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");

Dopo la mexClient configurazione, è possibile enumerare i contratti a cui si è interessati e usare MetadataResolver per recuperare un elenco di endpoint con tali contratti:

// 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);

Infine, è possibile usare le informazioni di tali endpoint per inizializzare l'associazione e l'indirizzo di un oggetto ChannelFactory, utilizzato per creare canali di comunicazione con gli endpoint dell'applicazione.

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

Il punto chiave di questo client di esempio consiste nel dimostrare che, se si usa MetadataResolver, ed è necessario specificare associazioni o comportamenti personalizzati per la comunicazione di scambio di metadati, è possibile usare per MetadataExchangeClient specificare tali impostazioni personalizzate.

Per configurare e compilare l'esempio

Assicurati di aver eseguito la procedura di installazione di One-Time per gli esempi di Windows Communication Foundation.
Per compilare la soluzione, seguire le istruzioni riportate in Compilazione degli esempi di Windows Communication Foundation.

Per eseguire l'esempio nello stesso computer

Eseguire Setup.bat dalla cartella di installazione di esempio. Vengono installati tutti i certificati necessari per l'esecuzione dell'esempio. Si noti che Setup.bat usa lo strumento FindPrivateKey.exe, installato eseguendo setupCertTool.bat da One-Time Procedura di installazione per gli esempi di Windows Communication Foundation.
Eseguire l'applicazione client da \MetadataResolverClient\bin o \SvcutilClient\bin. L'attività client viene visualizzata nell'applicazione console client.
Se il client e il servizio non sono in grado di comunicare, vedere Suggerimenti per la risoluzione dei problemi per gli esempi WCF.
Rimuovere i certificati eseguendo Cleanup.bat al termine dell'esempio. Altri esempi di sicurezza usano gli stessi certificati.

Per eseguire l'esempio tra computer

Nel server eseguire setup.bat service. L'esecuzione setup.bat con l'argomento service crea un certificato del servizio con il nome di dominio completo del computer ed esporta il certificato del servizio in un file denominato Service.cer.
Nel server modificare Web.config in modo da riflettere il nuovo nome del certificato. Ovvero, modificare l'attributo findValue nell'elemento <serviceCertificate> impostandolo sul nome di dominio completo del computer.
Copiare il file Service.cer dalla directory del servizio alla directory client nel computer client.
Nel client eseguire setup.bat client. L'esecuzione setup.bat con l'argomento client crea un certificato client denominato Client.com ed esporta il certificato client in un file denominato Client.cer.
Nel file App.config di MetadataResolverClient sul computer del client, aggiornare il valore dell'indirizzo dell'endpoint mex in modo che corrisponda al nuovo indirizzo del servizio. Per fare ciò, sostituire localhost con il nome di dominio completo del server. Modificare anche l'occorrenza di "localhost" nel file metadataResolverClient.cs con il nuovo nome del certificato del servizio (il nome di dominio completo del server). Eseguire la stessa operazione per il App.config del progetto SvcutilClient.
Copiare il file Client.cer dalla directory client alla directory del servizio nel server.
Nel client eseguire ImportServiceCert.bat. Questo importa il certificato del servizio dal file Service.cer nell'archivio CurrentUser - TrustedPeople.
Nel server eseguire ImportClientCert.bat, importa il certificato client dal file Client.cer nell'archivio LocalMachine - TrustedPeople.
Sul computer di servizio, compila il progetto di servizio in Visual Studio e seleziona la pagina di aiuto in un browser web per verificare che sia in esecuzione.
Nel computer client eseguire MetadataResolverClient o SvcutilClient da Visual Studio.
1. Se il client e il servizio non sono in grado di comunicare, vedere Suggerimenti per la risoluzione dei problemi per gli esempi WCF.

Per eseguire la pulizia dopo l'esempio

Eseguire Cleanup.bat nella cartella samples dopo aver completato l'esecuzione dell'esempio.

Annotazioni

Questo script non rimuove i certificati del servizio in un client durante l'esecuzione di questo esempio tra computer. Se hai eseguito esempi di Windows Communication Foundation (WCF) che utilizzano certificati tra diverse macchine, assicurati di cancellare i certificati di servizio installati nell'archivio CurrentUser - TrustedPeople. A tale scopo, usare il comando seguente: certmgr -del -r CurrentUser -s TrustedPeople -c -n <Fully Qualified Server Machine Name>. Ad esempio: certmgr -del -r CurrentUser -s TrustedPeople -c -n server1.contoso.com.

Last updated on 2025-06-17

Condividi tramite