Differences

This shows you the differences between two versions of the page.

--- infrastructure:services:keycloak [2024-01-28 23:38 UTC] – [Data entry] June -> june june
+++ infrastructure:services:keycloak [2024-11-04 21:05 UTC] (current) – [Nutzeraccounts] adapt for ID-invite self-service jtbx
@@ Line 19: / Line 19: @@
 ==== Nutzeraccounts ====
-Um einen Nutzeraccount zu bekommen, meldet euch bitte einfach im CCCHH IRC- bzw. Matrix-Channel.
+Um einen Nutzeraccount zu bekommen, meldet euch bitte einfach im CCCHH Matrix-Channel (siehe [[club:willkommen#matrix-chatraum_und_-space|Matrix-Chatraum und Space]]) oder fragt vor Ort nach Mitgliedern oder Personen aus dem Infra-Team.
+Alle Personen, die Teil der "intern"-Gruppe im Keyloak sind können unter https://invite.hamburg.ccc.de eine Account-Einladung verschicken.
+Weitere Gruppenzuordnungen müssen dann jedoch immer noch von Personen aus dem Infra-Team gemacht werden.
 Der eigene Account kann dann unter folgender URL verwaltet werden: [[https://id.hamburg.ccc.de/realms/ccchh/account/]]
@@ Line 28: / Line 31: @@
 ---- datatable ----
-headers : Service, Service-URLs, Host-FQND, Server
+headers : Service, Service-URLs, Host-FQDN, Server
 cols    : %pageid%, service-urls_urls, host-fqdn, server_page
 filter  : %class%=service
@@ Line 43: / Line 46: @@
   * [[infrastructure:services:netbox|NetBox]]
-  * [[https://gitlab.hamburg.ccc.de|Unser GitLab]]
+  * <del>[[https://gitlab.hamburg.ccc.de|Unser GitLab]]</del> Gitlab soll so bald wie möglich stillgelegt werden; Forgejo ist die Zukunft.
 ===== Konfiguration =====
@@ Line 49: / Line 52: @@
 Die einzelnen an Keycloak angebundenen Anwendungen heißen "clients", die Nutzeraccounts sind "user".
 Alle Nutzeraccounts für die Club-Services liegen im "ccchh" realm.
-Da die verschiedenen Services (clients) unterschiedliche Rollen-/ Gruppen-Namen für dieselben Funktionalitäten verwenden könne, sollten für jeden Client unter "Clients -> $client -> Roles" eingerichtet werden.
-Im Keycloak können dann Real-weite Gruppen angelegt werden, die eine Reihe von Client-Roles enthalten.
 Support für 2FA via WebAuthn wurde über einen selbst erstellten Authentication Flow namens "webauthn browser" realisiert. Dieser ist eine angepasste Kopie des built-in browser flow mit WebAuthn Support. Hierzu wurde [[https://www.keycloak.org/docs/latest/server_admin/index.html#webauthn_server_administration_guide|diese Doku]] zu Rate gezogen.
@@ Line 58: / Line 58: @@
 Oder auch mit limitierten Rechten durch den eigenen Nutzer-Account unter folgender URL: [[https://keycloak-admin.hamburg.ccc.de/admin/ccchh/console/]]
+===== Gruppen und Rollen =====
+Da die verschiedenen Services (clients) unterschiedliche Rollen-/ Gruppen-Namen für dieselben Funktionalitäten verwenden können, sollten für jeden Client unter "Clients -> $client -> Roles" eingerichtet werden. wir haben die Clients in der Regel so konfiguriert, dass der Namen der Rolle einer Gruppe im Client entspricht, also z. B. im DokuWiki wird aus der Keycloak-Rolle "hackertours" die Gruppe "hackertours".
+Im Keycloak können dann Realm-weite Gruppen angelegt werden, die eine Reihe von Client-Roles enthalten.
+Damit z. B. im Wiki eine Gruppe "foo" für die Berechtigung zur Verfügung steht, müssen in Keycloak diese Objekte konfiguriert werden:
+  * Clients > wiki > Roles > "foo"
+  * Groups > "foo" > Role Mapping > "wiki foo"
+Etwas verwirrend: wenn man in der Gruppe ein Role Mapping hinzufügen möchte, sieht man die Client-spezifischen Rollen zunächst nicht. Man muss nach Klick auf "Assign Roles" die Option "Filter by Clients" auswählen, dann gibt's die richtige Liste.
+Durch diesen Mechanismus ist es möglich, von einer Gruppe in Keycloak auf verschiedene Gruppennamen in den unterschiedlichen Clients zu mappen. Wir versuchen aber, die Gruppennamen konsistenz über alle Services zu halten.
 ==== DokuWiki ====
@@ Line 76: / Line 91: @@
 Außerdem ist wichtig, dass Keycloak allen Usern die "user"-Gruppe vom Dokuwiki zuweist.
+==== Permission & Configuration Structure ====
+THIS IS THE DESIRED STATE AND NOT HOW IT WORKS IN PRACTICE YET.
+This section tries to give insight into how the groups, roles, client roles and attributes work to form a  permission and configuration structure for our realm and its clients.
+=== Groups ===
+Groups act like profiles, which one can apply to users.
+Example:
+  * The ''user'' group should give access to all the clients and resources all users should have access to.
+  * The ''intern'' group on the other hand should give further access to clients and resources, only internal members should have access to.
+  * Same thing for groups like ''freifunk'', ''admin'' and so on.
+Important to note here is that the groups themselves aren't used directly for access to clients/to grant permissions in any client. The group just holds the relevant client roles and attributes for granting access to clients/to grant permissions in any clients. \\
+This way of having the groups act like general profiles, but having the actual configuration of permissions achieved using client roles, decouples them both nicely. \\
+This then allows for special use cases like the wiki user for example, which isn't in any group, but still has access to certain clients and resources through manual assignment of client roles.
+=== Roles ===
+We don't make use of roles, since they are mostly the same as groups it seems. Further configuration beyond groups is achieved using client roles and attributes.
+=== Client Roles ===
+Client roles are used to configure client-specific user permissions.
+Example: There exists a ''(wiki) intern'' client role, which then gets mapped to the wikis ''intern'' group. Users, who have this role assigned in Keycloak are then automatically part of the wikis ''intern'' group and can access the relevant resources.
+=== Attributes ===
+ToDo
 ==== RBAC ====
+NEEDS REVISION
 Für alle nicht-Keycloak-internen Clients haben wir nun auch Role Based Access Control.