infrastructure:services:keycloak
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
infrastructure:services:keycloak [2023-08-07 23:41 UTC] – max | infrastructure:services:keycloak [2024-11-04 21:05 UTC] (current) – [Nutzeraccounts] adapt for ID-invite self-service jtbx | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== CCCHH ID ====== | ====== CCCHH ID ====== | ||
---- dataentry service ---- | ---- dataentry service ---- | ||
- | service-urls_urls: | + | service-urls_urls |
- | other-service-fqdns: | + | other-service-fqdns |
- | host-fqdn: | + | host-fqdn |
- | netbox-link_url: | + | netbox-link_url |
- | server_page: | + | server_page |
- | maintainers: | + | maintainers |
+ | ccchh-id-integration_yesno : true | ||
---- | ---- | ||
+ | |||
+ | |||
+ | |||
+ | ===== Beschreibung ===== | ||
CCCHH ID ist unser SSO- und Account-System. Es ist realisiert durch eine [[https:// | CCCHH ID ist unser SSO- und Account-System. Es ist realisiert durch eine [[https:// | ||
So können wir jeder interessierten Person einen Account bieten, mit welchem diese dann je nach Rechtelevel all die verschiedenen Club-Services nutzen kann. | 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 ===== | + | ==== Nutzeraccounts ==== |
+ | |||
+ | Um einen Nutzeraccount zu bekommen, meldet euch bitte einfach im CCCHH Matrix-Channel (siehe [[club: | ||
- | Um einen Nutzeraccount zu bekommen, meldet euch bitte einfach | + | Alle Personen, die Teil der " |
+ | 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:// | Der eigene Account kann dann unter folgender URL verwaltet werden: [[https:// | ||
- | ===== Angebundene Services | + | ==== Angebundene Services ==== |
Zur Zeit sind folgende Services angebunden: | Zur Zeit sind folgende Services angebunden: | ||
- | * [[infrastructure: | + | ---- datatable ---- |
+ | headers : Service, Service-URLs, | ||
+ | cols : %pageid%, service-urls_urls, | ||
+ | filter | ||
+ | and : %pageid%!=infrastructure: | ||
+ | and : ccchh-id-integration_yesno==true | ||
+ | ---- | ||
+ | |||
+ | Weitere angebundene Services: | ||
* [[infrastructure: | * [[infrastructure: | ||
+ | * [[infrastructure: | ||
Folgenden Services sollen noch angebunden werden: | Folgenden Services sollen noch angebunden werden: | ||
* [[infrastructure: | * [[infrastructure: | ||
- | * [[https:// | + | * <del>[[https:// |
- | * Eine geplante Nextcloud | + | |
- | * Ein geplantes HedgeDoc | + | |
===== Konfiguration ===== | ===== Konfiguration ===== | ||
Line 36: | Line 52: | ||
Die einzelnen an Keycloak angebundenen Anwendungen heißen " | Die einzelnen an Keycloak angebundenen Anwendungen heißen " | ||
Alle Nutzeraccounts für die Club-Services liegen im " | Alle Nutzeraccounts für die Club-Services liegen im " | ||
- | |||
- | Da die verschiedenen Services (clients) unterschiedliche Rollen-/ Gruppen-Namen für dieselben Funktionalitäten verwenden könne, sollten für jeden Client unter " | ||
- | 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 " | Support für 2FA via WebAuthn wurde über einen selbst erstellten Authentication Flow namens " | ||
Line 45: | Line 58: | ||
Oder auch mit limitierten Rechten durch den eigenen Nutzer-Account unter folgender URL: [[https:// | Oder auch mit limitierten Rechten durch den eigenen Nutzer-Account unter folgender URL: [[https:// | ||
+ | |||
+ | ===== 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 " | ||
+ | |||
+ | Im Keycloak können dann Realm-weite Gruppen angelegt werden, die eine Reihe von Client-Roles enthalten. | ||
+ | |||
+ | Damit z. B. im Wiki eine Gruppe " | ||
+ | * Clients > wiki > Roles > " | ||
+ | * Groups > " | ||
+ | |||
+ | 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 " | ||
+ | |||
+ | 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 ==== | ==== DokuWiki ==== | ||
Line 63: | Line 91: | ||
Außerdem ist wichtig, dass Keycloak allen Usern die " | Außerdem ist wichtig, dass Keycloak allen Usern die " | ||
+ | |||
+ | ==== 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 '' | ||
+ | * The '' | ||
+ | * Same thing for groups like '' | ||
+ | |||
+ | 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 '' | ||
+ | |||
+ | === 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 '' | ||
+ | |||
+ | === RBAC einrichten === | ||
+ | |||
+ | Erstelle die '' | ||
+ | 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 ===== | ===== Admin How-To ===== | ||
==== Nutzeraccount anlegen ==== | ==== Nutzeraccount anlegen ==== | ||
- | - Auf https:// | + | - Auf https:// |
- Add user | - Add user | ||
* Required user actions: Update Password, Verify Email | * Required user actions: Update Password, Verify Email |
infrastructure/services/keycloak.1691451683.txt.gz · Last modified: 2023-08-07 23:41 UTC by max