wake-up-neo.com

Wie implementiere ich die Anmeldung in einem RESTful-Webdienst?

Ich erstelle eine Webanwendung mit einer Serviceebene. Die Service-Schicht wird mit einem RESTful-Design erstellt. Es wird davon ausgegangen, dass wir in Zukunft möglicherweise andere Anwendungen (iPhone, Android usw.) erstellen, die dieselbe Dienstschicht wie die Webanwendung verwenden. Meine Frage ist: Wie implementiere ich die Anmeldung? Ich glaube, ich habe Probleme, von einem traditionelleren verbbasierten Design zu einem ressourcenbasierten Design zu wechseln. Wenn ich dies mit SOAP erstellen würde, hätte ich wahrscheinlich eine Methode namens Login. In REST Ich hätte eine Ressource. Ich habe Schwierigkeiten zu verstehen, wie ich sollte konstruiere meine URI für ein Login. Sollte es so aussehen:

http: // myservice / {Benutzername}? p = {Passwort}

BEARBEITEN: Die Front-End-Webanwendung verwendet das herkömmliche ASP.NET-Framework für die Authentifizierung. Irgendwann im Authentifizierungsprozess muss ich jedoch die angegebenen Anmeldeinformationen überprüfen. In einer herkömmlichen Webanwendung würde ich eine Datenbanksuche durchführen. Aber in diesem Szenario rufe ich einen Dienst an, anstatt eine Datenbanksuche durchzuführen. Ich benötige also einen Dienst, der die angegebenen Anmeldeinformationen überprüft. Und neben der Überprüfung der angegebenen Anmeldeinformationen benötige ich wahrscheinlich auch Informationen über den Benutzer, nachdem er sich erfolgreich authentifiziert hat - beispielsweise seinen vollständigen Namen, seine ID usw. Ich hoffe, dass dies die Frage klarer macht.

Oder denke ich nicht richtig darüber nach? Ich habe das Gefühl, dass ich Schwierigkeiten habe, meine Frage richtig zu beschreiben.

Corey

77
Corey Burnett

Wie S.Lott bereits betont hat, haben wir hier zwei Dinge zusammengefasst: Login und Authentifizierung

Die Authentifizierung ist hier nicht zulässig, da dies vielfach diskutiert wird und eine gemeinsame Übereinkunft besteht. Was benötigen wir jedoch tatsächlich, damit sich ein Client erfolgreich bei einem RESTful-Webdienst authentifiziert? Richtig, eine Art Token, nennen wir es Access-Token.

Client) Also, alles was ich brauche ist ein Access-Token, aber wie bekomme ich so RESTfully?
Server) Warum nicht einfach erstellen?
Kunde) Wie kommt das?
Server) Ein Access-Token ist für mich nichts anderes als eine Ressource. Daher erstelle ich eine für Sie im Austausch für Ihren Benutzernamen und Ihr Passwort.

Somit könnte der Server die Ressourcen-URL "/ accesstokens" zum POSTEN des Benutzernamens und des Kennworts anbieten und den Link zur neu erstellten Ressource "/ accesstokens/{accesstoken}" zurückgeben. Alternativ geben Sie ein Dokument mit dem Zugriffstoken und einer href mit dem Link der Ressource zurück:

 <Zugriffstoken 
 id = "{Zugriffstoken-ID wird hier abgelegt, z. B. GUID}" 
 href = "/ accesstokens/{id}" 
 /> 

Höchstwahrscheinlich erstellen Sie das Access-Token nicht als Subressource und nehmen daher dessen href nicht in die Antwort auf.
Wenn Sie dies jedoch tun, könnte der Client den Link in seinem Namen generieren oder nicht? Nein!
Denken Sie daran, dass wirklich REST-konforme Webdienste Ressourcen so miteinander verknüpfen, dass der Client selbst navigieren kann, ohne Ressourcenverknüpfungen erstellen zu müssen.

Die letzte Frage, die Sie wahrscheinlich haben, ist, ob Sie POST den Benutzernamen und das Passwort als HTML-Formular oder als Dokument, z. B. XML oder JSON, eingeben sollten - es kommt darauf an ... :-)

59
Patrick

Du "loggst dich nicht ein". Sie "authentifizieren". Welt der Unterschiede.

Sie haben viele Authentifizierungsalternativen.

HTTP Basic-, Digest-, NTLM- und AWS S3-Authentifizierung

  • HTTP Basic- und Digest-Authentifizierung. Dies verwendet die HTTP_AUTHORIZATION Header. Das ist sehr schön, sehr einfach. Kann aber zu viel Verkehr führen.

  • Benutzername/Unterschrift Authentifizierung. Wird manchmal als "ID and KEY" -Authentifizierung bezeichnet. Dies kann eine Abfragezeichenfolge verwenden.

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

    Dies ist, was Orte wie Amazon verwenden. Der Benutzername ist die "ID". Der "Schlüssel" ist ein Digest, ähnlich dem für die HTTP-Digest-Authentifizierung verwendeten. Beide Seiten müssen sich auf die Zusammenfassung einigen, um fortzufahren.

  • Eine Art Cookie-basierte Authentifizierung. OpenAM kann beispielsweise als Agent konfiguriert werden, um sich zu authentifizieren und ein Cookie bereitzustellen, das Ihr RESTful-Webserver dann verwenden kann. Der Client würde sich zuerst authentifizieren und dann das Cookie mit jeder REST-Anforderung bereitstellen.

24
S.Lott

Gute Frage, gut gestellt. Ich mag Patricks Antwort wirklich. Ich benutze sowas

-/users/{username}/loginsession

Mit POST und GET wird verarbeitet. Ich poste also eine neue Anmeldesitzung mit Anmeldeinformationen und kann dann die aktuelle Sitzung über GET als Ressource anzeigen.

Bei der Ressource handelt es sich um eine Anmeldesitzung, für die möglicherweise ein Zugriffstoken oder ein Authentifizierungscode, ein Ablaufdatum usw. vorhanden ist.

Seltsamerweise muss mein MVC-Aufrufer selbst ein Schlüssel-/Träger-Token über einen Header präsentieren, um zu beweisen, dass er das Recht hat, neue Anmeldesitzungen zu erstellen, da die MVC-Site ein Client der API ist.

Bearbeiten

Ich denke, einige andere Antworten und Kommentare hier lösen das Problem mit einem gemeinsamen Out-of-Band-Geheimnis und authentifizieren sich nur mit einem Header. Das ist in vielen Situationen oder für Service-to-Service-Anrufe in Ordnung.

Die andere Lösung besteht darin, ein Token OAuth oder JWT oder anderweitig, was bedeutet, dass die "Anmeldung" bereits von einem anderen Prozess stattgefunden hat, wahrscheinlich einer normalen Anmelde-Benutzeroberfläche in einem Browser, der darauf basiert ein Formular POST.

Meine Antwort ist für den Dienst, der sich hinter dieser Benutzeroberfläche befindet, vorausgesetzt, Sie möchten die Anmeldung und die Authentifizierungs- und Benutzerverwaltung in einem REST Service und nicht im MVC-Code der Site. Es IS der Benutzeranmeldedienst.

Es ermöglicht auch anderen Diensten, sich anzumelden und ein ablaufendes Token abzurufen, anstatt einen vorinstallierten Schlüssel zu verwenden, sowie Testskripte in einer CLI oder einem Postman.

1
Luke Puplett

Das erste, was Sie über REST verstehen sollten, ist, dass es sich um einen Token-basierten Ressourcenzugriff handelt. Im Gegensatz zu herkömmlichen Methoden wird der Zugriff auf der Grundlage der Token-Validierung gewährt Jetzt gibt es eine Menge anderer Dinge für die Erstellung und Manipulation von Token.

Für Ihre erste Frage können Sie eine Restfull-API entwerfen. Anmeldeinformationen (Benutzername und Passwort) werden an Ihre Serviceebene übergeben. Die Serviceebene überprüft diese Anmeldeinformationen und erteilt ein Token. Die Anmeldeinformationen können entweder ein einfacher Benutzername/Passwort oder SSL-Zertifikate sein. SSL-Zertifikate verwenden das Protokoll OAUTH und sind sicherer.

Sie können Ihre URI wie folgt gestalten - URI für Token-Anforderung -> http: // myservice/some-directory/token ? (Sie können Credentilals in dieser URI für Token übergeben.)

Um dieses Token für den Ressourcenzugriff zu verwenden, können Sie dieses [Berechtigung: Träger (Token)] zu Ihrem http-Header hinzufügen.

Mit diesem Token kann der Kunde auf verschiedene Komponenten Ihrer Service-Schicht zugreifen. Sie können auch den Ablaufzeitraum dieses Tokens ändern, um einen Missbrauch zu verhindern.

Bei Ihrer zweiten Frage können Sie verschiedene Token für den Zugriff auf verschiedene Ressourcenkomponenten Ihrer Serviceschicht vergeben. Hierfür können Sie in Ihrem Token einen Ressourcenparameter und basierend auf diesem Feld eine allgemeine Berechtigung angeben.

Sie können auch diesen Links folgen, um weitere Informationen zu erhalten- http://www.codeproject.com/Articles/687647/Detailed-Tutorial-for-Building-ASP-NET-WebAPI-REST

http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api

0
Rishabh Soni

Da hat sich seit 2011 einiges geändert ...

Wenn Sie bereit sind, ein Drittanbieter-Tool zu verwenden, und von REST geringfügig für die Web-Benutzeroberfläche abweichen, ziehen Sie http://shiro.Apache.org in Betracht.

Shiro bietet Ihnen grundsätzlich einen Servlet-Filter, der sowohl für die Authentifizierung als auch für die Autorisierung vorgesehen ist. Sie können alle von @ S.Lott aufgelisteten Anmeldemethoden verwenden, einschließlich einer einfachen formularbasierten Authentifizierung.

Filtern Sie die restlichen URLs, die eine Authentifizierung erfordern, und Shiro erledigt den Rest.

Ich verwende dies derzeit in meinem eigenen Projekt und es hat bisher ziemlich gut für mich funktioniert.

Hier ist noch etwas, was andere Leute interessieren könnte. https://github.com/PE-INTERNATIONAL/shiro-jersey#readme

0
Half_Duplex