0 votes

Services Web Authentification Jungle

J'ai fait quelques recherches dernièrement sur les meilleures approches pour authentifier les appels de services web (REST SOAP ou autre). Mais aucune des approches ne m'a convaincu... Mais je n'arrive toujours pas à faire un choix...
Certains parlent de SSL et d'authentification de base http -login/mot de passe- ce qui semble bizarre pour une machine (je veux dire qu'il faut attribuer un login/mot de passe à une machine, n'est-ce pas ?)
D'autres parlent de clés API (il semble que ce système soit davantage utilisé pour le suivi et pas vraiment pour la sécurisation).
Certains parlent de jetons (comme les identifiants de session), mais ne devrions-nous pas rester apatrides (surtout dans le style REST) ?

Dans mon cas d'utilisation, lorsqu'une application distante appelle l'un de nos services Web, je dois évidemment authentifier l'application appelante, et l'appel doit - le cas échéant - m'indiquer quel utilisateur il usurpe afin que je puisse gérer l'autorisation ultérieurement.

Qu'en pensez-vous ?

1voto

Will Hartung Points 57465

Donc, vous avez Utilisateur -> clientServeur -> votreServeur, oui ?

Vous devez authentifier clientServer -> yourServer, pour vous assurer que personne ne peut parler à votre serveur.

S'il s'agit d'une relation de confiance établie (c'est-à-dire que vous discutez, signez des documents et faites d'autres choses "hors bande"), vous pouvez simplement utiliser des certificats SSL, des certificats que vous pouvez signer.

En gros, vous créez votre propre autorité de certification, vous créez un certificat racine, puis vous créez un certificat client signé par ce certificat racine.

Vous envoyez ensuite ce certificat au client-serveur et ne laissez personne se connecter à votre service s'il ne possède pas un certificat signé par votre certificat racine.

Si le client met un jour un terme à sa relation, vous pouvez révoquer son certificat et il ne pourra plus vous parler.

Quant à l'identification de l'utilisateur, elle devra faire partie de l'API. Le client doit les authentifier correctement, puis vous transmettre les informations d'identification dont vous avez besoin.

Il peut s'agir d'un élément de première classe de votre service Web (comme un paramètre) ou, si vous utilisez SOAP, il peut être transmis dans une pièce jointe SAML dans l'en-tête SOAP, que vous pouvez ensuite extraire.

WS-Security propose environ 8000 façons de sécuriser les services web SOAP, comme vous avez pu le découvrir.

Cela dépend donc de ce que vous voulez faire, et d'autres exigences. Mais étant donné le peu que vous avez, cela devrait fonctionner à merveille.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X