Implementieren der Authentifizierung und der rollenbasierten Autorisierung im ASP.NET MVC-Web-API-Dienst und in der MVC-Client-Architektur

8

Ich habe Schwierigkeiten, einen Ansatz zu finden, während ich das Authentifizierungs- / Autorisierungsszenario für mein Web-API (Service) - MVC (Client) -Architekturprojekt implementiere. Obwohl ich die benutzerdefinierte tokenbasierte Authentifizierung im Web-API-Projekt implementiert habe, finde ich es schwierig, wo genau ich die Berechtigung implementieren sollte (im Client oder in der API selbst).

Architekturübersicht:

  • Projektlösung -


    | __ ASP.NET-Web-API-basierten REST-Dienst (unabhängig gehostet auf IIS bei M / C 1)


    | __ ASP.NET MVC-basierter Client (unabhängig auf IIS gehostet bei M / C 2 Consuming REST-Dienst)


    | __ Smartphone-Client-Anwendung (Konsumieren des REST-Dienstes)

Bereits implementierte Authentifizierung:

  • Token-basierte Authentifizierung in der Web-API (mit Message Handler) - Die SHA1-Token für den authentifizierten Benutzer generiert, der Teil jedes http-Anfrage-Headers für die Authentifizierung sein muss.
    (Token = Benutzername + Benutzer-IP)

  • SSL-geschützte HTTP-Anfrage. (Erneut mit Message Handler)

Aktuelle Probleme:

  1. Auf welcher Ebene sollte die Autorisierung implementiert werden?
  2. Wie sollte die Benutzerrolle beim Client beibehalten werden? Verwenden von Cookies? oder Hinzufügen von Rolleninformationen zu Token selbst (was zusätzlichen Aufwand für die API zum Entschlüsseln der Informationen und zusätzliche DB-Aufrufe zum Abrufen von mit dieser Rolle verknüpften Berechtigungen zur Folge haben kann)
  3. Wie sollte das Authentifizierungs-Token in der Client-Sitzung beibehalten werden?
  4. Da meine Anwendung SPA MVC-Anwendung ist, Was ist der beste Weg, das Authentifizierungstoken als Teil jedes AJAX-Aufrufs, den ich an die API mache, einzuschließen?

Ich hoffe, ich mache keine Fehler, wenn ich das gesamte Authentifizierungs- / Autorisierungskonzept in Betracht ziehe. Daher schätze ich jeden alternativen Ansatz / Vorschlag.

    
vabz 29.10.2013, 14:37
quelle

2 Antworten

3

Erstens denke ich, dass es nie eine gute Idee ist, einen eigenen Authentifizierungsmechanismus zu erfinden.

Um Ihre aktuellen Probleme zu beantworten:

1 Im Allgemeinen möchten Sie Ihre Api immer mit der Authentifizierung sichern, da Sie dort auf Ihre Daten zugreifen. Ihr Client (MVC App / Smartphone) sollte sich selbst autorisieren, um auf Ihre API zuzugreifen.

2 & amp; 3 Da Sie eine REST Api verwenden, würde ich vorschlagen, Ihre Api statuslos zu halten, mit anderen Worten, keine Sitzungsinformationen zu speichern. Fügen Sie einfach die erforderlichen Rollendaten in Ihr Token ein. Sie könnten zum Beispiel ein JSON Web Token verwenden.

4 Ich würde immer den Berechtigungsheader verwenden, um Autorisierungsdaten zu senden. In Ihrem DelegatingHandler (beachten Sie den Unterschied MessageHandler MVC, DelegatingHander HTTP) können Sie einfach den Header abrufen.

%Vor%

Weitere Informationen zum Einschließen des Autorisierungsheaders in einen Ajax-Aufruf finden Sie unter: Wie benutze ich Basic Auth mit jQuery und AJAX?

Zusätzliche Informationen:

Wenn ich Sie wäre, würde ich mir auch den Identity Server von Thinktecture ansehen: Ссылка

Und vielleicht hilft Ihnen diese Antwort zur REST-Service-Authentifizierung auch: REST-Service-Authentifizierung

    
Jos Vinke 29.10.2013, 15:39
quelle
0

Warum erstellen Sie ein vollständiges Token-System (es sei denn, Sie verwenden eine Art föderierte Sicherheit) Sie haben Formularauthentifizierung und Cookies, sobald der Cookie gesetzt und zurückgegeben wird der Browser sendet das Cookie mit allen AJAX-Anfragen von Ihrem SPA.

    
CSharpYouDull 29.10.2013 15:20
quelle

Tags und Links

Django: Verwenden von Annotate, Count und Distinct in einem Queryset Wählen Sie mehrere Dateien mit Intent.ACTION_GET_CONTENT aus