it-swarm.com.de

Autorisierungs- und Authentifizierungssystem für Microservices und Verbraucher

Wir planen, unser Unternehmenssystem in ein auf Mikrodiensten basierendes System umzugestalten. Diese Mikrodienste werden von unseren eigenen unternehmensinternen Anwendungen und bei Bedarf von Partnern von Drittanbietern verwendet. Eine für die Buchung, eine für Produkte usw.

Wir sind uns nicht sicher, wie wir mit Rollen und Bereichen umgehen sollen. Die Idee ist, drei grundlegende Benutzerrollen wie Administratoren, Agenten und Endbenutzer zu erstellen und die Consumer-Apps bei Bedarf die Feinabstimmung der Bereiche zu ermöglichen.

  • Admins kann standardmäßig alle Ressourcen (für ihre Firma) erstellen, aktualisieren, lesen und löschen.
  • Agenten können Daten für ihr Unternehmen erstellen, aktualisieren und lesen.
  • Endbenutzer kann Daten erstellen, aktualisieren, löschen und lesen, jedoch nicht auf dieselben Endpunkte wie Agenten oder Administratoren zugreifen. Sie können auch Daten erstellen oder ändern, jedoch nicht auf derselben Ebene wie Agenten oder Administratoren. Beispielsweise können Endbenutzer ihre Kontoinformationen aktualisieren oder lesen, genau wie der Agent dies für sie tun kann, sie können jedoch keine Administratornotizen anzeigen oder aktualisieren.

Angenommen, Agenten können standardmäßig jede Ressource für ihr Unternehmen erstellen, lesen und aktualisieren. Dies ist der maximale Umfang, der für ihr Token/ihre Sitzung angefordert werden kann. Entwickler von Clientanwendungen (API-Konsumenten) haben jedoch entschieden, dass einer ihrer Agenten dies kann Lesen und erstellen Sie nur bestimmte Ressourcen.

Ist es eine bessere Praxis, dies in unserer internen Sicherheit zu behandeln und sie diese Daten in unsere Datenbank schreiben zu lassen, oder lassen Sie Clients dies intern tun, indem Sie ein Token mit geringerem Umfang anfordern, und lassen Sie sie schreiben, welcher Agent welchen Umfang in ihrer Datenbank hat ? Auf diese Weise müssten wir nur Token-Bereiche verfolgen.

Der Nachteil dabei ist, dass unser Team auch in unseren internen Anwendungen genau abgestimmte Zugriffsmechanismen erstellen muss.

Mit dieser Denkweise sollten Mikrodienste und ihr Autorisierungssystem nicht mit den Kundenbedürfnissen belästigt werden, da sie nur Verbraucher und nicht Teil des Systems sind (obwohl einige dieser Verbraucher unsere eigenen internen Apps sind).

Ist diese Delegation ein guter Ansatz?

15
Robert

Authentifizierung und Autorisierung sind immer gute Themen

Ich werde versuchen, Ihnen zu erklären, wie wir mit Berechtigungen im aktuellen Mandantendienst umgehen, an dem ich arbeite. Die Authentifizierung und Autorisierung erfolgt auf Token-Basis unter Verwendung des offenen Standards JSON Web Token. Der Dienst stellt eine REST API zur Verfügung, auf die jede Art von Client (Web-, Mobil- und Desktopanwendungen) zugreifen kann. Wenn ein Benutzer erfolgreich authentifiziert wurde, stellt der Dienst ein Zugriffstoken bereit, das auf jedem Client gesendet werden muss Anfrage an den Server.

Lassen Sie mich einige Konzepte vorstellen, die darauf basieren, wie wir Daten in der Serveranwendung wahrnehmen und behandeln.

Ressource : Dies ist eine Einheit oder Gruppe von Daten, auf die ein Client über den Dienst zugreifen kann. Allen Ressourcen, die wir steuern möchten, weisen wir einen einzelnen Namen zu. Wenn wir beispielsweise die nächsten Endpunktregeln haben, können wir sie wie folgt benennen:

product

/products
/products/:id

payment

/payments/
/payments/:id

order

/orders
/orders/:id
/orders/:id/products
/orders/:id/products/:id

Nehmen wir also an, wir haben bisher drei Ressourcen in unserem Dienst; product, payment und order.

Aktion : Dies ist eine Operation, die für eine Ressource ausgeführt werden kann, z. B. Lesen, Erstellen, Aktualisieren, Löschen usw. Es müssen nicht nur die klassischen CRUD-Operationen sein. Sie können beispielsweise eine Aktion mit dem Namen follow ausführen, wenn Sie einen Dienst verfügbar machen möchten, der mithilfe von WebSockets Informationen weitergibt.

Fähigkeit : Die Fähigkeit, ein action an einem resource auszuführen. Zum Beispiel; Produkte lesen, Produkte erstellen usw. Es handelt sich im Grunde genommen nur um ein Ressourcen-/Aktionspaar. Sie können aber auch einen Namen und eine Beschreibung hinzufügen.

Rolle : Eine Reihe von Fähigkeiten, die ein Benutzer besitzen kann. Beispielsweise könnte eine Rolle Cashier die Fähigkeiten "Zahlung lesen", "Zahlung erstellen" oder eine Rolle Seller kann die Fähigkeiten "Produkt lesen", "Reihenfolge lesen", "Bestellung aktualisieren", "Bestellung löschen" haben.

Schließlich kann einem Benutzer verschiedene Rollen zugewiesen werden.


Erläuterung

Wie ich bereits sagte, verwenden wir JSON Web Token und die Fähigkeiten, die ein Benutzer besitzt, werden in der Nutzlast des Tokens deklariert. Nehmen wir also an, wir haben einen Benutzer mit der Rolle des Kassierers und des Verkäufers gleichzeitig für ein kleines Einzelhandelsgeschäft. Die Nutzlast sieht folgendermaßen aus:

{
    "scopes": {
        "payment": ["read", "create"],
        "order": ["read", "create", "update", "delete"]
    }
}

Wie Sie in der Behauptung scopes sehen können, geben wir nicht den Namen der Rollen (Kassierer, Verkäufer) an, sondern nur die Ressourcen und die damit verbundenen Aktionen. Wenn ein Client eine Anforderung an einen Endpunkt sendet, sollte der Dienst prüfen, ob das Zugriffstoken die erforderliche Ressource und Aktion enthält. Zum Beispiel eine GET Anfrage an den Endpunkt /payments/88 wird erfolgreich sein, aber eine DELETE -Anforderung an denselben Endpunkt muss fehlschlagen.


  • Wie man die Ressourcen gruppiert und benennt und wie man die Aktionen und definiert und benennt wird eine Entscheidung der Entwickler sein.

  • Was sind die Rollen und welche Fähigkeiten werden diese Rollen haben, sind Entscheidungen der Kunden.


Natürlich müssen Sie der Nutzlast zusätzliche Eigenschaften hinzufügen, um den Benutzer und den Kunden (Mandanten) zu identifizieren, der das Token ausgestellt hat.

{
    "scopes": {
        ...
    },
    "tenant": "acme",
    "user":"coyote"
}

Mit dieser Methode können Sie den Zugriff eines beliebigen Benutzerkontos auf Ihren Dienst optimieren. Und das Wichtigste ist, dass Sie nicht verschiedene vordefinierte und statische Rollen erstellen müssen, z. B. Admin, Agenten und Endbenutzer , wie Sie in Ihrer Frage hervorheben. Ein Super User ist ein Benutzer, der ein role mit allen besitzt. resources und actions des ihm zugewiesenen Dienstes.

Was ist, wenn es 100 Ressourcen gibt und wir eine Rolle wollen, die Zugriff auf alle oder fast alle von ihnen bietet? Unsere Token-Nutzlast wäre riesig. Dies wird gelöst, indem die Ressourcen verschachtelt und nur die übergeordnete Ressource in den Bereich für Zugriffstoken eingefügt werden.


Die Autorisierung ist ein kompliziertes Thema, das je nach den Anforderungen der einzelnen Anwendungen behandelt werden muss.

14
miso

Ich denke, egal was passiert, Sie möchten, dass Ihre Dienste ein Authentifizierungstoken akzeptieren, das von einem Authentifizierungsdienst bereitgestellt wird, den Sie schreiben, um Benutzer zu validieren. Dies ist der einfachste/sicherste Weg, um den Missbrauch Ihrer Microservices zu verhindern. Wenn Sie möchten, dass ein Client eine gute Erfahrung macht, sollten Sie die kritischen Funktionen im Allgemeinen selbst implementieren und gründlich testen, um sicherzustellen, dass die von Ihnen angebotenen Funktionen gut implementiert sind.

Da alle Anrufer Ihren Microservices den Nachweis erbringen müssen, dass sie authentifiziert wurden, können Sie Berechtigungen auch an diese Authentifizierung binden. Wenn Sie die Möglichkeit bieten, einen Benutzer an eine beliebige Zugriffsgruppe zu binden (oder Gruppen, wenn Sie Lust haben, obwohl das Hinzufügen oder Subtrahieren von Berechtigungen hier schwieriger ist), werden von Ihren Kunden weniger Fragen dazu gestellt, warum Benutzer x konnte eine unerwünschte Operation ausführen. In jedem Fall muss jemand für jeden Dienst eine Überprüfung der Zugriffsliste durchführen, also können Sie es auch sein. Es ist etwas, das zu Beginn aller Dienste sehr leicht codiert werden kann (if ( !TokenAuthorized(this.ServiceName, this.token) { Raise error }). Sie können es auch tun und die Benutzergruppen selbst verfolgen. Es ist richtig, dass Sie einen Berechtigungsgruppen-Manager haben und ihn in die Benutzerverwaltungs-Benutzeroberfläche einarbeiten müssen (vorhandene/neue Gruppe für Benutzerberechtigungen erstellen). Listen Sie die Benutzer, die beim Bearbeiten der Definition an eine Gruppe gebunden sind, auf jeden Fall auf, um Verwirrung zu vermeiden . Aber es ist kein harter Job. Haben Sie einfach Metadaten für alle Dienste und verknüpfen Sie die Zuordnung zwischen Gruppe und Dienst mit der Behandlung des Authentifizierungstokens.

Ok, es gibt also einige Details, aber jeder Ihrer Clients, der diese Funktionalität wünscht, müsste dies auf jeden Fall codieren. Wenn Sie die dreistufigen Benutzerberechtigungen unterstützen, können Sie sie auch einfach auf Benutzerzugriff erweitern Gruppen. Wahrscheinlich wäre ein logischer Schnittpunkt zwischen Basisgruppenberechtigungen und benutzerspezifischen Berechtigungen die richtige Aggregation. Wenn Sie jedoch Basisberechtigungen für die Basisberechtigungen "Administrator", "Agent" und "Endbenutzer" hinzufügen und entfernen möchten, müssen Sie dies tun Das übliche Drei-Status-Flag in den Berechtigungsgruppen: Berechtigung hinzufügen, Berechtigung verweigern, Standardberechtigung und Berechtigungen entsprechend kombinieren.

(Als Hinweis sollte dies alles über etwas wie SSL oder sogar Zwei-Wege-SSL geschehen, wenn Sie sich Sorgen über die Sicherheit beider Enden des Gesprächs machen. Wenn Sie diese Token an einen Angreifer "weitergeben", ist er so, als ob er ' d ein Passwort geknackt.)

3
BenPen

Meiner Ansicht nach haben Sie hier zwei Möglichkeiten.

  • Wenn Sie nur konfigurierbaren Zugriff auf im Wesentlichen dieselbe Anwendung benötigen, lassen Sie die Dienste die Berechtigungen überprüfen und Ihren Kunden eine Schnittstelle geben, über die sie die für jede Rolle erteilten Berechtigungen ändern können. Auf diese Weise können die meisten Benutzer das Standard-Rollensetup verwenden, mit dem die "Problem" -Kunden die Rollen optimieren oder neue erstellen können, um sie ihren Anforderungen anzupassen.

  • Wenn Ihre Kunden ihre eigenen Anwendungen entwickeln, sollten sie ihre eigene Zwischen-API einführen. Dieser stellt eine Verbindung zu Ihrem Administrator her, überprüft jedoch die eingehende Anforderung anhand der eigenen benutzerdefinierten Authentifizierungsanforderungen, bevor Sie Ihre Dienste aufrufen

1
Ewan

Hier gibt es auch eine kurze Antwort. Sie sollten alle Core Funktionen implementieren, die Sie Ihren "Kunden" selbst anbieten möchten. Es scheint problematisch zu sein, dass Clients ein so grundlegendes Verhalten wie Benutzerberechtigungen selbst hinzufügen, da Sie bereits eine Benutzerauthentifizierung durchführen. Wenn Sie es dem Client überlassen, es zu implementieren, werden Sie möglicherweise mehrere Implementierungen desselben Berechtigungscodes "unterstützen". Auch wenn Sie es nicht "besitzen", wird es Fehler in ihrem Code geben und Sie möchten, dass Ihre Clients die Funktionalität haben, die sie erwartet haben, so dass Sie die Lösung der Probleme unterstützen, die ein Client hat. Die Unterstützung mehrerer Codebasen macht keinen Spaß.

1
BenPen

Sicherheitsüberlegung

Wenn ich Ihr Design gut verstehe, beabsichtigen Sie, einige Mechanismen zur Kontrolle des Ressourcenzugriffs an die Clientseite zu delegieren, d. H. Eine konsumierende App reduziert die Elemente, die ein Benutzer sehen kann. Ihre Annahme ist:

mikrodienste und ihr Autorisierungssystem sollten sich nicht mit den Bedürfnissen der Kunden befassen, da sie nur Verbraucher und nicht Teil des Systems sind

Ich sehe hier zwei ernsthafte Probleme für ernsthafte Geschäfte:

  • Was ist, wenn ein betrügerischer Benutzer da draußen (zum Beispiel in einem Werk Ihres Partners) die Client-App zurückentwickelt und sich über die API informiert, die Einschränkungen umgeht, die sein Unternehmen dem Kunden auferlegt hat, und diese Informationen verwendet, um Ihrem Unternehmen Schaden zuzufügen? Ihr Unternehmen wird Schadensersatz verlangen, aber das Partnerunternehmen wird argumentieren, dass Sie nicht die Mittel angegeben haben, um Ihre Daten ausreichend gut zu schützen.
  • Normalerweise ist es nur eine Frage der Zeit, ob vertrauliche Daten missbraucht werden (oder bei einer Prüfung wird das Risiko festgestellt), und Ihr Management wird am Ende nach einer genaueren Kontrolle dieser Daten fragen.

Aus diesem Grund würde ich empfehlen, solche Ereignisse zu antizipieren und Autorisierungsanfragen zu bearbeiten. Sie befinden sich in einer frühen Reengineering-Phase und es wird viel einfacher sein, diese in Ihrer Architektur zu berücksichtigen (auch wenn Sie nicht alle implementieren) als später.

Wenn Sie Ihre derzeitige Position weiter verfolgen, wenden Sie sich mindestens an Ihren Informationssicherheitsbeauftragten.

Wie man es implementiert

Du hast den Trick:

Auf diese Weise müssten wir nur Token-Bereiche verfolgen.

Ok, Sie beabsichtigen, einige vom Client ausgewählte allgemeine Token zu verwenden. Wieder eine Schwäche in meinem Auge, weil einige Kunden außerhalb Ihrer Kontrolle sein können.

Ich weiß nicht, ob Sie bereits JWT verwenden oder ob Sie andere Techniken verwenden. Wenn Sie jedoch JWT verwenden, verfügen Sie möglicherweise über ein Identitätstoken, das die Identität des Benutzers enthält (und sogar über ein zweites Token, das die ursprüngliche App sicher identifiziert, sodass Sie das Vertrauensniveau zwischen internen Clients und externen Clients unterscheiden können ).

Da Sie sich für eine Microservice-Architektur entscheiden, möchte ich vorschlagen, amke den Unterschied zwischen dem Benutzerverwaltungs- und Authentifizierungsprozess (der als dedizierter Dienst ausgeführt werden soll) und der Zugriffssteuerung (dh) spezifisch für jeden Mikrodienst und sollte von jedem lokal gehandhabt werden). Natürlich sollte ein Administrator-Client aus Gründen der Benutzerfreundlichkeit einen umfassenden Überblick über mehrere Dienste geben.

1
Christophe