WCF Transport vs Message
je lisais sur les implémentations de sécurité WCF et j'ai découvert qu'il y avait 2 types de sécurité: Transport Mode and Message Mode (or both)
Si j'ai utilisé HTTPS pour le mode de transport, est-il plus sécurisé si j'ai également utilisé la sécurité des messages? je pose la question car ce que je comprends est le suivant:
https utilise le protocole SSL qui crypte les messages ... alors pourquoi devrais-je ajouter Message Security et crypter le message crypté SSL? ou suis-je un malentendu?
La sécurité dans WCF en fait se compose de plusieurs fonctionnalités . La différence entre ces deux est la façon dont les messages sont signés et chiffrés.
La sécurité du transport ne fournit que la sécurité des canaux point à point. Cela signifie que HTTPS établit un canal sécurisé uniquement entre le client et le serveur exposé au client. Mais si ce serveur n'est qu'un équilibreur de charge ou un serveur proxy inverse, il a un accès direct au contenu du message.
La sécurité des messages offre une sécurité de bout en bout. Cela signifie que la sécurité fait partie des données transférées et que seule la destination prévue peut déchiffrer les données (l'équilibreur de charge ou le proxy ne voit que les messages chiffrés). Dans la plupart des cas, la sécurité des messages utilise également des certificats pour fournir le chiffrement et la signature, mais elle est généralement plus lente car la sécurité du transport peut utiliser l'accélération matérielle.
Dans les scénarios avancés, ces méthodes peuvent être combinées. Par exemple, vous pouvez sécuriser la communication avec votre équilibreur de charge par HTTPS car vous faites confiance à votre réseau interne après l'équilibreur de charge, mais en même temps, vous pouvez faire signer le message (sécurité des messages) afin de pouvoir prouver qu'il n'a pas été modifié.
Une autre différence entre ces deux est que la sécurité du transport est liée au protocole de transport unique tandis que la sécurité des messages est indépendante du protocole de transport.
La sécurité des messages est basée sur des protocoles interopérables (mais sachez que toutes les configurations dans WCF ne sont pas interopérables). WCF prend en charge au moins partiellement ces protocoles:
- WS-Security 1.0 et 1.1 - règles de base pour le chiffrement, la signature, le transport de jetons, les horodatages, etc.
- UserName token profile 1.0 - définition du jeton utilisé pour transporter le nom d'utilisateur et le mot de passe. Cette spécification n'est implémentée que partiellement car WCF prêt à l'emploi ne prend pas en charge le mot de passe digéré et nécessite l'utilisation de ce jeton avec le transport ou le chiffrement des messages.
- X509 token profile 1.1 - définition du jeton utilisé pour le transport des certificats.
- Kerberos token profile 1.1 - définition du jeton utilisé pour le transport des tickets Kerberos.
- SAML 1.1 token profile 1.0 and 1.1 - définition du jeton utilisé pour la sécurité fédérée. SAML 2.0 est fourni par WIF.
- WS-SecurityPolicy 1.1 et 1.2 - prend en charge la définition de l'assertion de sécurité dans WSDL.
- WS-SecureConversation 1.3 et février 2005 - prend en charge la session de sécurité où les informations d'identification sont échangées uniquement lors du premier appel et le reste de la communication utilise un jeton de sécurité unique.
- WS-Trust 1.3 et février 2005 - prend en charge les scénarios fédérés et les services de jetons de sécurité (STS).
WCF prend également en charge WS-I Basic Security Profile 1.0, qui n'est qu'un sous-ensemble d'anciens protocoles avec une configuration prescrite.
Pour les fonctionnalités non interopérables, WCF propose des fonctionnalités telles que la sécurité Windows ou TLSNego et SPNego (les deux devraient généralement être interopérables mais ne sont pas disponibles dans de nombreuses SOAP) pour l'échange d'informations d'identification de service.
Ce lien décrit les raisons d'utiliser ou de ne pas utiliser la sécurité des messages.
Fondamentalement, la sécurité du transport est préférable, sauf si elle ne peut pas être utilisée.
Un extrait du lien:
Avantages et inconvénients de la sécurité au niveau du transport
La sécurité des transports présente les avantages suivants:
Ne nécessite pas que les parties communicantes comprennent les concepts de sécurité de niveau XML. Cela peut améliorer l'interopérabilité, par exemple, lorsque HTTPS est utilisé pour sécuriser la communication.
Performances généralement améliorées.
Des accélérateurs matériels sont disponibles.
Le streaming est possible.
La sécurité des transports présente les inconvénients suivants:
Hop-to-hop uniquement.
Ensemble limité et inextensible d'informations d'identification.
Dépendant du transport.
Inconvénients de la sécurité au niveau des messages
La sécurité des messages présente les inconvénients suivants:
Performance
Impossible d'utiliser le streaming de messages.
Nécessite la mise en œuvre de mécanismes de sécurité de niveau XML et la prise en charge de la spécification WS-Security. Cela pourrait affecter l'interopérabilité.
Il y a aussi des cas où vous ne pourrez peut-être pas avoir un chiffrement au niveau du transport et donc "retomber" sur le chiffrement au niveau du message, qui est juste un peu moins sûr que la sécurité au niveau du transport.
Faire les deux sera plus sûr, bien sûr. Mais c'est un peu exagéré lorsque vous avez une bonne sécurité au niveau du transport.
Je dirais que dans la plupart des cas, cela devrait suffire à l'un ou à l'autre. Si vous pouvez utiliser la sécurité au niveau du transport qui est préférable car elle crypte la communication entière, pas seulement le contenu du message.