Comment implémenter la connexion dans un service Web RESTful?

Question

Je suis en création d'une application web avec une couche de services. La couche de services va être construit à l'aide d'une bonne conception. L'idée, c'est qu'à un certain moment dans le futur, on peut construire d'autres applications (iPhone, Android, etc.) qui utilisent les mêmes services que la couche de l'application web. Ma question est-ce - comment puis-je mettre en œuvre de connexion? Je pense que je vais avoir de la difficulté à bouger de façon plus traditionnelle verbe de base de conception d'une ressource en fonction de la conception. Si j'ai été la construction de ce avec du SAVON, je serais probablement à une méthode de Connexion. Au RESTE, je devrait avoir une ressource. Je vais avoir de la difficulté à comprendre comment je dois construire mon URI pour une connexion. Devrait-il être quelque chose comme ceci:

http://myservice/{username}?p={mot de passe}

EDIT: avant La fin de l'application web utilise le traditionnel ASP.NET cadre pour l'authentification. Cependant, à un certain point dans le processus d'authentification j'ai besoin de valider les informations d'identification fournies. Dans un cadre traditionnel de l'application web, je ferais une recherche de base de données. Mais dans ce cas, je vais appeler un service, plutôt que de faire une recherche de base de données. J'ai donc besoin de quelque chose dans le service qui permettra de valider les informations d'identification fournies. Et en plus de valider les informations d'identification fournies j'ai probablement aussi besoin d'une sorte de renseignements au sujet de l'utilisateur après qu'ils ont authentifié avec succès - des choses comme leur nom complet, leur carte d'identité, etc. J'espère que cela rend la question plus claire.

Ou ne suis-je pas penser à ce la bonne manière? Je sens que je vais avoir de la difficulté à décrire ma question correctement.

Corey

Answer 1

Comme S. Lott a souligné déjà, nous avons deux plié chose ici: de Connexion et d'authentification

L'authentification est hors-sujet ici, comme cela est largement discutée et il est commun accord. Cependant, que faisons-nous réellement besoin pour un client de s'authentifier avec succès contre un service web RESTful? À droite, un type de jeton, nous allons l'appeler accès à jeton.

Client) Donc, tout ce que je besoin est un accès à jeton, mais comment obtenir ces Paisiblement?
Serveur), Pourquoi ne pas simplement créer?
Client) Comment?
Serveur) Pour moi, un accès à jeton n'est rien d'autre qu'une ressource. Donc, je vais en créer un pour vous en échange de votre nom d'utilisateur et mot de passe.

Ainsi, le serveur peut offrir la ressource URL "/accesstokens", pour afficher le nom d'utilisateur et mot de passe pour remettre le lien vers la ressource nouvellement créée "/accesstokens/{accesstoken}". Alternativement, vous revenez à un document contenant de l'accès à jeton et un href avec la ressource du lien:

<accès à jeton
 id="{jeton d'accès id va ici; par exemple, GUID}"
href="http://stackoverflow.com/accesstokens/{id}"
/>

Très probablement, vous n'avez pas réellement créer l'accès à jeton comme un sous-ressource et donc, de ne pas inclure de href de la réponse.
Toutefois, si vous procédez ainsi, le client peut générer le lien sur son nom ou pas? Non!
Rappelez-vous, vraiment des services web RESTful de lien entre les ressources de manière à ce que le client peut naviguer sans la nécessité de générer des liens de ressources.

La dernière question, vous avez probablement est si vous devez afficher le nom d'utilisateur et mot de passe comme un formulaire HTML ou d'un document, par exemple XML ou JSON - ça dépend... :-)

Answer 2

Vous n'avez pas "login". Vous "s'authentifier". Monde de différence.

Vous avez beaucoup d'authentification des solutions de rechange.

HTTP Basic, Digest, NTLM et AWS S3 Authentification

• Authentification HTTP Basic et Digest. Il utilise l' HTTP_AUTHORIZATION - tête. C'est très joli, très simple. Mais il peut conduire à beaucoup de trafic.

• Nom d'utilisateur/l'authentification de signatures. Parfois appelé "l'ID et la CLÉ d'authentification. Il peut s'agir d'une chaîne de requête.

  ?username=this&signature=some-big-hex-digest

  C'est ce que des endroits comme Amazon utilisation. Le nom d'utilisateur est "id". La "clé" est un recueil de la, similaire à celui utilisé pour l'authentification HTTP Digest. Les deux côtés sont d'accord sur le résumé de procéder.

• Une sorte de cookie d'authentification. OpenAM, par exemple, peut être configuré comme un agent d'authentifier et de fournir un cookie que votre serveur web RESTful pouvez ensuite utiliser. Le client doit s'authentifier en premier, et ensuite fournir le cookie avec chaque Reposant demande.

Answer 3

Depuis un peu a changé depuis 2011...

Si vous êtes ouvert à l'aide d'un outil 3ème partie, et légèrement divergentes RESTE légèrement pour l'INTERFACE web, envisager de http://shiro.apache.org.

Shiro vous donne essentiellement un filtre de servlet adaptés pour l'authentification et l'autorisation. Vous pouvez utiliser toutes les méthodes d'authentification répertoriés par @S. Lott, y compris un simple formulaire d'authentification.

Filtre le reste Url qui nécessitent une authentification, et Shiro fera le reste.

Je suis actuellement utilisé dans mon projet et il a très bien fonctionné pour moi jusqu'à présent.

Voici quelque chose d'autre personnes peuvent être intéressées. https://github.com/PE-INTERNATIONAL/shiro-jersey#readme

Answer 4

J'ai rencontré le même problème avant. La connexion ne se traduit pas bien pour les ressources de base de conception.

La façon dont j'ai l'habitude de le manipuler, c'est d'avoir de Connexion de ressources et de passage nom d'utilisateur et mot de passe sur la chaîne de paramètre, essentiellement faire

OBTENIR sur http://myservice/login?u={nom d'utilisateur} et p={mot de passe}

La réponse est une sorte de session ou auth chaîne qui peut ensuite être transmis à d'autres Api pour la validation.

Une alternative à fait OBTENIR sur la connexion de ressources est en train de faire un POST, RESTE les puristes ne sera probablement pas comme moi maintenant :), et en passant dans le creds dans le corps. La réponse serait la même.