KeyCloak-Anbindung ins Backend einbauen

[rowe42]

Die von Barrakuda generierten MS bekommen derzeit ein Token, das vom eigenentwickelten Auth-Server kommt. Es ist zu prüfen, inwieweit hier Anpassungen vorzunehmen sind, wenn stattdessen KeyCloak angebunden wird.

Zudem wird die Autorisierung ebenfalls (und offenbar bei jedem Zugriff auf den MS) vom User-Endpoint des Auth-Servers geholt. Wir wollen das mit dem KeyCloak ja etwas anders machen (Entitlements-API von KeyCloak verwenden, Permissions beim ersten Zugriff des Users holen und cachen), was man exemplarisch ins Backend einbauen muss und dann auch mit in die Generierung übernehmen muss.

Es stellt sich architekturell die Frage, ob alle MS den KeyCloak direkt per Entitlements-API aufrufen (über das authorisationLib.jar, das ich schon erstellt habe), oder über einen neu zu erstellenden User-MS, der als eine Art Proxy zum KeyCloak fungiert. Insbesondere vor dem Hintergrund, dass wir vom Frontend aus ebenfalls Zugriff auf die Permissions des aktuellen Users brauchen (da möchte ich aber auch die authorisationLib verwenden und nicht das gleiche nochmal in JS nachbauen).

[rowe42]

@xdoo zum Einbau von Keycloak ins backend muss ich Änderungen an der service-lib machen. Kannst du dafür ein eigenes Repo anlegen?
Oder soll ich noch den Umzug ins interne Gitlab abwarten, @Baumfrosch?
Alternativ könnte es auch ein privates Repo im Github sein...

[rowe42]

Habe das jetzt so gelöst, dass ich die überbleibenden Klassen aus der service-lib direkt nach animad-admin-service übernommen habe und die Referenz auf service-lib entfernt habe. Brauchst mir also kein neues Repo mehr anlegen.

[rowe42]

Wurde in Branch _#156 eingecheckt und nach master gemerged.
Alle Backend-Services (api-gateway, admin-service, user-service) lassen sich jetzt sowohl

• standardmäßig mit KeyCloak Anbindung
• oder über Spring-Profile "no-security" ohne KeyCloak Anbindung
  ausführen.

Schließe das Issue.