Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Cette section traite de la sécurité des messages WCF lors de l’utilisation NetMsmqBinding.
Remarque
Avant de lire cette rubrique, il est recommandé de lire les concepts de sécurité.
L’illustration suivante fournit un modèle conceptuel de communication mise en file d’attente à l’aide de WCF. Cette illustration et cette terminologie sont utilisées pour expliquer
concepts de sécurité du transport.
Lors de l’envoi de messages mis en file d’attente à l’aide de WCF, le message WCF est attaché en tant que corps du message Message Queuing (MSMQ). Bien que la sécurité du transport sécurise l’ensemble du message MSMQ, la sécurité du message (ou SOAP) sécurise uniquement le corps du message MSMQ.
Le concept clé de sécurité des messages est que le client sécurise le message pour l’application de réception (service), contrairement à la sécurité du transport où le client sécurise le message pour la file d’attente cible. Par conséquent, MSMQ ne joue aucun rôle lors de la sécurisation du message WCF à l’aide de la sécurité des messages.
La sécurité des messages WCF ajoute des en-têtes de sécurité au message WCF qui s’intègrent à des infrastructures de sécurité existantes, telles qu’un certificat ou le protocole Kerberos.
Type de crédential du message
À l’aide de la sécurité des messages, le service et le client peuvent présenter des informations d’identification pour s’authentifier mutuellement. Vous pouvez sélectionner la sécurité des messages en définissant le mode Security sur Message ou Both (c'est-à-dire, utilisez à la fois la sécurité du transport et la sécurité des messages).
Le service peut utiliser la Current propriété pour inspecter les informations d’identification utilisées pour authentifier le client. Cela peut également être utilisé pour des vérifications d’autorisation supplémentaires que le service choisit d’implémenter.
Cette section explique les différents types d’informations d’identification et comment les utiliser avec des files d’attente.
Certificat
Le type d’informations d’identification du certificat utilise un certificat X.509 pour identifier le service et le client.
Dans un scénario classique, le client et le service sont émis un certificat valide par une autorité de certification approuvée. Ensuite, la connexion est établie, le client authentifie la validité du service à l’aide du certificat du service pour décider s’il peut approuver le service. De même, le service utilise le certificat du client pour valider l’approbation du client.
Étant donné la nature déconnectée des files d’attente, le client et le service peuvent ne pas être en ligne en même temps. Par conséquent, le client et le service doivent échanger des certificats hors bande. En particulier, le client, du fait qu'il détient le certificat du service (lequel peut être chaîné à une autorité de certification) dans son magasin approuvé, doit croire qu'il communique avec le service correct. Pour authentifier le client, le service utilise le certificat X.509 attaché au message pour le faire correspondre au certificat dans son magasin pour vérifier l’authenticité du client. Là encore, le certificat doit être chaîné à une autorité de certification.
Sur un ordinateur exécutant Windows, les certificats sont conservés dans plusieurs types de magasins. Pour plus d’informations sur les différents magasins, consultez Magasins de certificats.
Fenêtres
Le type d’informations d’identification du message Windows utilise le protocole Kerberos.
Le protocole Kerberos est un mécanisme de sécurité qui authentifie les utilisateurs sur un domaine et permet aux utilisateurs authentifiés d’établir des contextes sécurisés avec d’autres entités sur un domaine.
Le problème lié à l'utilisation du protocole Kerberos pour la communication mise en file d'attente est que les tickets qui contiennent l'identité du client que le centre de distribution de clés distribue sont relativement éphémères. Une durée de vie est associée au ticket Kerberos qui indique la validité du ticket. Par conséquent, étant donné une latence élevée, vous ne pouvez pas vous assurer que le jeton est toujours valide pour le service qui authentifie le client.
Notez que lorsque vous utilisez ce type d’informations d’identification, le service doit s’exécuter sous le compte SERVICE.
Le protocole Kerberos est utilisé par défaut lors du choix des informations d’identification du message.
Nom d'utilisateur Mot de passe
À l’aide de cette propriété, le client peut s’authentifier auprès du serveur à l’aide d’un mot de passe de nom d’utilisateur dans l’en-tête de sécurité du message.
IssuedToken
Le client peut utiliser le service de jeton de sécurité pour émettre un jeton qui peut ensuite être attaché au message du service pour authentifier le client.
Utilisation du transport et de la sécurité des messages
Lors de l’utilisation de la sécurité du transport et de la sécurité des messages, le certificat utilisé pour sécuriser le message à la fois au niveau du transport et du message SOAP doit être identique.