Laden...

Authorisierung & Authentifizierung in einer Microservice Architektur

Erstellt von Regenwurm vor 8 Jahren Letzter Beitrag vor 8 Jahren 2.460 Views
R
Regenwurm Themenstarter:in
295 Beiträge seit 2008
vor 8 Jahren
Authorisierung & Authentifizierung in einer Microservice Architektur

Hallo Experten,

Um uns für ein grösseres Projekt vorzubereiten entwickeln wir zur Zeit eine kleinere Web-Applikation welche die Microservice Architektur unterstützt.

Damit die einzelnen REST-Services geschützt sind, möchten wir eine Authorisierung einbauen die Service-Übergreifend ist und müssen da scheinbar noch auf den richtigen Weg geschupst werden.
Was uns da spontan in den Sinn kommt ist eine OpenID Implementation.

Dazu folgende Fragen:

  • Ist es korrekt, dass wir damit unseren eigenen Identity Server benötigen (beispielsweise https://identityserver.github.io).
  • Wir möchten die User und/oder Clients auf Policies überprüfen (keine Role-Based Authentication). Können wir diese auch auf dem IDP selber oder müssen wir diese auf allen Services definieren?
  • Business Logik Überprüfungen (beispielsweise ob ein Benutzer eine Gruppe editieren und/oder löschen kann) wird dann nicht mehr direkt mit dem OAuth Protokoll geregelt, sondern über 'eigene' interne Strukturen. Ist dies korrekt so oder haben wir da einen Denkfehler?
  • Gibt es wichtige Punkte die wir noch beachten müssen?

Beste Grüsse,
Wurm

ServiceStack & Angular = =)

16.807 Beiträge seit 2008
vor 8 Jahren

Wenn ihr selbst der OAuth (ich sag auch OAuth, mein aber damit OAuth 2.0)Provider sein wollt, dann braucht ihr auch einen entsprechenden Server, zB den IdentityServer.

Ab der Stelle, bei der Du authentifizierst hast Du em Backend ein Principal-Objekt (oder ähnliches).
Das kannst Du ja in Deinem Backend-Code auch verwenden. Darin sind Claims, die zB dann für die jeweilige Aktions-Authorisierung verwenden kannst.
Standardmäßig gibt es in der Regel sowas wie ClaimTypes.Role, das Du zB für Rollenbasierte Authorisierung verwendest.

Du kannst auch eigene Claims erstellen und für zB Policies missbrauchen; hab ich aber noch nicht gemacht.
Gibt aber zB das IAuthorizationPolicy Interface, das dafür evtl. verwendet werden könnte.

R
Regenwurm Themenstarter:in
295 Beiträge seit 2008
vor 8 Jahren

Hi Abt,

Danke für deine Antwort.
Wir wollen schlussendlich eine OAuth Login-Möglichkeit anbiete, sprich:

  • Entweder der Benutzer registriert sich bei uns mit Email & Passwort und konfiguriert dann sein Profil (weitere Daten wie beispielsweise.. Beruf, Anschrift, was weiss ich) oder
  • er nutzt einen IDP wie Facebook oder Google, authentifiziert sich dort und konfiguriert dann sein Profil weiter bei uns (wieder; Beruf, Anschrift etc).

Wichtig ist hier, dass wir wie erwähnt eine Microservice Architektur verwenden und keinen Monolith.
Alle Services können zwar die IDP Authentifizierung nachverfolgen, wie aber die Custom-Authentifizierung (die nicht über einen externen IDP, sondern über unser eigenes System erledigt wurde) verifiziert wird ist mir noch unschlüssig.
Kannst du uns da noch weiter helfen?
Oder ist - wie erwähnt - die beste Lösung, dass unser Auth-Service selber auch ein IDP also quasi ein IdentityServer ist?

Gruss,
Wurm

ServiceStack & Angular = =)

16.807 Beiträge seit 2008
vor 8 Jahren

Microservice nur verwenden, damit mans als Marketing quasi verwendet, ja das ist grade Trend 😃
Was versteht ihr denn bei euch als Microservice? Die Auth*-Machanismen haben damit nämlich recht wenig zutun 😉

Euer Auth*-System könnt ihr so umsetzen, dass der eigene Login via Forms funktioniert und das externe via OAuth.
So ist auch das Standard ASP.NET MVC Template mit externen Providern umgesetzt. Nichts anderes beschreibst Du gerade.
Im einfachsten Fall muss nur eine einzige Zeile beim Standardtemplate angepasst werden; nämlich die CookieDomain setzen - und dann eben noch den MachineKey via Web.Config bei allen Services synchronisieren.

Als eigenen OAuth-Provider aufzutreten macht vor allem sinn, wenn man eben auch mehrere eigene APIs hat und/oder mehrere eigene/fremde Clients hat, die auf diese APIs zugreifen.

R
Regenwurm Themenstarter:in
295 Beiträge seit 2008
vor 8 Jahren

Hey Abt,

Keine Ahnung wie positiv die Repräsentation damit im Marketing ist. 😉
Wir sind alles bald-Absolventen und und interessieren uns für die Thematik da so etwas in unserem Bachelor Studium nicht mehr so genau (oder gar nicht? 😃) gelehrt wird. Keine Angst das hat nichts mit Firmenstrategie oder reiner Publicity zu tun. 😉

Siehe Anhang für die Microservice Idee.
Die Aufteilung hier mag zwar trivial sein, soll ja aber auch nur als Beispiel- & Lernprojekt dienen.

Danke für den Input bzgl. normales Login via Forms - ich schaus mir nochmals genauer an!
Mag sein dass ich ein wenig eingerostet bin und mir dadurch das Ganze komplizierter vorstelle als es überhaupt ist.
Aber ja schlussendlich sollen es mehrere Services geben, auf welche durch ein Gateway geroutet wird.
Clients wird es SPA und Mobile App geben.

Besten Dank,
Wurm.

ServiceStack & Angular = =)

16.807 Beiträge seit 2008
vor 8 Jahren

Ja, das ist eine typische, einfache Microservice Architektur.
Lässt sich aber alles typischerweise, wenn es keine externe Möglichkeit für OAuth geben soll, mit dem Standard ASP.NET Template abdecken.