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:
Beste Grüsse,
Wurm
ServiceStack & Angular = =)
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.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Hi Abt,
Danke für deine Antwort.
Wir wollen schlussendlich eine OAuth Login-Möglichkeit anbiete, sprich:
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 = =)
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.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
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 = =)
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.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code