Services Web Authentification Jungle

Question

J'ai récemment fait des recherches 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 ne peux toujours pas faire un choix ...
Certains parlent de SSL et authentification de base http --login/mot de passe - qui semble juste bizarre pour une machine (je veux dire avoir à attribuer un identifiant/mot de passe à une machine, ou n'est-ce pas?).
Certains autres disent API clés (semble que ce schéma est plus utilisé pour le suivi et pas vraiment pour la sécurisation).
Certains disent des jetons (comme les identifiants de session) mais ne devrions-nous pas rester apatrides (surtout si nous utilisons le style REST)? Dans mon cas d'utilisation, lorsqu'une application distante appelle un de nos services Web, je dois évidemment authentifier l'application appelante, et l'appel doit - le cas échéant - me dire quel utilisateur il usurpe pour que je puisse traiter avec autorisation plus tard.

Des pensées?

Answer 1

Donc, vous avez User -> clientServer -> yourServer, oui?

Vous devez authentifier clientServer -> yourServer pour vous assurer que tout le monde ne peut pas parler à votre serveur. S'il s'agit d'une relation d'approbation établie (c'est-à-dire que vous clavardez, signez des documents et effectuez d'autres opérations hors bande), vous pouvez simplement utiliser des certificats SSL, des certificats que vous pouvez signer.

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

Vous envoyez ensuite ce certificat au clientServer et ne laissez personne se connecter à votre service qui n'a pas de certificat signé par votre certificat racine.

Si le client cesse jamais sa relation, vous pouvez révoquer son CERT et il ne peut plus vous parler. En ce qui concerne l'identification de l'utilisateur, cela devra faire partie de l'API. Le client doit les authentifier correctement, puis transmettre les informations d'identification dont vous avez besoin. Cela peut être une partie 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 l'avez peut-être découvert. Donc, cela dépend de ce que vous voulez faire, et d'autres exigences. Mais vu le peu que vous avez, cela devrait marcher.