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.
Microsoft s’engage à protéger la confidentialité des utilisateurs finaux. Lorsque vous générez une application à l’aide de Windows Communication Foundation (WCF), version 3.0, votre application peut avoir un impact sur la confidentialité de vos utilisateurs finaux. Par exemple, votre application peut collecter explicitement les informations de contact de l’utilisateur, ou demander ou envoyer des informations sur Internet à votre site web. Si vous incorporez la technologie Microsoft dans votre application, cette technologie peut avoir son propre comportement susceptible d’affecter la confidentialité. WCF n’envoie aucune information à Microsoft à partir de votre application, sauf si vous ou l’utilisateur final choisissez de l’envoyer à nous.
WCF en bref
WCF est une infrastructure de messagerie distribuée à l’aide de Microsoft .NET Framework qui permet aux développeurs de créer des applications distribuées. Les messages communiqués entre deux applications contiennent des informations d’en-tête et de corps.
Les en-têtes peuvent contenir le routage des messages, les informations de sécurité, les transactions, etc. en fonction des services utilisés par l’application. Les messages sont généralement chiffrés par défaut. L’une des exceptions est l’utilisation du BasicHttpBinding, qui a été conçu pour une utilisation avec des services Web non sécurisés et hérités. En tant que concepteur d’applications, vous êtes responsable de la conception finale. Les messages du corps SOAP contiennent des données spécifiques à l’application ; Toutefois, ces données, telles que les informations personnelles définies par l’application, peuvent être sécurisées à l’aide de fonctionnalités de chiffrement WCF ou de confidentialité. Les sections suivantes décrivent les fonctionnalités qui peuvent avoir un impact sur la confidentialité.
Messagerie
Chaque message WCF a un en-tête d’adresse qui spécifie la destination du message et où la réponse doit aller.
Le composant d’adresse d’une adresse de point de terminaison est un URI (Uniform Resource Identifier) qui identifie le point de terminaison. L’adresse peut être une adresse réseau ou une adresse logique. L’adresse peut inclure le nom de l’ordinateur (nom d’hôte, nom de domaine complet) et une adresse IP. L’adresse de point de terminaison peut également contenir un identificateur global unique (GUID) ou une collection de GUID pour l’adressage temporaire utilisé pour discerner chaque adresse. Chaque message contient un ID de message qui est un GUID. Cette fonctionnalité suit la norme de référence WS-Addressing.
La couche de messagerie WCF n’écrit aucune information personnelle sur l’ordinateur local. Toutefois, il peut propager des informations personnelles au niveau du réseau si un développeur de services a créé un service qui expose ces informations (par exemple, en utilisant le nom d’une personne dans un nom de point de terminaison, ou en incluant des informations personnelles dans le langage de description des services web du point de terminaison, mais qui n’oblige pas les clients à utiliser https pour accéder au WSDL). En outre, si un développeur exécute l’outil Utilitaire de métadonnées ServiceModel (Svcutil.exe) sur un point de terminaison qui expose des informations personnelles, la sortie de l’outil peut contenir ces informations et le fichier de sortie est écrit sur le disque dur local.
Hébergement
La fonctionnalité d’hébergement dans WCF permet aux applications de démarrer à la demande ou d’activer le partage de ports entre plusieurs applications. Une application WCF peut être hébergée dans Internet Information Services (IIS), similaire à ASP.NET.
L’hébergement n’expose pas d’informations spécifiques sur le réseau et ne conserve pas les données sur l’ordinateur.
Sécurité des messages
La sécurité WCF fournit les fonctionnalités de sécurité pour les applications de messagerie. Les fonctions de sécurité fournies incluent l’authentification et l’autorisation.
L’authentification est effectuée en passant des informations d’identification entre les clients et les services. L’authentification peut être via la sécurité au niveau du transport ou via la sécurité au niveau des messages SOAP, comme suit :
Dans la sécurité des messages SOAP, l’authentification est effectuée via des informations d’identification telles que le nom d’utilisateur/mot de passe, les certificats X.509, les tickets Kerberos et les jetons SAML, qui peuvent tous contenir des informations personnelles, en fonction de l’émetteur.
À l’aide de la sécurité du transport, l’authentification est effectuée via des mécanismes d’authentification de transport traditionnels comme les schémas d’authentification HTTP (De base, Digest, Negotiate, Integrated Windows Authorization, NTLM, None et Anonymous) et l’authentification par formulaire.
L’authentification peut entraîner une session sécurisée établie entre les points de terminaison de communication. La session est identifiée par un GUID qui reste valide pendant toute la durée de vie de la session de sécurité. Le tableau suivant montre ce qui est conservé et où.
| Données | Stockage |
|---|---|
| Informations d’identification de présentation, telles que le nom d’utilisateur, les certificats X.509, les jetons Kerberos et les références aux informations d’identification. | Mécanismes de gestion des informations d’identification Windows standard, tels que le magasin de certificats Windows. |
| Informations d’appartenance des utilisateurs, telles que les noms d’utilisateur et les mots de passe. | fournisseurs d'adhésion ASP.NET |
| Informations d’identité sur le service utilisé pour authentifier le service auprès des clients. | Adresse du point de terminaison du service. |
| Informations de l’appelant. | Journaux d’audit. |
Processus d'audit
L’audit enregistre la réussite et l’échec des événements d’authentification et d’autorisation. Les enregistrements d’audit contiennent les données suivantes : URI de service, URI d’action et identification de l’appelant.
L’audit enregistre également lorsque l’administrateur modifie la configuration de la journalisation des messages (l’activation ou la désactivation), car la journalisation des messages peut consigner des données spécifiques à l’application dans les en-têtes et les corps. Pour Windows XP, un enregistrement est enregistré dans le journal des événements de l’application. Pour Windows Vista et Windows Server 2003, un enregistrement est enregistré dans le journal des événements de sécurité.
Opérations
La fonctionnalité de transactions fournit des services transactionnels à une application WCF.
Les en-têtes de transaction utilisés dans la propagation des transactions peuvent contenir des ID de transaction ou des ID d’inscription, qui sont des GUID.
La fonctionnalité Transactions utilise microsoft Distributed Transaction Coordinator (MSDTC) Transaction Manager (un composant Windows) pour gérer l’état des transactions. Par défaut, les communications entre les gestionnaires de transactions sont chiffrées. Les gestionnaires de transactions peuvent enregistrer des références à des points de terminaison, des ID de transaction et des ID d'inscription dans le cadre de leur état durable. La durée de vie de cet état est déterminée par la durée de vie du fichier journal du Gestionnaire de transactions. Le service MSDTC détient la propriété et assure la maintenance de ce journal.
La fonctionnalité Transactions implémente les normes transactionnelles WS-Coordination et WS-Atomic.
Sessions fiables
Les sessions fiables dans WCF fournissent le transfert de messages lorsque des défaillances de transport ou d’intermédiaire se produisent. Ils fournissent un transfert exactement une fois des messages, même lorsque le transport sous-jacent se déconnecte (par exemple, une connexion TCP sur un réseau sans fil) ou perd un message (un proxy HTTP supprimant un message sortant ou entrant). Les sessions fiables récupèrent également la réorganisation des messages (comme cela peut se produire dans le cas d’un routage multipath), en conservant l’ordre dans lequel les messages ont été envoyés.
Les sessions fiables sont implémentées à l’aide du protocole WS-ReliableMessaging (WS-RM). Ils ajoutent des en-têtes WS-RM qui contiennent des informations de session, utilisée pour identifier tous les messages associés à une session fiable particulière. Chaque session WS-RM a un identificateur, qui est un GUID.
Aucune information personnelle n’est conservée sur l’ordinateur de l’utilisateur final.
Canaux mis en file d’attente
Les files d’attente stockent les messages d’une application d’envoi pour le compte d’une application de réception et transfèrent ultérieurement ces messages à l’application de réception. Ils permettent de garantir le transfert de messages de l’envoi d’applications à la réception d’applications lorsque, par exemple, l’application de réception est temporaire. WCF prend en charge la mise en file d’attente à l’aide de Microsoft Message Queuing (MSMQ) comme transport.
La fonctionnalité canaux mis en file d’attente n’ajoute pas d’en-têtes à un message. Au lieu de cela, il crée un message Message Queuing avec les propriétés de message Message Queuing appropriées définies et appelle les méthodes Message Queuing pour placer le message dans la file d’attente Message Queuing. Message Queuing est un composant facultatif fourni avec Windows.
Aucune information n’est conservée sur l’ordinateur de l’utilisateur final par la fonctionnalité canaux mis en file d’attente, car elle utilise Message Queuing comme infrastructure de mise en file d’attente.
Intégration COM+
Cette fonctionnalité encapsule les fonctionnalités COM et COM+ existantes pour créer des services compatibles avec les services WCF. Cette fonctionnalité n’utilise pas d’en-têtes spécifiques et ne conserve pas les données sur l’ordinateur de l’utilisateur final.
Moniker de service COM
Cela fournit un wrapper non managé à un client WCF standard. Cette fonctionnalité n’a pas d’en-têtes spécifiques sur le réseau et ne conserve pas les données sur l’ordinateur.
Canal homologue
Un canal homologue permet le développement d’applications multiparty à l’aide de WCF. La messagerie pluripartite se produit dans le contexte d'une maille. Les maillages sont identifiés par un nom que les nœuds peuvent joindre. Chaque nœud du canal homologue crée un écouteur TCP sur un port spécifié par l’utilisateur et établit des connexions avec d’autres nœuds du maillage pour garantir la résilience. Pour vous connecter à d’autres nœuds dans le maillage, les nœuds échangent également des données, notamment l’adresse de l’écouteur et les adresses IP de l’ordinateur, avec d’autres nœuds dans le maillage. Les messages envoyés dans le maillage peuvent contenir des informations de sécurité relatives à l’expéditeur pour empêcher l’usurpation et la falsification des messages.
Aucune information personnelle n’est stockée sur l’ordinateur de l’utilisateur final.
Expérience professionnelle informatique
Traçage
La fonctionnalité de diagnostic de l’infrastructure WCF consigne les messages qui passent par les couches de transport et de modèle de service, ainsi que les activités et les événements associés à ces messages. Cette fonctionnalité est désactivée par défaut. Elle est activée à l’aide du fichier de configuration de l’application et le comportement de suivi peut être modifié à l’aide du fournisseur WMI WCF au moment de l’exécution. Quand elle est activée, l’infrastructure de suivi émet une trace de diagnostic qui contient des messages, des activités et des événements de traitement pour les écouteurs configurés. Le format et l’emplacement de la sortie sont déterminés par les choix de configuration de l’écouteur de l’administrateur, mais il s’agit généralement d’un fichier au format XML. L’administrateur est chargé de définir la liste de contrôle d’accès (ACL) sur les fichiers de trace. En particulier, lorsqu’il est hébergé par le système d’activation Windows (WAS), l’administrateur doit s’assurer que les fichiers ne sont pas servis à partir du répertoire racine virtuel public si ce n’est pas souhaité.
Il existe deux types de suivi : journalisation des messages et suivi de diagnostic du modèle de service, décrits dans la section suivante. Chaque type est configuré via sa propre source de trace : MessageLogging et System.ServiceModel. Ces deux sources de trace de journalisation capturent les données locales de l’application.
Journalisation des messages
La source de trace de journalisation des messages (MessageLogging) permet à un administrateur de consigner les messages qui transitent par le système. Par le biais de la configuration, l’utilisateur peut décider de consigner des messages entiers ou des en-têtes de message uniquement, s’il faut se connecter aux couches de modèle de transport et/ou de service, et s’il faut inclure des messages mal formés. En outre, l’utilisateur peut configurer le filtrage pour restreindre les messages enregistrés.
Par défaut, la journalisation des messages est désactivée. L’administrateur de l’ordinateur local peut empêcher l’administrateur au niveau de l’application d’activer la journalisation des messages.
Journalisation des messages chiffrés et déchiffrés
Les messages sont enregistrés, chiffrés ou déchiffrés, comme décrit dans les termes suivants.
Journalisation des transports : messages échangés au niveau du transport. Ces messages contiennent tous les en-têtes et peuvent être chiffrés avant d’être envoyés sur le câble et lors de la réception.
Si les messages sont chiffrés avant d’être envoyés sur le réseau et lorsqu’ils sont reçus, ils sont également enregistrés chiffrés. Une exception est lorsqu’un protocole de sécurité est utilisé (https) : ils sont ensuite enregistrés déchiffrés avant d’être envoyés et après avoir été reçus, même s’ils sont chiffrés sur le câble.
Enregistrement de service Enregistre les messages reçus ou envoyés au niveau du modèle de service, après que le traitement d'en-tête de canal a eu lieu, juste avant et après l'entrée du code utilisateur.
Les messages enregistrés à ce niveau sont déchiffrés même s’ils ont été sécurisés et chiffrés sur le câble.
La journalisation des messages mal formés enregistre les messages que l'infrastructure WCF ne peut pas comprendre ou traiter.
Les messages sont enregistrés as-is, c’est-à-dire chiffrés ou non
Lorsque les messages sont consignés dans un formulaire déchiffré ou non chiffré, par défaut, WCF supprime les clés de sécurité et les informations potentiellement personnelles des messages avant de les journaliser. Les sections suivantes décrivent quelles informations sont supprimées et quand. L’administrateur de l’ordinateur et le déployeur d’applications doivent effectuer certaines actions de configuration pour modifier le comportement par défaut pour consigner les clés et les informations potentiellement personnelles.
Informations supprimées des en-têtes de message lors de la journalisation des messages déchiffrés/non chiffrés
Lorsque les messages sont enregistrés dans un formulaire déchiffré ou non chiffré, les clés de sécurité et les informations potentiellement personnelles sont supprimées par défaut des en-têtes de message et des corps des messages avant qu’ils ne soient enregistrés. La liste suivante montre ce que WCF considère comme des clés et des données potentiellement personnelles.
Clés supprimées :
Pour
xmlns:wst="http://schemas.xmlsoap.org/ws/2004/04/trust"etxmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust"wst:BinarySecretwst:EntropyPour
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.1.xsd"etxmlns:wsse="http://docs.oasis-open.org/wss/2005/xx/oasis-2005xx-wss-wssecurity-secext-1.1.xsd"wsse:Passwordwsse:Nonce
Informations potentiellement personnelles supprimées :
Pour
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.1.xsd"etxmlns:wsse="http://docs.oasis-open.org/wss/2005/xx/oasis-2005xx-wss-wssecurity-secext-1.1.xsd"wsse:Usernamewsse:BinarySecurityTokenPour
xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion", les éléments suivants dansboldsont supprimés :
<Assertion MajorVersion="1 » MinorVersion="1 » AssertionId="[ID] » Issuer="[string] » IssueInstant="[dateTime] »
<Conditions NotBefore="[dateTime] » NotOnOrAfter="[dateTime]"><AudienceRestrictionCondition><Audience>[uri]</Audience>+ </AudienceRestrictionCondition>* <DoNotCacheCondition />* <-- abstract type <Condition />*
</Conditions> ?
<Conseil><AssertionIDReference>[ID]</AssertionIDReference>* <Assertion>[assertion]</Assertion>* [any]* </Advice> ?
<-- Abstract base types<, instruction />* <SubjectStatement SubjectStatement><>
<NameIdentifier
NameQualifier="[string]"?
Format="[uri]"?
>
[string]
</NameIdentifier>?
<SubjectConfirmation><ConfirmationMethod>[anyUri]</ConfirmationMethod>+ <SubjectConfirmationData[any]>/SubjectConfirmationData<> ?
<ds :KeyInfo>...</ds :KeyInfo> ?
</SubjectConfirmation> ?
</Sujet/DéclarationDuSujet><>*
<AuthenticationStatement AuthenticationMethod="[uri] » AuthenticationInstant="[dateTime] »
[Objet]
<SubjectLocality
IPAddress="[string]"?
DNSAddress="[string]"?
/>?
<AuthorityBinding AuthorityKind="[QName] » Location="[uri] » Binding="[uri] » />* /* </AuthenticationStatement* >AttributeStatement<> [Subject] <Attribute AttributeName="[string] » AttributeNamespace="[uri] »
<AttributeValue>[any]</AttributeValue>+
</Attribute+ >/AttributeStatement<>* <AuthorizationDecisionStatement Resource="[uri] » Decision="[Permit|Refuser|Indéterminé]"
[Objet] <Action Namespace="[uri]">[string]</Action>+ <Evidence><AssertionIDReference>[ID]</AssertionIDReference>+ <Assertion>[assertion]</Assertion>+ </Evidence> ? </AuthorizationDecisionStatement>* </Assertion>
Informations supprimées des corps de messages lors de la journalisation des messages déchiffrés/non chiffrés
Comme décrit précédemment, WCF supprime les clés et les informations potentiellement personnelles connues des en-têtes de message pour les messages déchiffrés et non chiffrés enregistrés. De plus, WCF supprime les clés et les informations potentiellement personnelles connues des corps de messages pour les actions et éléments de corps figurant dans la liste suivante, qui décrivent des messages de sécurité impliqués dans l’échange de clé.
Pour les espaces de noms suivants :
xmlns:wst="http://schemas.xmlsoap.org/ws/2004/04/trust" et xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust" (par exemple, si aucune action n’est disponible)
Les informations sont supprimées pour ces éléments de corps, qui impliquent l'échange de clé :
wst:RequestSecurityToken
wst:RequestSecurityTokenResponse
wst:RequestSecurityTokenResponseCollection
Les informations sont également supprimées pour chacune des actions suivantes :
http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issuehttp://schemas.xmlsoap.org/ws/2005/02/trust/RSTR/Issuehttp://schemas.xmlsoap.org/ws/2005/02/trust/RST/Renewhttp://schemas.xmlsoap.org/ws/2005/02/trust/RSTR/Renewhttp://schemas.xmlsoap.org/ws/2005/02/trust/RST/Cancelhttp://schemas.xmlsoap.org/ws/2005/02/trust/RSTR/Cancelhttp://schemas.xmlsoap.org/ws/2005/02/trust/RST/Validatehttp://schemas.xmlsoap.org/ws/2005/02/trust/RSTR/Validatehttp://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCThttp://schemas.xmlsoap.org/ws/2005/02/trust/RSTR/SCThttp://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT/Amendhttp://schemas.xmlsoap.org/ws/2005/02/trust/RSTR/SCT/Amendhttp://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT/Renewhttp://schemas.xmlsoap.org/ws/2005/02/trust/RSTR/SCT/Renewhttp://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT/Cancelhttp://schemas.xmlsoap.org/ws/2005/02/trust/RSTR/SCT/Cancelhttp://schemas.xmlsoap.org/ws/2004/04/security/trust/RST/SCThttp://schemas.xmlsoap.org/ws/2004/04/security/trust/RSTR/SCThttp://schemas.xmlsoap.org/ws/2004/04/security/trust/RST/SCT-Amendhttp://schemas.xmlsoap.org/ws/2004/04/security/trust/RSTR/SCT-Amend
Aucune information n’est supprimée des en-têtes et des données de corps propres à l’application
WCF ne suit pas les informations personnelles dans les en-têtes spécifiques à l’application (par exemple, les chaînes de requête) ou les données de corps (par exemple, numéro de carte de crédit).
Lorsque la journalisation des messages est activée, les informations personnelles dans les en-têtes spécifiques à l’application et les informations de corps peuvent être visibles dans les journaux. Là encore, le déployeur d’applications est chargé de définir les listes de contrôle d’accès sur les fichiers journaux et de configuration. Ils peuvent également désactiver la journalisation s’ils ne veulent pas que ces informations soient visibles ou filtrent ces informations à partir des fichiers journaux une fois journalisées.
Suivi du modèle de service
La source de trace du modèle de service (System.ServiceModel) permet le suivi des activités et des événements liés au traitement des messages. Cette fonctionnalité utilise la fonctionnalité de diagnostic .NET Framework à partir de System.Diagnostics. Comme avec la MessageLogging propriété, l’emplacement et sa liste de contrôle d’accès sont configurables par l’utilisateur à l’aide de fichiers de configuration d’application .NET Framework. Comme pour la journalisation des messages, l’emplacement du fichier est toujours configuré lorsque l’administrateur active le suivi ; ainsi, l’administrateur contrôle la liste de contrôle d’accès.
Les suivis contiennent des en-têtes de messages lorsqu'un message est dans la portée. Les mêmes règles pour masquer les informations potentiellement personnelles dans les en-têtes de message de la section précédente s’appliquent : les informations personnelles précédemment identifiées sont supprimées par défaut des en-têtes dans les traces. L’administrateur de l’ordinateur et le déployeur d’applications doivent modifier la configuration afin de journaliser des informations potentiellement personnelles. Toutefois, les informations personnelles contenues dans des en-têtes spécifiques à l’application sont consignées dans des traces. Le déployeur d’application est chargé de définir les listes de contrôle d’accès sur les fichiers de configuration et de trace. Ils peuvent également désactiver le suivi pour masquer ces informations ou filtrer ces informations à partir des fichiers de trace après sa journalisation.
Dans le cadre du suivi ServiceModel, les ID uniques (appelés ID d’activité, et généralement un GUID) relient différentes activités lorsque les messages transitent par différentes parties de l’infrastructure.
Écouteurs de trace personnalisés
Pour la journalisation et le suivi des messages, un écouteur de suivi personnalisé peut être configuré, qui peut envoyer des traces et des messages sur le câble (par exemple, à une base de données distante). Le déployeur d’applications est chargé de configurer des écouteurs personnalisés ou d’autoriser les utilisateurs à le faire. Il est également responsable des informations personnelles exposées à l’emplacement distant et de l’application correcte des listes ACL à cet emplacement.
Autres fonctionnalités pour les professionnels de l’informatique
WCF dispose d’un fournisseur WMI qui expose les informations de configuration de l’infrastructure WCF via WMI (fourni avec Windows). Par défaut, l’interface WMI est disponible pour les administrateurs.
La configuration WCF utilise le mécanisme de configuration .NET Framework. Les fichiers de configuration sont stockés sur l’ordinateur. Le développeur d’applications et l’administrateur créent les fichiers de configuration et la liste de contrôle d’accès pour chacune des exigences de l’application. Un fichier de configuration peut contenir des adresses de point de terminaison et des liens vers des certificats dans le magasin de certificats. Les certificats peuvent être utilisés pour fournir des données d’application pour configurer différentes propriétés des fonctionnalités utilisées par l’application.
WCF utilise également la fonctionnalité de vidage de processus du .NET Framework en appelant la méthode FailFast.
Outils professionnels de l’informatique
WCF fournit également les outils professionnels de l’informatique suivants, qui sont fournis dans le Kit de développement logiciel (SDK) Windows.
SvcTraceViewer.exe
La visionneuse affiche les fichiers de trace WCF. La visionneuse affiche toutes les informations contenues dans les suivis.
SvcConfigEditor.exe
L’éditeur permet à l’utilisateur de créer et de modifier des fichiers de configuration WCF. L’éditeur affiche les informations contenues dans les fichiers de configuration. La même tâche peut être effectuée avec un éditeur de texte.
ServiceModel_Reg
Cet outil permet à l’utilisateur de gérer les installations de ServiceModel sur un ordinateur. L’outil affiche les messages d’état dans une fenêtre de console lorsqu’il s’exécute et, dans le processus, peut afficher des informations sur la configuration de l’installation wcf.
WSATConfig.exe et WSATUI.dll
Ces outils permettent aux professionnels de l’informatique de configurer la prise en charge du réseau interopérable WS-AtomicTransaction dans WCF. Les outils affichent et permettent à l’utilisateur de modifier les valeurs des paramètres de WS-AtomicTransaction les plus couramment utilisés stockés dans le Registre.
Caractéristiques croisées
Les fonctionnalités suivantes sont transversales. Autrement dit, elles peuvent être composées avec l’une des fonctionnalités précédentes.
Infrastructure de service
Les en-têtes peuvent contenir un ID d’instance, qui est un GUID qui associe un message à une instance d’une classe CLR.
Le langage WSDL (Web Services Description Language) contient une définition du port. Chaque port a une adresse de point de terminaison et une liaison qui représente les services utilisés par l’application. L’exposition de WSDL peut être désactivée à l’aide de la configuration. Aucune information n’est conservée sur la machine.