Peer Channel Message Authentication

  • Article

Cet exemple montre l'utilisation de la liaison NetPeerTcpBinding avec l'authentification basée sur les messages, qui fournit la communication pluripartite à l'aide du canal homologue. Cet exemple est une variante de Getting Started, exemple. Pour une vue d'ensemble de Windows Communication Foundation (WCF), consultez Getting Started, exemple.

Dans cet exemple, les instances d'application sont des applications console auto-hébergées.

Contrairement à d'autres exemples de liaison de transport, cet exemple utilise l'interface de contrat IQuoteChange à des fins d'illustration de la communication pluripartite. Toutes les instances implémentent ce contrat pour recevoir des messages et créer des proxys du même contrat afin d'envoyer des messages à la maille. Cela est illustré en créant un canal duplex vers la maille.

Aa967730.note(fr-fr,VS.90).gifRemarque :
La procédure d'installation ainsi que les instructions de génération relatives à cet exemple figurent à la fin de cette rubrique.

Le fonctionnement du processus de configuration de liaison dans l'exemple implique les concepts de canal homologue suivants :

  • Le programme de résolution d'homologue est chargé de résoudre un ID de maille aux adresses de point de terminaison de certains nœuds dans la maille.
  • Une maille est une collection nommée de nœuds homologues identifiée par l'ID de maille.
  • Un nœud homologue est une instance d'une application qui participe à la maille.
  • Les ID de maille identifient la partie hôte de l'adresse d'un point de terminaison dans la maille. Ces adresses sont par exemple net.p2p://chatMesh/servicemodelsamples/chat ou net.p2p://broadcastMesh/servicemodelsamples/announcements. chatMesh et broadcastMesh sont les ID de maille.
  • Tous les clients qui participent à une maille utilisent le même ID de maille, mais peuvent potentiellement utiliser des chemins d'accès et des services différents. Un message adressé à une adresse de point de terminaison spécifique est remis à tous les clients à l'aide de cette adresse.

Lorsqu'un nœud homologue est ouvert, il utilise un programme de résolution d'homologue pour résoudre l'ID de maille à une liste d'adresses d'autres nœuds homologues dans la maille. Les messages peuvent ainsi être propagés sur l'ensemble de la maille.

PeerTransportCredentialType spécifie la manière dont les homologues dans la maille sont authentifiés les uns par rapport aux autres. Cette propriété peut être spécifiée dans la configuration de liaison, dans un objet NetPeerTcpBinding ou en utilisant un élément de liaison PeerTransportBindingElement. Une instance ClientCredentialSettings (ou ServiceCredentialSettings) avec les informations d'identification appropriées spécifiées sur la propriété Peer doit être ajoutée à la collection de comportements sur la fabrication de canal ou l'hôte de service selon l'utilisation.

Le canal homologue prend en charge les modes d'authentification suivants dans la classe PeerTransportCredentialType :

  1. Password. Il s'agit du mode d'authentification par défaut pour le canal homologue. Dans ce mode, tous les participants à la maille sont supposés prouver qu'ils connaissent un mot de passe secret. Cela s'effectue en établissant une connexion sécurisée entre des voisins et en échangeant une transformation de ce mot de passe. Lorsque Password est spécifié, la propriété ClientCredentialSettings.Peer doit contenir un mot de passe valide et éventuellement une instance X509Certificate2 (à l'aide de SetSelfCertificate).
  2. Certificate. Dans ce mode, l'authentification spécifique à l'application est effectuée lors de l'établissement de connexions homologue. Lorsque ce mode est spécifié, les applications doivent spécifier une implémentation concrète de X509Certificate2Validator dans ClientCredentialSettings.Peer.PeerAuthentication ajouté à la fabrication de canal.

Les applications peuvent signer des messages sortants et valider des messages entrants lorsque la propriété NetPeerTcpBinding.Security.Mode a la valeur SecurityMode.Message ou SecurityMode.TransportWithMessageCredential.

La signature des messages sortants utilise une instance de X509Certificate2 spécifiée avec ClientCredentialSettings.Peer.SetSelfCertificate().

La signature de message est effectuée à l'aide d'une instance de X509Certificate2. Pour la signature des messages sortants (en cas de OutputChannel de DuplexChannel), l'application doit spécifier les informations d'identification à utiliser pour signer à l'aide de PeerCredential.SetSelfCertificate()..

Pour la vérification des messages entrants (InputChannel ou DuplexChannel), les applications doivent spécifier une implémentation concrète de X509Certificate2Validator qui valide la source des messages et est spécifié à l'aide de ServiceCredentialSettings.Peer.MessageSenderAuthentication().

La liaison est spécifiée dans les fichiers de configuration de l'expéditeur et des récepteurs. Le type de liaison est spécifié dans l'attribut binding de l'élément endpoint, tel qu'indiqué dans l'exemple suivant.

<services>
    <service name="Microsoft.ServiceModel.Samples.BroadcastReceiver">
        <!-- use base address provided by the host -->
        <endpoint address="Stocks"
            binding="netPeerTcpBinding"
            bindingConfiguration="Binding1" 
            contract="Microsoft.ServiceModel.Samples.IQuoteChange" />
    </service>
</services>

Si vous utilisez la liaison NetPeerTcpBinding avec le comportement par défaut, la sécurité par mot de passe est activée. L'élément binding fournit des attributs permettant de définir le port, l'adresse IP d'écoute, le type de programme de résolution, la taille maximale de message, la taille maximale de pool de mémoires tampons, les quotas de lecteurs, le mode d'authentification de nœud homologue, l'authentification de message et les délais d'attente (pour la fermeture, l'ouverture, l'envoi et la réception).

Aa967730.note(fr-fr,VS.90).gifRemarque :
Cet exemple utilise le programme de résolution d'homologue (PNRP) par défaut, qui n'est pas disponible dans WCF. Par conséquent, pour exécuter cet exemple sur WCF, vous devez utiliser un programme de résolution d'homologue personnalisé. Pour un exemple qui utilise un programme de résolution d'homologue personnalisé, consultez Peer Channel Chat. 

<netPeerTcpBinding>
    <binding configurationName="Binding1"> 
        <resolver mode="Custom">
            <customResolver type=
                  "MyAppNameSpace.MyCustomPeerResolver, myApp"/>
        </resolver>
    </binding>
</netPeerTcpBinding>

Le fichier qui contient MyCustomPeerResolver doit être compilé avec l'expéditeur et les récepteurs. Notez que si l'exemple est exécuté sur plusieurs ordinateurs avec différentes plateformes, ils doivent tous utiliser le même programme de résolution.

Les implémentations de récepteur et d'expéditeur montrent également comment récupérer le nœud homologue associé à l'instance de récepteur ou d'expéditeur et comment s'inscrire aux événements en ligne et hors ligne. Un événement en ligne est initialisé lorsque le nœud homologue est connecté à au moins un autre nœud homologue dans la maille. Un événement hors connexion est initialisé lorsqu'un nœud homologue n'est plus connecté à aucun autre nœud homologue dans la maille.

À ce stade, le canal homologue ne s'intègre pas avec Service Model Metadata Utility Tool (Svcutil.exe). Pour cette raison, Svcutil.exe ne peut pas être utilisé pour générer un canal typé pour l'expéditeur.

Lorsque vous exécutez l'exemple, l'expéditeur affiche un message indiquant qu'il est prêt à envoyer des messages. Entrez les valeurs suivies par ENTER pour envoyer la valeur stock actuelle aux clients de récepteur. Les mises à jour s'affichent dans les autres fenêtres de console clientes. Pour arrêter le client, entrez une valeur vide dans les fenêtres de console de l'expéditeur (ou appuyez sur ENTER pour un client de récepteur).

Si vous activez le suivi ou l'enregistrement des messages, vous pouvez surveiller l'activité de l'expéditeur et du récepteur de manière plus approfondie. La procédure suivante décrit comment activer le suivi et l'enregistrement des messages.

Aa967730.note(fr-fr,VS.90).gifRemarque :
Il est important de noter que l'exemple ne gère pas actuellement toutes les exceptions possibles que l'infrastructure peut lever. Si vous utilisez ces exemples dans un environnement commercial ou de production, conformez-vous aux meilleures pratiques de gestion des exceptions.

Pour configurer, générer et exécuter l'exemple

  1. Assurez-vous d'avoir effectué la procédure indiquée dans la section Procédure d'installation unique pour les exemples Windows Communication Foundation.

  2. Pour générer l'édition C# ou Visual Basic .NET de la solution, suivez les instructions indiquées dans Génération des exemples Windows Communication Foundation.

  3. Pour exécuter l'exemple dans une configuration à un seul ordinateur, suivez les instructions indiquées dans Exécution des exemples Windows Communication Foundation.

  4. Pour installer PNRP sur Windows XP SP2 (installation unique) :

    1. Dans le Panneau de configuration, double-cliquez sur Ajout/Suppression de programmes.
    2. Dans la boîte de dialogue Ajouter ou supprimer des programmes, cliquez sur Ajouter ou supprimer des composants Windows.
    3. Dans l'Assistant composants de Windows, activez la case à cocher Services de mise en réseau, puis cliquez sur Détails.
    4. Activez la case à cocher Homologue à homologue et cliquez sur OK.
    5. Dans l'Assistant composants de Windows, cliquez sur Suivant.
    6. Lorsque l'installation est terminée, cliquez sur Terminer.
    7. Dans une invite de commandes shell, démarrez le service PNRP à l'aide de la commande suivante : net start pnrpsvc.

  5. Chaque fois que l'étape 3 fait référence au client et au service, ces étapes s'appliquent à l'expéditeur et au récepteur.

  6. Si vous exécutez cet exemple pour la première fois, exécutez Setup.bat pour créer et enregistrer les certificats utilisés par l'exemple. Si vous utilisez l'exemple sur plusieurs ordinateurs, exécutez Setup.bat sur un seul ordinateur uniquement et exportez le certificat généré vers tous les autres ordinateurs utilisés. Cela est dû au fait que Setup.bat crée un certificat aléatoire, et donc différentes exécutions de Setup.bat génèrent et enregistrent un certificat unique.

  7. Démarrez le ou les récepteurs et l'expéditeur. Lorsque les instances se connectent, entrez des valeurs dans la console de l'application expéditrice afin d'envoyer des mises à jour au(x) récepteur(s). Les messages de conversation envoyés par l'expéditeur sont reçus par tous les récepteurs.

  8. Exécutez Cleanup.bat pour supprimer les certificats créés par cet exemple.

Send comments about this topic to Microsoft.
© 2007 Microsoft Corporation. All rights reserved.