@jensp hat bereits den Open-LDAP aufgesetzt und baut gerade Self-Services
@meike.jung merkt an, das man aus Datenschutzgründen ggf. Mitglieder und Anmeldedaten trennen sollte
@luckow hat sich schon Gedanken gemacht wie man die verschiedenen Accounts zusammenführt
@contao-kirsten merkt an, das man dem LDAP nicht als führendes System verwenden sollte
Meine Idee wäre:
Eine DB auf Basis der die Benutzer und Mitglieder verwaltet werden (z.B. Benutzerverwaltung des CMS) darin gibt es verschiedene Benutzergruppen und ggf. Berechtigungen → daraus wird der LDAP dann provisioniert.
Alternativ könnte z.B. LUI zum Einsatz kommen: didmos LUI - DAASI International
Oder das Open-Source IdM midpoint (für unseren fall auch einfach einzurichten)
Vorteil das ganzen wäre, das wir später ggf. auch nen IdP aufsetzen könnten
Weitere Diskussionspunkte:
Sollen die Gruppen aus dem LDAP in allen angeschlossenen Anwendungen zur Verfügung stehen?
Ansonsten würde ich das ganze gerne so simple wie möglich aufsetzen. Daher sehe ich im Moment keinen Vorteil noch eine Datenbank dazwischen zu schalten. Und was mir noch wichtig wäre das alle beteiligten Komponenten - auch das Frontend - freie Software sind. Viel Funktionalität brauchen wir so weit ich das sehe nicht: Wir müssen Benutzer und Gruppen verwalten können, User-Informationen müssen sich per E-Mail verschicken lassen und wir brauchen die Möglichkeit sein Passwort zu ändern oder ein neues anzufordern, wenn seines mal vergessen hat.
Vorname, Nachname, Kontaktdaten müssen sich auch aktualisieren lassen
Darüber hinaus brauchen wir nach DSGVO eine Möglichkeit das ganze zu Exportieren.
Privilegierte Nutzer_in müssen Berechtigungen vergeben bzw. entziehen können. Berechtigungen müssen auf Zeit vergeben werden können (Mit ggf. Nachweis wer und wann/warum) das gemacht wurde.
Wir können davon ausgehen, dass wir bald die Personendaten in unseren CRM halten und pflegen werden.
Von dort aus sollten diese dann gerne exportiert werden können.
Dies spräche für den Ansatz von Kirsten, bzw könnte man unter Umständen um ein separates UI herum kommen, wenn man die Gruppen dort auch verwaltet.
Ich mache mir dazu mal Gedanken.
Wenn die Pflege über das CRM erfolgen kann wäre das sehr hilfreich. Allerdings müssen wir auch im Blick behalten, dass wir zum einen einen Möglichkeit zum Ändern des eigenen Passworts anbieten müssen. Das Passwort im LDAP liegen, damit die Anwendungen was damit anfangen können.
Zusätzlich zum LDAP müssen für die Gruppen auch noch einmal extra z.B. mit Redmine abgleichen da Redmine keine Gruppen aus dem LDAP auslesen kann. Nextcloud dagegen kann das. Aber wenn wir jetzt uns Gedanken zu einer solchen Struktur machen, sollten wir das gleich so konzipieren dass wir den User/Gruppen-Abgleich auch erweitern können wenn weitere Anwendungen dazu kommen.
Dazu gibt es verschiedene Ansätze, einmal einen LDAP-Baum (von dem ich persönlich abrate) wo die Struktur des CMS-Garden abgebildet wird und die Berechtigungen in MemberOf gepflegt werden. Oder verschiedene OUs für die angeschlossenen Systeme, wo nur die jeweiligen Attribute gepflegt werden.
cn=Kirsten Roschanski,ou=XXX,o=CMS Garden,c=de
memberOf: Telefonkonferenz
memberOf: Developer
Oder
ou=Telefonkonferenz,o=CMS Garden,c=de
cn=Kirsten Roschanski
ou=Developer,ou=Redmine,o=CMS Garden,c=de
cn=Kirsten Roschanski
Beim zweiten sind zwar Accounts/Personen mehrfach im LDAP, wenn man nicht mit Overlays arbeitet, jedoch ist die Verwaltung der Berechtigungen im LDAP-Config einfacher, da jedes System seinen eigenen Baum hat und nur die Attribute und Nutzer sehen kann die auch dafür Zugriff haben sollen/zugestimmt haben.
Schön das wir so viel Wissen hier zusammen bekommen 
.
Eine Idee noch, wir könnten die Nutzerdaten im CRM Pflegen, die Passwörter würde ich aber dann dort nicht erfassen. Da die nutzer normaler Weise nicht zwingend einen auch alle einen Zugang zum CRM haben werden. Aber es wäre gut wenn wir da ein mapping der Nutzernamen (ID’s) vorsehen können.
Denn manche Nutzer sollen dann im CRM schon arbeiten können und da wäre es toll, wenn die auch übers LDAP laufen würden. Aber das ist erst mal nice to have, wenn es alles zu aufwendig macht, dann können wir mit separaten Nutzern im CRM leben, da die Nutzeranzahl dort nicht so groß sein wird.
Generell sollten wir bedenken, wir reden hier insgesamt noch nicht von riesigen Nutzerzahlen, so dass sich oft eine einfachere Lösugn mit etwas manuellem Aufwand als besser geeignet herausstellt ;).
Ich würde jedoch schon vorsehen, das jede Person seine Daten in einem gewissen Umfang selbst ändern kann, denn nur die Person selbst weiß wo sie z.B. aktuell zu erreichen ist.
Klar macht es weniger Aufwand jetzt einen LDAP-Browser zu nehmen und die Daten schnell manuell rein zu geben. Aber wenn der Verein schnell wächst, ist das eine Baustelle, die dann sehr schnell kommt. Daher würde ich hier gleich eine richtige Lösung implentieren wollen, die einfach zu pflegen und schnell zu erweitern ist, damit wir für die Zukunft gerüstet sind, wer weiß ob wir nach der Wikipedia-Veröffentlichung nicht 30.000 Mitglieder haben 
Ein paar initiale Benutzer im LDAP könnte ich über einen LDAP Client, z.B. Apache Directory Studio, einpflegen.
Was interessant wäre: Welche Wege gäbe es, um an die Daten im CRM zu kommen? Es gibt theoretisch verschiedene Möglichkeiten: Entweder das CRM exportiert regelmäßig die Mitglieder in eine Datei die man dann per Skript abholt und abarbeitet. Oder es gibt eine REST-API, die ein Skript aufrufen kann.
Ein Frontend mit “nur” die Benutzer ihr Passwort ändern können, sollte nicht so schwierig zu implementieren sein. Ein initiales Passwort könnte das Skript ja setzen und verschicken sobald ein neuer Account im LDAP angelegt wird.
Den LDAP-Baum würde ich möglichst einfach halten und dort auch nur die Daten speichern die für die Authentifizierung und die Zuordnung auf Gruppen/Rollen in den Anwendungen notwendig sind. Für Anwendungen, die keine Gruppen aus dem Redmine lesen können müsste das Skript die entsprechenden Gruppen dann auch anlegen. Ob man die Gruppen wirklich mit ins LDAP packt sollten wir aber noch mal diskutieren.
Sinnvollerweise sollten auch Stephan, Kati etc. noch mal ihre Wünsche in die Runde werfen.
Ich stimme @contao-kirsten zu, die Nutzer sollten ihre Daten selbst aktuell halten können.
Die Frage ist also, wo wir am Ende die Nutzerdaten primär halten.
Aktuell würde ich da eigentlich die Website (drupal) sehen, da sich dort die meisten der Nutzerregistrieren und Ihre Daten schon aus eigenem Interesse aktuell halten solten.
@meike.jung @nullbyte wie ist denn der Plan mit der neuen Website?
Haben wir dort auch wieder Mitglieder in einem Verzeichnis und werden die Daten dann dort gehalten?
Oder soll dies inklusive der Datenpflege ausgelagert werden? Schöner wärs ja wenn das über die website laufen würde. Man könnte die Daten dann von dort ins CRM exportieren. LDAP kann ja jedes CMS sicherlich zumindestens für das Passwort ändern direkt oder? Passwortänderungen sind Zeitkritisch alles andere kann über export/import oder API’s gelöst werden.
Alles schlaue und wichtige Hinweise in der Diskussion. Können wir das irgendwie auf Anforderungslisten zusammendampfen, damit es etwas übersichtlicher wird?
Außerdem halte ich es für wichtig, dass wir den Begriff “Mitgliederverwaltung” streichen, um Missverständniss zu vermeiden. Die Mitgliederverwaltung ist eine Vorstandsaufgabe, die bei der Datenhoheit/Stammdatenpflege natürlich eine Rolle spielt, aber nicht in eine Gesamtlösung integriert werden sollte. Bei der Mitgliederverwaltung spielen ja auch noch Formalakte wie Beitritt und Austritt sowie der Zahlungsverkehr eine Rolle.
@MrTango Website-Relaunch ist in der Mache.
Um mich mal aus der Anforderungsrichtung ranzutasten …
(P = beteiligte Person; V = Vorstand):
-
Stammdatenpflege
Unterscheidung nach: Useraccount-Zugangsdaten und allgemeinen Kontaktdaten.
P sollte Änderungen nicht an mehreren Stellen pflegen müssen, denkt aber bei einem Umzug auch nicht automatisch an den Verein (regelmäßige Erinnerung/Abfrage erforderlich). -
Mitgliederverwaltung
Vorstandsaufgaben: Aufnahmeanträge annehmen, Aktualisierungen auf Mitteilung vornehmen, Austritte bestätigen, Mitgliedsbeitragszahlungen managen. -
Tools
Single-sign-on wünschenswert. Eventuell Berechtigungsgruppen zentral steuern (in Diskussion). Basisinformationen zu P über alle Systeme hinweg synchron halten.- CRM (in Evaluation: Odoo - Anforderungsanalyse im Redmine-Wiki)
- Projektmanagement-Tool (aktuell Redmine)
- Cloudspeicher (aktuell Nextcloud)
- Diskussionsforum (aktuell dieses hier)
- Chat (aktuell keiner)
- Newsletter-Tool (aktuell Newsletter2Go)
- OpenSpacer (Barcamp-Organisation)
- Website (Relaunch in Arbeit - momentan der einzige Ort, an dem P Daten selbst Account beantragen + Stammdaten einstellen können)
-
LDAP - sehe ich in diesem Zusammenhang als Brückentechnologie, nicht als Tool. Wir sollten klären, was die Synchronisierung minimum können muss und die nice-to-haves davon abgrenzen.