KeyCloak: Anlage von Permissions

[rowe42]

Es muss beschlossen werden, wie im KeyCloak Permissions gepflegt werden.

Optionen:

1. Der Entwickler macht das von Hand während der Entwicklung.
2. Die Microservices bekommen einen Mechanismus, mit dem sie beim Hochfahren ihre Permissions über die Permissions-API automatisch an KeyCloak melden.

Ursprünglich hatte ich 2) favorisiert, aber das birgt das Problem, dass die Rollen-Permissions-Zuordnung erst erfolgen könnte, sobald die Microservices in der jeweiligen Umgebung erstmalig hochgefahren sind. Das passt wahrscheinlich nicht zum Rollout-Vorgang, bei dem man ja auch vorgefertige Rollen per Import einspielen möchte. Außerdem gibt es komplexe Fragestellungen, z.B. was passiert, wenn zeitweilig unterschiedliche Versionen von Microservices hochgefahren werden (bei einem Upgrade), die sich in den Permissions unterscheiden.

Ich plädiere deshalb für 1), da das - insbesondere zwecks schnellerem Vorankommen - natürlich auch einfacher umzusetzen ist. Nachteil ist natürlich, dass die Permissions, die in den Microservices verdrahtet sind zu den Permissions passen müssen, die in KeyCloak hinterlegt sind und dies vom Entwickler sicherzustellen ist.

Was meint ihr? @xdoo @dragonfly28 @Baumfrosch @ejcsid

[DirkGern]

Ich kann deiner Argumentation folgen, @rowe42.
Mir ist dann wichtig, dass die Permissions als Skript oder Datei vorliegen und mit dem Code eingecheckt werden, damit sie mitgetestet werden.

[xdoo]

Aktuell machen wir das so, dass diese Permissions einfach als SQL Datei generiert werden. Die Müssen dann von Hand übertragen werden (da können natürlich Fehler entstehen), aber die Dateien an sich sind immer korrekt.

[rowe42]

Ok. Der ganze Autorisationsbereich im Keycloak lässt sich ex und importieren, und das sollte auch der Weg sein wie die security Konfiguration von C nach K und P transportiert wird.

[DirkGern]

KeyCloak hat ein REST-API, das wir nutzen, oder? Nicht mit SQL in die DB.

[rowe42]

Ja gibt es. Aber wie gesagt : ich bin dafür dass der Entwickler das während der Entwicklung in seinem Realm/Client im C System über die keycloak Oberfläche konfiguriert und regelmäßig exportiert und eincheckt. Und dann wenn es soweit ist wird die Datei in K eingespielt.

[xdoo]

Ob man jetzt eine SQL Datei generiert, oder eine Liste von CURL Befehlen bleibt sich gleich. Was ich eigentlich sagen wollte: Ich würde es generieren lassen.

[rowe42]

Was meinst du damit? Durch Barrakuda? Kann man machen. Sollte dann eben gerade das Import Format von keycloak (JSON) heraus kommen. Und sollte durch den Entwickler von Hand oder über Keycloak Oberfläche erweitert oder verändert werden können.

[xdoo]

Genau.

[DirkGern]

Dann ein CURL-Skript, denn einen direkten Zugriff auf die KeyCloak-DB wird I31 zurecht nicht akzeptieren.

[rowe42]

Ich habe nun die für das animad-Beispiel notwendigen Permissions in einem lokalen KeyCloak von Hand angelegt und die dabei entstandene Datei im internen Wiki als Datei Keycloak-config.zip hochgeladen und in Seite KeyCloak_Setup verlink.

Darin enthalten ist Datei openIdDemo-authz-config.json, die dann zukünftig durch Barrakuda zu generieren ist - wie genau ist noch zu disktuieren: es ist z.B. die Frage, ob Rollen auch mit generiert werden und wenn ja welche (im Beispiel: admin und readonly).

Diese Datei kann dann über die KeyCloak-Oberfläche in einen bestehenden KeyCloak-Client eingespielt werden.

Damit ist für mich der Issue erstmal für Milestone 1 gelöst. Wie das dann über CURL möglich ist und ob wir das überhaupt wollen, sollten wir in einem separaten Issue für Milestone 2 diskutieren (#170).