Vom Monolith zu Microservices

[internet]

danke für die Antwort.
"Tobias" etc. muss ich nicht verstehen?

Ich möchte nun aber dennoch nochmal "Authentifizierung" und "Authorisierung" aufgreifen.
Mein Eindruck ist, dass wir hier größtenteils immer nur von Authentifizierung reden.

Authentifizierung
Ist mir denke ich nun klar geworden:
Ablauf wäre nun:
1) User geht auf die Anmeldeseite, die von Keycloak gehostet wird
2) Wenn Anmeldung erfolgreich ist, dann wird zu meiner Webapp weitergeleitet
3) Keyclaok stellt ein Token aus
4) Anmeldung in meine WebApp erfolgt mittels Pac4j und Apache Shiro (alles noch nicht getestet, aber ist wohl dafür implementiert worden)

Authorisierung
Wie schon mehrmals erwähnt, möchte ich meine ganzen Berechtigungen in meiner Webapp speichern (ich nutze Apache Shiro).
Also mehrere Tabellen, die neben den einzelnen Berechtigungen eben auch speichert welcher User welche Berechtigung hat

Und nun sind wir wieder am Punkt, was muss in der Datenbank gespeichert werden.
Mir ist nun immer noch nicht klar, wie ein Mapping von Keycloak zu meinen User in der Webapp geschehen soll.

Nach meinem Verständnis wäre es so:
1) Ich habe in meiner WebApp neben "Permission" auch eine Tabelle "User".
Dort steht eben eine eindeutige UserID, also i.d.R. die Emailadresse.

Um jetzt den Prozess der Authorisierung nochmal zu vervollständigen mit Keycloak:
1) Token kommen von Keycloak zurück
2) In dem Token steht auch die Emailadresse
3) Mittels der Emailadresse suche ich meinen User in meiner Webapp Datenbank
4) Ich lade die Berechtigungen für diesen User

Passt das so?

 

[KonradN]

"Tobias" etc. muss ich nicht verstehen?

Haha ... nein, musst Du nicht. Du musst Dir nur Popcorn und was zu trinken holen und die Show genießen. Aber die fachlichen Darstellungen haben aber hoffentlich eher zur Klärung als zur Verwirrung beigetragen. Ich habe ja versucht, auch sachliche Erwiderungen zu bringen.

Ich möchte nun aber dennoch nochmal "Authentifizierung" und "Authorisierung" aufgreifen.
Mein Eindruck ist, dass wir hier größtenteils immer nur von Authentifizierung reden.

Also das wird durchaus teilweise vermengt. Hintergrund ist, dass Keycloak und co oft schlicht für beides benutzt wird.

Die ganz wichtige Aufgabe ist natürlich Authentifizierung. Und es gibt eine Trennung er Domänen: Die Domäne Userverwaltung kennt nicht die Rollen der Domäne ERP.

Aber natürlich gibt es Dinge, die zusammen gehören. In der Userverwaltung ist z.B. bekannt, dass ein User zu HR gehört. ERP verwaltet auch Mitarbeiter des Unternehmens und da darf nur HR Änderungen vornehmen. An irgend einer Stelle muss also eine Art Mapping stattfinden.

Nach meiner Erfahrung ist das aber etwas, das in der Userverwaltung stattfindet. Du hast dann also in der Userverwaltung eine Zuordnung von Rechten wie: Es gibt eine Gruppe ERP_employee_management und in dieser Gruppe ist HR.
Eine Applikation selbst, die gegen die Userverwaltung arbeitet, wird dann diese Gruppe prüfen. (Hier wird von claim gesprochen, die Userverwaltung packt also in das Token noch zusätzliche Informationen ... diese claims.)


Wir haben damals mit den .Net Services sehr feine Unterteilungen:

• Bei der Entwicklung haben wir allem, was wir gemacht haben, ein Recht vergeben. Dann hatten wir halt employee_read, employee_create, employee_modify, employee_delete, ....
• Ein weiterer Schritt sah dann vor, dass diese einzelnen Rechte kombiniert wurden. Damit konnte man Dinge, die zusammen gehören, zusammen fassen. Wenn man ein Employee verändern will, dann braucht man z.B. auch das Recht, Abteilungen zu sehen und so.
• Und dann gab es die Schnittstelle nach außen. Es wurden Gruppen (Bei uns ging alles gegen das AD) die kombinierten Rechte zugestanden.

Das muss aber so nicht sein. Du kannst es auch auf der Applikationsebene halten. Aber damit verkomplizierst Du einiges. Du hast ein Gesamtsystem welches aus mehreren Teilsystemen besteht. Und da musst Du dann jeweils Rechte verwalten.

ich muss also die Verwaltung Deiner Anwendungen als Operator kennen. Denn ich bekomme jetzt plötzlich Anträge, dass ich einem Hr. Maier in jedem Teilsystem irgendwelche Rechte zuordnen soll.
Der Hr. Maier ist aber ein neuer User. Der hat einen Account im Keycloak aber hat sich natürlich noch nie angemeldet. Das bedeutet, dass die Verwaltung nicht nur auf der lokalen Datenbank arbeiten darf sondern hier auch auf Keycloak zurückgreifen muss. Das ist technisch natürlich möglich aber Du merkst die höhere Komplexität?


Zuletzt auch einen wichtigen Punkt aus der Praxis: Warum macht man das denn so überhaupt? Firmen haben oft ihre eigenen Identity Provider. Diese beinhalten auch Claims (Gruppen und so). Und sie haben ein Management für genau dieses identity Management aufgebaut. Es gibt also eine Verwaltung, die universell zuständig ist. Es git ein Verfahren, um einem User Claims hinzu zu fügen und zu nehmen.

Und wenn so eine Firma zu Dir kommt: Was wird die Firma besser finden:

• Die Firma kann ihr Identity Management voll einbringen. Du konfiguriert also in KeyCloak den Zugriff auf das Identity Management des Kunden. Und Du übernimmst claims und mappst diese auf neue Claims für Deine Anwendung.
• Die Firma muss mehrere Mitarbeiter auf Deine Anwendung schulen, damit diese dann dort die eigenen User managen können. Dann müssen neue Prozesse eingeführt werden, damit alle Mitarbeiter wissen, wie denn die Rechtevergabe funktioniert. Und es können vorhandene Gruppen direkt berechtigt werden, d.h. man muss Mitarbeiter nicht einzeln berechtigen!

Und was ist für ein Admin besser:

• Der Admin nutzt ein Tool, das bekannt ist. Es gibt Schulungen, andere Nutzer, ...
• Der Admin nutzt ein Tool, das Du für sinnvoll erachtet und selbst entwickelt hast.

Meine Erfahrungen in diversen Firmen ist halt, dass Standardprozesse super sind. Wenn Du da ankoppeln kannst, dann hast Du viel weniger Arbeit. Ebenso bei Tools. Microsoft hatte damals auch eine eigene API / Tools für das koppeln. Das war dann eine XML Datei. Die wurde dann bei der Integration einmal angepasst. Wir konnten die auch jederzeit weiter anpassen. Keycloak bietet so viel. Das kannst Du also direkt verwenden. Teilweise ist es aber auch sehr einfach zu ersetzen. Es gibt ja mehrere Lösungen und nicht nur Keycloak!


Also wenn man noch einmal kurz zurück blickt:
Ja, du hast da zwei Themen, die getrennt zu betrachten sind und die auch sehr gut getrennt werden können (und sollen).
Ein Tool wie Keycloak kann für beides verwendet werden. Aber natürlich gibt es auch Tools, bei denen du es vermutlich immer trennen musst (Weil Du keine Kontrolle über den identity Provider hast - Du nutzt z.B. Facebook. Da bekommst Du nur schwer Claims rein )

Du kannst es so machen, wie Du es beschrieben hast. Hier ist es aus meiner Sicht wichtig, wirklich die Use cases zu betrachten und zu überlegen, wie sieht die Bedienung aus? Ist es für die Anwender eine positive Sache? Ist es das, was die Kunden wollen?

3) Mittels der Emailadresse suche ich meinen User in meiner Webapp Datenbank

Zu dem Punkt evtl. noch der Hinweis: die Emailadresse ist keine unveränderliche id. Nutze wirklich die id des Users. Bei Keycloak hast du im sub Claim die unveränderliche id des users. Wenn aus der Frau Schmidt also die Frau Müller wird, dann ändern sich Name und Email-Adresse aber sie möchte doch bestimmt ihre Daten und ihren Zugriff behalten. Aber auch hier ganz klar: Hier rede ich von einem Use Case. Ob der ein Rolle spielt oder ob es andere, wichtigere Use Cases gibt, die eben genau deinen Punkt erfordern: Das ist etwas, das Ihr wissen müsst. Technisch ist das, was du geschrieben hast, auch möglich.

 

[KonradN]

Evtl. noch einfach zwei Dinge:

a) Ganz einfach ausgedrückt geht es einfach um die konkreten Anforderungen. Die kennen wir nicht. Deine Anforderungen können also tatsächlich so sein, dass Deine Überlegungen ganz genau richtig sind.

b) Ein Beispiel für so ein Tool fällt mir gerade ein: Gitea. Du setzt Gitea für die Firma auf. Anmeldung erfolgt per openid-connect zu dem Identity Provider der Firma. Rechte laufen aber in keiner Weise darüber! Ein User hat einfach seinen Account mit Standard Rechten. Der Identity Provider hat nur die Aufgabe, die User zu authentifizieren. Alle weiteren Rechte kommen aus der Anwendung (Halt die Rechte die man da so kennt. Eigene Repositories erstellen und so. Wenn er Admin eines Repositories ist, dann kann er andere User hinzufügen oder User entfernen.... All sowas halt.) Bezüglich der Rechte hat der Identity Provider kein Mitspracherecht.

(ich habe mich hier also von meinen eigenen Vorstellungen eines ERP Systems leiten lassen. Die können aber selbstverständlich komplett falsch gewesen sein. Was ich an Anforderungen sehe, mag bei Dir keine Rolle spielen.)