Benutzerautorisierung mit Microservices

12

Sollten Microservices für die Abwicklung ihrer eigenen Autorisierung verantwortlich sein, oder ist es Ihrer Meinung nach besser, einen separaten Autorisierungsdienst zu haben, der für alle oder eine Teilmenge (innerhalb derselben Geschäftsdomäne) von Microservices gemeinsam genutzt wird?

Letzteres ist für mich sinnvoller, da es einfacher ist, Änderungen anzuwenden und Richtlinien durchzusetzen. Es ist trocken usw. Es kann jedoch leicht außer Kontrolle geraten, wenn alle Arten von Diensten ihre Regeln an einem Ort ablegen und sich auch Sorgen über den Netzwerk-Overhead machen.

Irgendwelche Gedanken?

architecture authorization microservices

— morcmarc
quelle

7

Ich würde ein zentrales, einheitliches Authentifizierungssystem verwenden und separate Berechtigungen / Statistiken für jeden Mikrodienst haben (ähnlich wie ich auf dieser Stack-Exchange-Site noch nicht upvoten kann, aber ich kann einen Stack-Überlauf durchführen, während ich das zentrale Stack-Exchange-Authentifizierungssystem verwende). Eines meiner aktuellen Projekte wird diesen Ansatz in naher Zukunft beinhalten, was sehr schön sein wird. Die vorherigen Entwicklungsarbeiten umfassten die Erstellung eines HIPPA-kompatiblen Systems, das eine zweite Autorisierungs- / Authentifizierungsebene erfordert, und es ist ein zeitaufwändiges Ärgernis, Verkettungsberechtigungen von rechtlich getrennten, aber funktional untrennbaren Komponenten des Systems zu verketten. Der Debugging-Prozess ist viel weniger erfreulich als ein einfaches Oauth-Login oder eine API mit Appid- und X-Auth-Headern.

Welche zu verwenden ist, hängt von den spezifischen Anforderungen einer Entwicklungs-Roadmap ab, aber ich würde nach Möglichkeit den einfacheren Ansatz wählen, um übermäßigen Overhead und Entwicklungszeit / -aufwand zu vermeiden.

— Jonathan Voss
quelle

Wir verwenden OAuth2 für die Authentifizierung, und ich möchte dem gleichen Prinzip folgen - das heißt, einen zentralen Dienst mit einer einzigen, genau definierten Verantwortung - für die Autorisierung zu haben, anstatt die Funktionalität und die Streulogik über die Dienste hinweg zu duplizieren. Für mich ist es eine Verletzung der Domaingrenze. Ich stimme jedoch zu, dass dies bedeutet, dass wir die Isolierung der Serviceregeln (z. B. Stackoverflow, Programmierer usw.) regeln müssen.

— Morcmarc

2

Möglicherweise verfügen Sie über globale Berechtigungen, die durch dienstspezifische Berechtigungen außer Kraft gesetzt werden. Dies ist hilfreich, wenn eine Handvoll zentraler Mikrodienste dieselben Berechtigungen verwenden. Die Microservice-spezifischen Berechtigungen sollten wahrscheinlich in der App-Infrastruktur für diesen Microservice gespeichert werden, um potenzielle Leistungsprobleme für den zentralen Authentifizierungsdienst zu vermeiden.

— Jonathan Voss

4

Jeder Microservice sollte keine eigene Authentifizierung durchführen müssen, sondern eine eigene Autorisierung.

Quelle

Und das macht durchaus Sinn. Ich gehe davon aus, dass es keinen Zweifel an der zentralen Authentifizierung gibt. Die Autorisierung ist jedoch ziemlich verwirrend.

Angesichts der Tatsache, dass die Anzahl der Mikrodienste auf Hunderte, Tausende ansteigen kann, sollte ein zentraler Autorisierungsdienst nur für die Auflistung von Berechtigungen verantwortlich sein, diese Berechtigungen jedoch nicht validieren. Einzelne Mikrodienste müssen möglicherweise anders vorgehen, um die Berechtigung zu validieren.

Dieser zentrale Autorisierungsdienst muss möglicherweise Modelle von verschiedenen Diensten abrufen und sich unterschiedlich verhalten, um Entscheidungen zu treffen. Am Anfang sieht er möglicherweise einfach und hübsch aus. Könnte aber später Chaos sein.

— Ashwani Agarwal
quelle