Table of Contents
CCCHH ID
- service-urls:
- https://id.hamburg.ccc.de/, https://keycloak-admin.hamburg.ccc.de/
- host-fqdn:
- keycloak.hamburg.ccc.de
- server:
- Chaosknoten
- maintainer:
- june, Infra-Team
- ccchh-id-integration:
- true
Beschreibung
CCCHH ID ist unser SSO- und Account-System. Es ist realisiert durch eine Keycloak-Instanz. So können wir jeder interessierten Person einen Account bieten, mit welchem diese dann je nach Rechtelevel all die verschiedenen Club-Services nutzen kann.
Nutzeraccounts
Um einen Nutzeraccount zu bekommen, meldet euch bitte einfach im CCCHH Matrix-Channel (siehe Matrix-Chatraum und Space) oder fragt vor Ort, ob ein Wesen euch mit einem Wesen des Infra-Teams in Kontakt bringen kann.
Der eigene Account kann dann unter folgender URL verwaltet werden: https://id.hamburg.ccc.de/realms/ccchh/account/
Angebundene Services
Zur Zeit sind folgende Services angebunden:
↓ Service | Service-URLs | Host-FQDN | Server |
---|---|---|---|
Cloud | https://cloud.hamburg.ccc.de/ | cloud-intern.hamburg.ccc.de | Chaosknoten |
DokuWiki | https://wiki.hamburg.ccc.de | wiki-intern.hamburg.ccc.de | Chaosknoten |
eh22-wiki | http://eh22.easterhegg.eu | eh22-wiki-intern.hamburg.ccc.de | Chaosknoten |
Git | https://git.hamburg.ccc.de/ | git.hamburg.ccc.de | Chaosknoten |
Grafana | https://grafana.hamburg.ccc.de | grafana-intern.hamburg.ccc.de | Chaosknoten |
Pad | https://pad.hamburg.ccc.de | pad-intern.hamburg.ccc.de | Chaosknoten |
invite | https://invite.hamburg.ccc.de | @@Host-FQDN@|@ | Chaosknoten |
CCCHH ID | https://id.hamburg.ccc.de/, https://keycloak-admin.hamburg.ccc.de/ | keycloak.hamburg.ccc.de | Chaosknoten |
Proxmox-Backup-Server | https://proxmox-backup-server.ccchh.net:8007/ | proxmox-backup-server.z9.ccchh.net | ThinkCCCluster |
zammad | https://zammad.hamburg.ccc.de | zammad-intern | Chaosknoten |
Weitere angebundene Services:
- ThinkCCCluster (Gruppen werden aber nicht aus dem Keycloak übernommen, sondern müssen im PVE manuell zugewiesen werden. )
- Chaosknoten (gleiches Gruppen-Problem wie beim ThinkCCCluster)
Folgenden Services sollen noch angebunden werden:
Unser GitLabGitlab soll so bald wie möglich stillgelegt werden; Forgejo ist die Zukunft.
Konfiguration
Die einzelnen an Keycloak angebundenen Anwendungen heißen “clients”, die Nutzeraccounts sind “user”. Alle Nutzeraccounts für die Club-Services liegen im “ccchh” realm.
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 diese Doku zu Rate gezogen.
Keycloak-Konfiguration kann entweder über den Admin-User selbst vorgenommen werden unter folgender URL: https://keycloak-admin.hamburg.ccc.de/admin/master/console/
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
Damit die Gruppen korrekt ins Dokuwiki übertragen werden, muss in den Keycloak Client-Settings unter “Client Scopes” → “$client-dedicated” ein neuer Mapper angelegt werden:
- Add Mapper: By Configuration: “User Client Role”
- Name: wiki-groups
- Client ID: Select the wiki client
- Multivalued: On
- Token Claim Name: groups
- Claim JSON Type: String
- Add to ID token: yes
- Add to access token: yes
- Add to userinfo: yes
In Dokuwiki muss noch die Option “plugin»oauth»overwrite-groups” aktiviert werden, damit Dokuwiki-Gruppen auch wieder entfernt werden.
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.
Das heißt wir haben für jeden Client eine client-allow
und client-deny
role, sowie einen entsprechenden Authentication Flow, welcher nach dem default login check auch überprüft, ob der User auch die client-allow
und client-deny
role hat. Sollte der User die client-allow
role nicht besitzen, wird access denied. Sollte der User die client-deny
role besitzen, wird auch access denied.
RBAC einrichten
Erstelle die client-allow
und client-deny
roles bei dem entsprechenden Client.
Dupliziere dann einen webauthn browser client auth flow (z.B.: webauthn browser cloud auth). Hier solltest du dann folgende Schritte durchführen:
- Passe Name und Description an
- Passe login sub-flow Namen an
- Passe forms sub-flow Namen an
- Passe Browser - Conditional OTP sub-flow Namen an
- Passe rbac allowlist Namen an
- Passe rbac allow Condition - user role config Namen und role an
- Passe rbac allow Deny access an
- Passe rbac denylist Namen an
- Passe rbac denylist Condition - user role config Namen und role an
- Passe rbac denylist Deny access an
Admin How-To
Nutzeraccount anlegen
- Auf https://keycloak-admin.hamburg.ccc.de/admin/ccchh/console/#/ccchh/users aus dem Club-Netz anmelden
- Add user
- Required user actions: Update Password, Verify Email
- Ggf. zur “intern”-Gruppe hinzufügen
- Unter “User Details” auf “Credentials” einen Credential Reset auslösen
- Reset Actions: Update Password, Verify Email
- Expires In: 2 days