search

rowe42 / lhm_animad_admin_html5

0 stars 6 forks source link

KeyCloak-Setup dokumentieren #90

Closed rowe42 closed 6 years ago

rowe42 commented 6 years ago

Es ist noch in Diskussion wie KeyCloak genau genutzt werden soll sprich:

Das muss an geeigneter Stelle (im internen Wiki) auch noch dokumentiert werden.

DirkGern commented 6 years ago

Aus meiner Sicht hatten wir doch schon einiges diskutiert. Mein Verständnis ist: zu 1) Für jede Anwendung gibt es einen Realen. zu 2) Die Rollen und Rechte werden im Projekt definiert und implementiert. Das sollte nicht über die Oberfläche, sondern via API erfolgen der Testbarkeit wegen. Die Pflege der Benutzer und deren Zuordnung zu Rollen darf ein Fach-Admin über die Pflegeoberfläche. zu 3) Da hatten wir uns doch auf einen Workflow geeinigt. Namen vergessen. Fall noch offene Fragen, bitte neuen Issue, @rowe zu 4) Darüber haben wir nicht diskutiert, bitte neuen Issue, @rowe

rowe42 commented 6 years ago

Es ist richtig, dass wir einiges davon schon besprochen haben. Es ist aber noch nicht sauber dokumentiert, und (auch) dafür ist dieser Issue.

Ich habe zu dem Thema außerdem nochmal mit den Security-ITAs und dem zukünftigen KV von KeyCloak diskutiert. Dabei wurde die Idee noch etwas verändert / konkretisiert. Würde ich gerne im nächsten AG-Meeting mit euch diskutieren. Aufgeschrieben habe ich es im internen Wiki hier: ...Java-Architektur/index.php/KeyCloak_Setup.

Im Detail: Zu 1) Der Vorschlag ist nun, doch nur einen Realm für alle Anwendungen zu verwenden. Bei mehreren Realms müsste die Konfiguration, die für alle gleich ist (z.B. der AD-Resolver) mehrmals dupliziert konfiguriert (und bei Änderungen mehrmals angepasst) werden. Und da die fachlichen Admins nun nicht mehr direkt mit KeyCloak arbeiten sollen, ist eine Rechte-Abtrennung zwischen den Realms auf Oberfläche nicht mehr so wichtig (und ließe sich sonst auch auf Client-Ebene erreichen). zu 2) Die Benutzer werden wie bereits heute im AD durch die entsprechenden Verantwortlichen eingerichtet und gepflegt. Die Rollen werden in Form von Gruppen im AD angelegt und den Benutzern zugewiesen. Das können die Fach-Admins in den Referaten bereits heute. Neu ist das Mapping AD-Gruppen->KeyCloak-Rollen->KeyCloak-Permissions (i.e. Rechte). Dieses wird vom Entwickler über die KeyCloak-Oberfläche in der Entwicklungsumgebung konfiguriert und kann dann per Import/Export auf die anderen KeyCloak-Umgebungen übertragen werden. Für die Frage, wie die Permissions initial nach Keycloak kommen, habe ich den separaten Issue #124 angelegt. zu 3) Idealerweise (wenn wir es hinbekommen) verwenden wir den Authorization Code Flow. Das ist der sicherste Flow, der sich aber nur für Server-seitige Applikationen einsetzen lässt. Es müssen aber in dem Zusammenhang noch ein paar Details festgelegt werden, eben z.B. welche Lebenszeit der Access Token haben darf. zu 4) Habe hierfür wie gewünscht einen neuen Issue eröffnet: #125

rowe42 commented 6 years ago

Dokumentation findet sich im Wiki in Artikel KeyCloak_Setup.