|
|
* #59 Payment Einbinden der Quota Limit in KC/LDAP und Anbindung an ownCloud / Dovecot / GroupOffice / Sandstorm/ ISPConfig |
|
|
\ No newline at end of file |
|
|
* Mit Roland wurde beschlossen, das wir vorerst keine volles GO Repository anlegen wollen. Stattdessen wollen wir ein GO Repostitory anlegen mit dem
|
|
|
|
|
|
* #59 Payment Einbinden der Quota Limit in KC/LDAP und Anbindung an ownCloud / Dovecot / GroupOffice / Sandstorm/ ISPConfig
|
|
|
|
|
|
* Für GroupOffice wird füe user wirklich der Kernknoten verwendet
|
|
|
* Gruppen app groupoffice groupoffice-groups
|
|
|
|
|
|
* Ticket für Armin
|
|
|
* für user und groupen filter im GO
|
|
|
* User und Gruppen Verwaltung deaktivieren
|
|
|
* Read-Only LDAP Access (rancher ggfs umbenennen)
|
|
|
|
|
|
* Drupalanbindung
|
|
|
* fairkom: Drupal
|
|
|
* faircoop: DA Alexandra
|
|
|
* faircoin: DA Alexandra
|
|
|
|
|
|
* Gruppenproblematik:
|
|
|
Wir wollen Gruppen so anlegen und verwalten wie KeyCloak diese auch verwalten kann. Da KC nur eine strikte Baum-Hierachie unterstützt, können wir nicht Gruppen für GroupOffice in einer dedizierten Gruppe zusammen fassen. Eine Gruppe kann im LDAP auch nur in einem OU-Knoten zugeordnet sein. Auch wenn per LDAP der selbe Gruppen Name in unterschiedlichen Hierarchie Knoten verwendet werden könnte, sind das letztendlich im LDAP unterschiedliche Gruppen. Im KeyCloak wird jedoch der Gruppen Name bzw. sein Pfand in der Baum Hierarchie als eindeutiges Merkmal verwendet und die OU-Hierarchie wird ignoriert. Damit wir die Gruppen Anwendungsspezifisch also im GroupOffice selektieren können, werden wir wohl ein anderes Attribut benötigen. Somit ist derzeit weder KC noch ein LDAP Browser ein optimales Frontend. Es wird wohl noch eine Verwaltungs-GUI nörtig sein, die aber die Gruppen und Berechtigungsstrukturen von KeyCloak berücksichtigt. |