Services Web sécurisés: REST via HTTPS et SOAP + WS-Security. Ce qui est mieux?
Je ne suis en aucun cas un expert en sécurité, mais je suis favorable à la création de services Web de style REST.
En créant un nouveau service qui doit sécuriser les données qu'il transmet. Nous sommes entrés dans un débat sur l'approche la plus sécurisée: REST avec HTTPS ou un SOAP WS avec WS-Security.
J'ai l'impression que nous pourrions utiliser le protocole HTTPS pour tous les appels de service Web et cette approche serait sécurisée. À mon sens, "si le protocole HTTPS convient assez bien aux sites Web des banques et des finances, il l'est aussi pour moi". Encore une fois, je ne suis pas un expert dans ce domaine, mais je pense que ces personnes ont beaucoup réfléchi à ce problème et sont à l'aise avec le protocole HTTPS.
Un collègue est en désaccord et dit SOAP et WS-Security est la seule solution.
Le web semble être omniprésent à cet égard.
Peut-être que la communauté ici pourrait peser sur le pour et le contre de chacun? Merci!
Le protocole HTTPS sécurise la transmission du message sur le réseau et fournit au client certaines assurances quant à l'identité du serveur. C'est ce qui est important pour votre banque ou votre courtier en valeurs mobilières en ligne. Leur intérêt pour l'authentification du client ne réside pas dans l'identité de l'ordinateur, mais dans votre identité. Ainsi, les numéros de carte, noms d'utilisateur, mots de passe, etc. sont utilisés pour vous authentifier. Quelques précautions sont alors généralement prises pour s’assurer que les soumissions n’ont pas été falsifiées, mais dans l’ensemble, tout ce qui se passe au cours de la session est considéré comme ayant été initié par vous.
WS-Security offre une protection d'intégrité et de confidentialité depuis la création du message jusqu'à sa consommation. Ainsi, au lieu de veiller à ce que le contenu des communications ne puisse être lu que par le bon serveur, il garantit qu'il ne peut être lu que par le bon processus sur le serveur. Au lieu de supposer que toutes les communications de la session lancée de manière sécurisée proviennent de l'utilisateur authentifié, elles doivent toutes être signées.
Il y a une explication amusante impliquant des motards nus ici:
Ainsi, WS-Security offre davantage de protection que HTTPS et SOAP offre une API plus riche que REST. Mon avis est que, sauf si vous avez réellement besoin de fonctionnalités ou de protection supplémentaires, évitez les frais généraux liés à SOAP et à WS-Security. Je sais que c'est un peu une échappatoire, mais ceux qui connaissent le problème intimement doivent prendre les décisions concernant le degré de protection qui est réellement justifié (pas seulement ce qui serait cool à construire).
La sécurité REST dépend du transport, alors que SOAP sécurité ne l’est pas.
REST hérite des mesures de sécurité du transport sous-jacent alors que SOAP définit ses propres mesures via WS-Security.
Lorsque nous parlons de REST, via HTTP, toutes les mesures de sécurité appliquées par HTTP sont héritées. Cette sécurité est appelée sécurité au niveau du transport.
La sécurité au niveau du transport ne sécurise votre message que lorsqu'il est sur le réseau - dès qu’il quitte le réseau, le message n’est plus sécurisé.
Cependant, avec WS-Security, sa sécurité au niveau du message - même si le message quitte le canal de transport, il sera toujours protégé. De plus, avec la sécurité au niveau du message, vous pouvez partiellement chiffrer le message [pas le message en entier, mais uniquement les parties que vous souhaitez] - mais avec la sécurité au niveau du transport, vous ne pouvez pas le faire.
WS-Security propose des mesures d'authentification, d'intégrité, de confidentialité et de non-répudiation, tandis que SSL ne prend pas en charge la non-répudiation [avec OAuth à deux pieds].
En termes de performances, SSL est beaucoup plus rapide que WS-Security.
Merci...
Techniquement, le libellé n'est pas correct, car la communication de la méthode SOAP n'est pas sécurisée et la méthode REST ne dit rien sur l'authentification des utilisateurs légitimes.
HTTPS empêche les attaquants de espionner sur la communication entre deux systèmes. Il vérifie également que le système hôte (serveur) est bien le système hôte auquel l'utilisateur a l'intention d'accéder.
WS-Security empêche les applications non autorisées (utilisateurs) d'accéder au système.
Si un système RESTful dispose d'un moyen d'authentifier les utilisateurs et qu'une application SOAP avec WS-Security utilise HTTPS, les deux sont réellement sécurisés. C'est juste une manière différente de présenter et d'accéder aux données.
Voir l'article wiki :
Dans des situations point à point, la confidentialité et l'intégrité des données peuvent également être appliquées aux services Web via l'utilisation de TLS (Transport Layer Security), par exemple, en envoyant des messages via https.
Cependant, WS-Security résout le problème plus général du maintien de l'intégrité et de la confidentialité des messages jusqu'à ce qu'un message ait été envoyé depuis le nœud d'origine, en fournissant la sécurité dite de bout en bout.
C'est:
- HTTPS est un mécanisme de sécurité de la couche de transport (point à point)
- WS-Security est un mécanisme de sécurité de la couche d'application (de bout en bout).
Comme vous le dites, REST convient aux banques et devrait donc l’être aussi.
La sécurité comporte deux aspects principaux: 1) le cryptage et 2) l’identité.
La transmission en SSL/HTTPS permet un cryptage sur le réseau. Mais vous devez également vous assurer que les deux serveurs peuvent confirmer qu'ils savent à qui ils parlent. Cela peut être via des certificats clients SSL, des secrets de partage, etc.
Je suis sûr que l’on pourrait affirmer que SOAP est "plus sécurisé" mais probablement pas de manière significative. L'analogie de motard nue est mignonne, mais si elle était exacte, cela impliquerait que tout Internet ne soit pas sécurisé.
Je n'ai pas encore le représentant nécessaire pour ajouter un commentaire ou je l'aurais simplement ajouté à la réponse de Bell. Je pense que Bell a très bien résumé les avantages et les inconvénients de haut niveau des deux approches. Quelques autres facteurs à prendre en compte:
1) Les demandes entre vos clients et votre service doivent-elles passer par des intermédiaires ayant besoin d'accéder à la charge utile? Si tel est le cas, WS-Security pourrait être un meilleur ajustement.
2) Il est en fait possible d'utiliser SSL pour fournir au serveur l'assurance de l'identité du client à l'aide d'une fonctionnalité appelée authentification mutuelle. Cependant, cela n’est pas très utile en dehors de certains scénarios très spécialisés en raison de la complexité de sa configuration. Bell a donc raison de dire que WS-Sec convient beaucoup mieux ici.
3) Le protocole SSL en général peut être un peu difficile à configurer et à maintenir (même dans la configuration la plus simple) en raison principalement de problèmes de gestion des certificats. Avoir quelqu'un qui sait comment faire cela pour votre plate-forme sera un gros plus.
4) Si vous devez effectuer une forme de mappage des informations d'identification ou une fédération d'identité, WS-Sec peut en valoir la peine. Non pas que vous ne puissiez pas faire cela avec REST, vous avez juste moins de structure pour vous aider.
5) Obtenir tous les atouts de WS-Security aux bons endroits du côté client peut être plus pénible que vous ne le pensez.
En fin de compte, cela dépend toutefois de beaucoup de choses que nous ne saurons probablement pas. Dans la plupart des situations, je dirais que l’une ou l’autre approche sera "suffisamment sûre" et que cela ne devrait donc pas être le principal facteur décisif.
Brace yourself, here there's another coming :-)
Aujourd'hui, j'ai dû expliquer à ma petite amie la différence entre le pouvoir expressif de WS-Security et celui de HTTPS. C'est une informaticienne, alors même si elle ne connaît pas tout le charabia XML, elle comprend (peut-être mieux que moi) ce que cryptage ou signature signifie. Cependant, je voulais une image forte, ce qui pourrait la faire comprendre vraiment à quoi les choses servent, plutôt que la façon dont elles sont mises en œuvre (un peu plus tard, elle n'y a pas échappé :-)).
Alors ça va comme ça. Supposons que vous êtes nu et que vous devez conduire votre moto vers une certaine destination. Dans le cas (A), vous passez par un tunnel transparent: votre seul espoir de ne pas être arrêté pour comportement obscène est que personne ne regarde. Ce n'est pas exactement la stratégie la plus sécurisée avec laquelle vous pouvez sortir ... (remarquez la sueur qui tombe du front des gars :-)). Cela équivaut à un POST en clair, et lorsque je dis "équivalent", je le pense vraiment. Dans le cas (B), vous êtes dans une meilleure situation. Le tunnel est opaque, donc tant que vous y entrez, vos archives publiques sont en sécurité. Cependant, ce n'est toujours pas la meilleure situation. Vous devez encore quitter la maison et atteindre l'entrée du tunnel. Une fois à l'extérieur du tunnel, vous devrez probablement descendre et marcher quelque part ... et cela vaut pour HTTPS. Certes, votre message est en sécurité tant qu'il traverse le plus gros gouffre: mais une fois que vous l'avez transmis de l'autre côté, vous ne savez pas vraiment combien d'étapes il devra franchir avant d'atteindre le point réel où les données seront traitées. Et bien sûr, toutes ces étapes pourraient utiliser quelque chose de différent du HTTP: un MSMQ classique qui stocke des requêtes qui ne peuvent pas être traitées immédiatement, par exemple. Que se passe-t-il si quelqu'un cache vos données alors qu'il se trouve dans cette zone de prétraitement? Hm. (lisez ce "hm" comme celui prononcé par Morpheus à la fin de la phrase "pensez-vous que vous respirez l'air?"). La solution complète (c) de cette métaphore est terriblement triviale: prenez des vêtements sacrément sur vous-même et surtout sur le casque en moto !!! Vous pouvez donc circuler en toute sécurité sans avoir à compter sur l’opacité des environnements. J'espère que la métaphore est claire: les vêtements vous accompagnent quels que soient la moyenne ou l'infrastructure environnante, comme le fait la sécurité au niveau des messages. En outre, vous pouvez décider de couvrir une partie mais d'en révéler une autre (et vous pouvez le faire à titre personnel: la sécurité de l'aéroport peut retirer votre veste et vos chaussures, votre médecin pouvant avoir un niveau d'accès plus élevé), mais n'oubliez pas que les chemises à manches courtes mauvaise pratique même si vous êtes fier de votre biceps :-) (mieux un polo, ou un t-shirt).
Je suis heureux de dire qu'elle a compris le point! Je dois dire que la métaphore des vêtements est très puissante: j'ai été tenté de l'utiliser pour introduire le concept de politique (les discothèques ne vous laisseront pas porter des chaussures de sport; vous ne pouvez pas aller retirer de l'argent dans une banque en sous-vêtements , bien que ce soit parfaitement acceptable tout en vous balançant sur un surf, et ainsi de suite) mais je pensais que pour un après-midi c'était suffisant ;-)
Architecture - WS, idées sauvages
Je travaille dans cet espace tous les jours, donc je veux résumer les bons commentaires à ce sujet dans le but de clore ceci:
SSL (HTTP/s) n’est qu’une couche assurant:
- Le serveur auquel vous vous connectez présente un certificat prouvant son identité (bien que cela puisse être usurpé par un empoisonnement DNS).
- La couche de communication est cryptée (pas d'écoute indiscrète).
WS-Security et les normes/implémentations associées utilisent PKI qui:
- Prouver l'identité du client.
- Prouvez que le message n'a pas été modifié en transit (MITM).
- Permet au serveur d'authentifier/autoriser le client.
Le dernier point est important pour les demandes de service lorsque l’identité du client (appelant) est primordial pour savoir s’il doit être autorisé à recevoir de telles données du service. SSL standard est une authentification unidirectionnelle (serveur) et ne fait rien pour identifier le client.
REST sur HTTPS Devrait être une méthode sécurisée tant que le fournisseur d'API implémente l'autorisation à la fin du serveur. Dans le cas d’une application Web, nous accédons également à une application Web via HTTPS et une certaine authentification/autorisation. Traditionnellement, les applications Web n’avaient pas de problèmes de sécurité. Par conséquent, une API reposante permettrait également de résoudre les problèmes de sécurité sans problème!
La réponse dépend en fait de vos besoins spécifiques.
Par exemple, avez-vous besoin de protéger vos messages Web ou la confidentialité n'est pas requise et tout ce dont vous avez besoin est d'authentifier les correspondants et d'assurer l'intégrité des messages? Si tel est le cas - et c'est souvent le cas avec les services Web - HTTPS est probablement le mauvais marteau.
Cependant - de par mon expérience - ne négligez pas la complexité du système que vous construisez. Non seulement HTTPS est plus facile à déployer correctement, mais une application qui repose sur la sécurité de la couche de transport est plus facile à déboguer (via HTTP simple).
Bonne chance.
Si votre appel RESTFul envoie des messages XML dans le corps HTML de la requête HTTP, vous devriez pouvoir bénéficier de tous les avantages de WS-Security, tels que le cryptage XML, les certificats, etc. dans vos messages XML, tout en utilisant les fonctions de sécurité. sont disponibles à partir de http tels que le cryptage SSL/TLS.