Les meilleures Pratiques pour sécuriser une API REST / web service

Question

Lors de la conception d'une API REST ou d'un service sont-il des pratiques exemplaires établies pour traiter de la sécurité (Authentification, l'Autorisation, la Gestion de l'Identité) ?

Lors de la construction d'une API SOAP, vous avez WS-Security en tant que guide et beaucoup de littérature existe sur le sujet. J'ai trouvé de moins en moins d'informations sur la sécurisation RESTE des points de terminaison.

Alors que je comprends le REPOS intentionnellement ne pas avoir des caractéristiques analogues à WS-* je suis en espérant que les meilleures pratiques ou les modèles recommandés ont émergé.

Toute discussion ou des liens vers des documents pertinents serait très apprécié. Si il le faut, nous serions en utilisant WCF avec POX/JSON sérialisé messages pour notre API REST/Services construit à l'aide de la v3.5 de la .NET Framework.

Answer 1

Comme tweakt dit, Amazon S3 est un bon modèle pour travailler avec. Leur demande de signatures n'ont certaines fonctions (telles que l'intégration d'un timestamp) qui aident à protéger contre accidentelle ou malveillante demande de relecture.

La bonne chose à propos de HTTP de Base est que pratiquement tous HTTP bibliothèques de soutien. Vous aurez, bien sûr, besoin de besoin de SSL dans ce cas, car l'envoi de mots de passe en clair sur le net est presque toujours une mauvaise chose. De base est préférable à Digérer lors de l'utilisation de SSL, car même si l'appelant sait déjà que les informations d'identification sont nécessaires, Digérer nécessite un aller-retour supplémentaire pour l'échange de la valeur de nonce. Avec la de Base, les appelants il suffit d'envoyer les informations d'identification de la première fois.

Une fois l'identité du client est établie, l'autorisation est vraiment juste un problème de mise en œuvre. Cependant, vous pourriez déléguer l'autorisation à d'autres composantes à un modèle d'autorisation. De nouveau la bonne chose à propos de Base ici est que votre serveur se termine avec une copie en clair du mot de passe du client que vous pouvez tout simplement passer à un autre composant au sein de votre infrastructure en tant que de besoin.

Answer 2

Il n'existe pas de normes pour le REPOS autres que HTTP. Il y a établi des services REST. Je vous suggère de prendre un coup d'oeil à eux et avoir une idée de comment ils fonctionnent.

Par exemple, nous avons emprunté beaucoup d'idées, d'Amazon S3 RESTE de service lors de l'élaboration de notre propre. Mais nous avons choisi de ne pas utiliser le plus avancé modèle de sécurité basé sur la demande de signatures. L'approche la plus simple est HTTP Basic auth sur SSL. Vous devez décider ce qui fonctionne le mieux dans votre situation.

Aussi, je recommande fortement le livre des Services Web RESTful de O'reilly. Il explique les concepts de base et de ne fournir certaines des meilleures pratiques. Vous pouvez généralement prendre le modèle qu'ils fournissent et de l'associer à votre propre application.

Answer 3

Vous pouvez également prendre un coup d'oeil à OAuth, un nouveau protocole d'ouverture de la base de jeton d'autorisation ciblant spécifiquement l'api http.

Il est très similaire à l'approche adoptée par flickr et ne pas oublier le lait de "repos" api (pas nécessairement de bons exemples de restful api, mais de bons exemples de la base de jeton d'approche).

Answer 4

Je suis un peu surpris de SSL avec des certificats client n'a pas encore été mentionnés. Accordé, cette approche n'est vraiment utile que si vous pouvez compter sur la communauté des utilisateurs sont identifiés par des certificats. Mais un certain nombre de gouvernements ou de sociétés de faire question à leurs utilisateurs. L'utilisateur n'a pas à se préoccuper de la création pourtant, un autre nom d'utilisateur/mot de passe, et l'identité est établie sur chaque connexion afin que la communication avec le serveur peut être entièrement apatrides, pas de sessions d'utilisateur requis. (Ne signifie pas que l'une ou l'autre des solutions mentionnés ont besoin de séances)

Answer 5

Tout le monde dans ces réponses a négligé vrai contrôle de l'accès ou de l'autorisation.

Si par exemple votre Api REST / services web sont sur l'Affichage / GETing des dossiers médicaux, vous pouvez définir le contrôle d'accès policie sur qui peut accéder aux données et dans quelles circonstances. Par exemple:

• les médecins peuvent OBTENIR le dossier médical d'un patient qu'ils ont une relation de soins avec
• nul ne peut publier des données médicales à l'extérieur des heures de pratique (par exemple de 9 à 5)
• les utilisateurs peuvent OBTENIR les dossiers médicaux personnels ou les dossiers médicaux des patients pour lesquels ils sont les gardiens
• les infirmières peuvent mettre à JOUR le dossier médical d'un patient qui appartient à la même unité que l'infirmière.

Afin de définir et de mettre en œuvre ces fine des autorisations, vous aurez besoin d'utiliser un attribut de contrôle d'accès basé langue appelée XACML, eXtensible Access Control Markup Language.

Les autres normes sont ici pour la suite:

• OAuth: id. de la fédération et de la délégation d'autorisation, par exemple en laissant une loi sur le service sur mon compte sur un autre service (Facebook peut poster sur mon Twitter)
• SAML: la fédération d'identité / web SSO. SAML est très bien à propos de qui est l'utilisateur.
• WS-Security / WS-* normes: elles mettent l'accent sur la communication entre les services SOAP. Elles sont spécifiques au niveau de l'application de messagerie format (SOAP) et ils traitent de certains aspects de la messagerie par exemple la fiabilité, la sécurité, la confidentialité, l'intégrité, l'atomicité, des concours... Aucun couvercle de contrôle d'accès et tous sont spécifiques à SAVON.

XACML est la technologie de l'agnostique. Il peut être appliqué à des applications java, .NET, Python, Ruby... services web, Api REST, et plus encore.

Les éléments suivants sont des ressources intéressantes:

• l'OASIS XACML site web
• le NIST ABAC standard