Consultez la FAQ sur le ZF avant de poster une question
Vous n'êtes pas identifié.
Bonjour,
depuis le début de la semaine je réfléchis à des solutions de restriction des services web mis en place.
J'ai lu pas mal de documentation depuis 2 jours, et je sais que la question est vague, mais si vous avez implémenté des services web, comment les avez-vous sécurisés ?
Mon problème est :
1) d'authentifier un programme qui tourne en tâche de fond (via un plugin installé sur le browser) appelant un web service ;
2) crypter les données et envoyer les données de ce plugin vers le serveur.
Inutile de dire que mon portail est de structure MVC zend framework.
Merci d'avance de vos réponses.
Hors ligne
https si possible et un échange par clef publique clef privées pour garantir l'authentification.
crypter est très coûteux mais c'est un plus.
utiliser d'autre verbes que POST GET HEAD et PUT
A+JYT
Hors ligne
Même solution. La seule solution sécurisée à mon sens est l'https, avec login et mot de passe. C'est ce que j'ai implémenté pour mes services web.
Hors ligne
@maiky : tu parles d'un "vrai" webservice avec SOAP, WSDL et tout ce qui va avec ? Si c'est le cas, tu as pas mal de couches de sécurité standard, notamment https pour le transport et WS-Security qui a pour but de vérifier :
- que c'est bien toi qui envoie la réponse (basé sur XML Signature)
- ton intervenant est bien celui qu'il prétend être (basé sur XML encryption)
A+, Philippe
PS : je ne l'ai jamais mis en place, c'est une réponse très théorique, mais ces technos sont faites pour...
Hors ligne
Merci beaucoup pour vos réponses !
J'avais pensé à la solution https donc merci sekaijin et vg33 de confirmer.
Philippe pour l'instant avec des webservices simplistes REST et donc c'est vrai que pour SOAP j'ai vu plusiurs implémentations de WS-Security. Mais on ne sait pas encore réellement si on aura besoin de webservices SOAP, REST étant très simple et rapide à mettre en place.
@ vg33 : je reviens sur ta solution https/login et mot de passe. L'utilisation de tes webservices se limite à des clients "connus" (authentifiés sur ton site) ou est restreinte par exemple à 2 machines auquel cas tu passes directement les login/mot de passe dans la requête ?
@ seikaijin : quel est le coût de la méthode clé publique/clé privée ?
Merci encore pour vos réponses
Hors ligne
c'est surtout dans la mise en oeuvre que cela coute. il te faut un couple pk/sk pour le serveur et ensuite il t'en faut autant que de client pour les clients.
le serveur doit connaitre toutes les clefs de ses clients ensuite il existe des algo qui prennent les clefs croisées
pk du serveur sk du client (côté serveur) et qui génère une clef de transaction le couple
sk du serveur pk du client générant la même clef de transaction
le client vas donc générer un clef de transaction avec la sk du serveur et sa pk et la transmettre dans le flux
le serveur recevant le flux vas prendre sa pk et la sk du client (il faut les générer toutes) pour générer la clef de transaction si la clef transmise et identique à une de celle généré c'est ok sinon c'est un usurpateur.
ça demande donc du calcul et surtout un infrastructure bien maitrisée. les pk ne doivent surtout pas trainer
c'est donc impossible à utiliser en Ajax à moins d'avoir un plugin déployé sur le poste client.
car le code provenant du serveur ne doit pas véhiculer les clefs privés du client. et le code javascript n'a pas accès au données du poste client.
A+JYT
Hors ligne
Merci pour ta réponse complète sekaijin
C'est vrai que cette méthode demande du temps et beaucoup de moyens pour la mettre en place.
Est ce que ça veut dire qu'en terme d'architecture physique ton serveur gérant les clés est différent de celui hébergeant ton site ? Je suppose que si c'est le cas ça complique encore les choses au niveau du nombre de requêtes passées ...
Hors ligne
le tier de "confiance" (certifié) est effectivement un plus non négligeable et ça rends les choses encore plus compliquées
A+JYT
Hors ligne
Mes services web sont utilisés par des applications distantes, et par l'application elle-même (elle requête ses propres services pour factoriser le code).
Tout simplement, au moment d'instancier le service web, le client doit envoyer son login et mot de passe (en https je rappelle), et son authentification est conservée en session.
Hors ligne
Merci @ tous pour vos lumières
J'espère revenir vers vous pour un compte rendu mais pour l'instant c'est beaucoup de travail pour mettre tout ça en place.
Hors ligne
Bonsoir,
je déterre un peu ce topic.
J'ai besoin de développer un webservice pour séparer une gestion d'un portail public.
Je n'ai jamais développé de webservices mais j'en utilise deux en SOAP qui ont des méthodes d'authentification différentes.
Le premier (d'OVH) demande une auth au départ, retourne l'ID de session qui est ensuite le premier paramètre de chacune des fonctions appelées.
Le second (un truc plus privé) demander le couple login / password dans chacune des fonctions.
Est-ce qu'il y a une grande différence entre les deux méthodes ?
Comme je développe la partie server de la partie client, j'ai un max de flexibilité. Mais est-ce préférable de réduire au minimum le nombre de fonctions appelées dans un script ?
Je m'explique. J'ai par exemple besoin d'envoyer depuis la gestion client les factures de 1000 clients sur la partie publique. Est-ce que je fais une méthode simple qui enverra pour chaque client sa facture (donc méthode appelée 1000 fois) ou est-ce que je m'oblige à tout envoyer en une seule fois pour que ce soit sur la partie publique que je décortique le tout ?
Hors ligne
Sur mes services Web en plus d'une clé j'ai aussi une protection par referrer . c'est à dire que seul certain ip sont autorisé a consommé les WS. Après cela nécessite de connaître les ip .
Si tu fait 1000 appels un par un et que tu as un problème de liaison tu risque d'avoir des pertes ? alors que si tu retourne tes 1000 lignes en un appel tu limite les pertes. Voila c'est mon avis
Hors ligne