Bonn im Wandel Joint-Venture


#1

Hallo ihr,
ich habe mich letzte Woche mit Sascha zusammen gesetzt und wir haben überlegt, wie und an welchen Stellen wir im Sinne einer IT des Wandels kooperieren können. Dabei war eine Möglichkeit diese tolle Discourse Instanz. Konkret haben wir Bedarf an internen Email-Listen und da bietet discourse ja einige Möglichkeiten. Zunächst würde ich in den kommenden Wochen mal ein paar Tests laufen lassen, die ungefähr so aussehen würden:

  • Testgruppe 1: 2 oder 3 Accounts von mir
  • Testgruppe 2: Bonn im Wandel Kerngruppe (7 Personen)
  • Testgruppe 3: Projektgruppe mit ca 30 Personen

Wobei Gruppe 3 schon sehr in den Produktiveinsatz gehen würde. An der Stelle sollten wir uns, finde ich, nochmal genauer unterhalten, z.B. darüber wie wir diese Plattform mittragen können. Es gibt Projektgelder, sodass da in den nächsten 1,5-2 Jahren eine finanzielle Beteiligung möglich wäre. Das wäre uns schon allein deshalb wichtig, weil die Tools, die wir für das Projekt nutzen auch zumindest für die Projektlaufzeit vorhanden sein sollten. Wünschenswert wäre natürlich ein Betrieb darüber hinaus und eine Verstetigung unseres Beitrags.
Bei all dem geht es uns primär um die interne Gruppenkommunikation. Was darüber hinaus im öffentlichen Bereich passiert, wäre für uns erstmal keine Priorität.
Was denkt ihr dazu?
Viele Grüße,
Andi


#2

Hi @Andi. Wie Du merkst ist es hier sehr ruhig geworden. 130 angemeldet User, aber nur zwei waren letzte Woche aktiv. Aber wenn das hier noch mal inhaltlich interessanter wird, dann passiert auch wieder mehr.
Ich musste technisch noch mal ein paar neue Grundlagen legen. Der alte E-Mail-Server, den wir genutzt haben, wird auf kurz oder lang abgeschaltet, insofern habe ich gleich noch mal alles auf Langfristigkeit eingerichtet. Dazu wird jetzt der E-Mail-Server von Bonn.digital genutzt, den er hat die erforderlichen Einträge: DKIM, PTR, DMARC und was man sonst so braucht, damit man nicht als Spammer auf irgendwelche Blacklisten landet, sobald man mehr als 3 E-Mails am Tag verschickt. Die alte Adresse @bonn.community habe ich deswegen eingestellt, weil ich sonst für jede Domain und jeden Webserver dahinter noch mal den gleichen Aufwand betreiben müsste.
Übers Geld können wir gerne mal reden, wenn der Server aufgrund der Last zusammenbricht, ansonsten ist das hier eine Community-Dienstleistung, die wir gerne erbringen. Mir macht ja genau so wie Dir das technische Spaß, aber was nutzt es, wenn nachher keiner aktiv was damit anfangen kann. #Relevanz
So, also, dann testen wir mal fleißig mit der Gruppe 1.


#3

Ok, dann sag nur Bescheid, wenn ihr anfangt unsere Daten zu verkaufen oder Werbung zu schalten :wink: Ne, im Ernst: Wir suchen nach besseren Kommunikationsmöglichkeiten die wir auch langfristig nutzen können und das IT Budget von Bonn im Wandel wird hoffentlich größer in Zukunft. Und momentan geht es primär um die interne Kommunikation in nicht-öffentlichen Gruppen, das wollte ich nur klar kommunizieren. Das von den Velowerft Leuten die Plattform dann auch mal für öffentliche Diskussionen nutzen, könnte auch mal passieren. Kann aber auch sein, dass sich überhaupt niemand mal einloggt und alle nur die Mailing-Listen Funktion nutzen.
Ich werde dann mal schauen, wie da ein möglicher Workflow aussehen kann. Ende März ist der nächste Velowerft Workshop, da werde ich dann bonn.community vorstellen und einen konkreten Vorschlag für die Nutzung machen. Ich bin sehr gespannt und bedanke mich schonmal für die Unterstützung!


#4

@Michael_Thomas_Bauer: Danke für deine Likes :slight_smile: Dadurch ist mir aufgefallen, dass einige Kategorien öffentlich waren, die es nicht sein sollten. Waren nur zum testen, aber die sollten eigentlich nicht unter Aktuelles auftauchen. Also nicht wundern, wenn die gerade verschwunden sind!


#5

Geht klar, danke für die Info.


#6

Das Thema “IT- des Wandels” interessiert mich auch sehr, ich habe aus Regensburg das auch so mitgeteilt bekommen. Deren Ansicht ist, dass ernst gemeinter Aktivismus nicht ohne auskommt. So gesehen trennt sich darüber der Weg. Das sollte im Vorfeld klar sein. Leider regnet es Abneigung das um zu setzen. Wie auch immer man die Arbeit konstruieren will, oder Kommunikation aufstellen muss. IT bringt deutlich den Schlüssel mit, auch an einen Erfolg glauben zu können. Das Thema “Wandel” ist “peng” da. Es lohnt nicht mit alten Zöpfen und Ansichten zu hantieren. Effektiv muss es sein. Sonst kann keine Zeit gut gemacht werden, was dringend nötig ist. Ein Umsetzen in der Kollaboration kann nicht bedeuten, wieder nur Papier und Visionen an den Tag zu legen. @Sascha_Foerster setzt mit SSO auf ein schnelles Pferd. Das bringt die Bequemlichkeit in der Anwendung, die der User wünscht. Wie gesagt, " der Anwender ist nicht interessiert am Backoffice, es muss für ihn nur reibungslos funktionieren."


#7

Ich denke das Thema ist sehr facettenreich. Zum einen ist es wichtig Leute zu sensibilisieren und die vielen, äußerst komplexen Themen runterzubrechen auf ein verständliches Niveau, gerade im Bereich Datenschutz. Dann ist die Frage, um wen geht es. Momentan besteht “meine Testgruppe” erstmal aus Leute, die in Initiativen aktiv sind. Da gibt es einen konkreten Bedarf, eine gewisse Sensibilisierung ist bereits vorhanden und es sind überschaubar große Gruppen, was es ermöglicht ehrenamtlich einen Prozess zu begleiten und verschiedene Tools und Abläufe auszuprobieren. Ich finde es da immer wichtig, schnell möglichst konkret zu werden.
Was meinst du denn mit “SSO”?


#8

das beschreibt einen Vorgang, der “eine Anmeldung” für mehrere miteinander kommunizierenden Plattformen beschreibt. So braucht der User nur einen zentral verwalteten Login und kann dann über alle Maschinen umher arbeiten. https://de.wikipedia.org/wiki/Single_Sign-on


#9

Ach, du meinst den SSO, den discourse mitbringt, mit google, facebook und twitter. Ok, ich dachte du meintest etwas, was @Sascha_Foerster -spezifisich ist :wink: Discourse ist grandios, ja! SSO ist für mich relativ uninteressant solange es nur die “großen 3” zur Auswahl gibt. In der Schweiz arbeiten Menschen an Transition Connect, das einen selbstbestimmten Datenaustausch zwischen verschiedenen selbstverwalteten System ermöglichen soll. Das ist nicht unbedingt SSO (weiß ich nicht genau), aber geht in die Richtung denke ich.


#10

ne, das geht weiter. @Sascha_Foerster hat da eine Vorstellung die er besser selber vorbringt. Ich denke es macht Sinn für @bonndigital wenn als lokaler Anbieter diese Funktion auch auf dem onlineAngebot implementiert ist.


#11

Hi! Naja, Single-Sign-On, dahinter steckt für mich die Idee, dass es einen Login zur gesamten Bonn.digital-Plattform gibt. Fände ich natürlich sehr cool, aber das ist noch hundert Jahre entfernt von der Realisierung. Ich beobachte aber auch da, welche Tools es gibt. Momentan experimentiere ich etwas mit LDAP, aber das wird gleich so komplex und bei Logins ist ja auch nicht zu Spaßen.
Ich würde sagen, dass Thema kommt direkt nach dem Aufbau von Geschäftsmodellen, falls man sich mal eine/n Entwickler leisten kann, dann darf der das umsetzen. :wink:
Auf der anderen Seite dachte ich dann auch: ein Login bedeutet auch wieder, dass man über alle Plattformen hinweg sehr viel über diese Person hinter dem Login erfahren kann. Da ist es vielleicht doch besser, alles getrennt zu lassen.


#12

Tja, und kaum bin ich viel zu spät am surfen, finde ich auch schon was passendes:
https://lemonldap-ng.org/documentation/presentation

Gefunden habe ich das in dieser Übersicht von OpenSource-Tools, die in Frankreich offiziell in der Verwaltung genutzt werden dürfen (so habe ich das grob verstanden):


#13

Das sehe ich ähnlich. Es ist schon eine ziemlich große Aufgabe und eine die auf keinen Fall scheitern sollte :wink: Im Zweifel lieber der klassische Weg.
@rjung Hast du zufällig Erfahrungen mit ldap oder sso Zeugs?


#14

@Andi Ein wenig Erfahrung. LDAP ist zunächst mal ein Verzeichnis-Dienst (Lightweight Directory Access Protocol, also eigentlich ein Protokoll, aber meistens meint man mit LDAP einen LDAP-Server, der das Protokoll implementiert). LDAP hat die positive Eigenschaft, dass ausreichend große Teile des Protokolls standardisiert sind und damit LDAP-Clients und LDAP-Server unabhängig voneinander entwickelt werden können und in der Regel gut zusammen arbeiten. Der klassiche Open Source LDAP-Server ist OpenLDAP, es gibt auch Apache Directoy Server und natürlich auch kommerzielle Produkte. Auch der Microsoft Active Directory Server beinhaltet im Kern einen LDAP-Server (aber noch viel mehr).
LDAP verwaltet zum Beispiel User, Passwörter und Rollen. LDAP hat erst mal nicht direkt etwas mit SSO zu tun sondern ist eine mögliche Quelle gegen die Anwendungen User athentisieren und autorisieren können. Bei SSO geht es aber darum, eine Schicht drüber zu legen mit der Anwendungen nicht mehr selbst die User authentisieren, sondern einer schon stattgefundenen Autzentisierung vertrauen, d.h. ein Login statt viele. Da gibt es aber keine Magie, sondern die Möglichkeit SSO zu machen hängt von den einzelnen Anwendungen ab. Klassisches SSO findet in einer IT-Landschaft mit zentraler Userverwaltung (dann meist in LDAP) statt. Außerdem wird das in solchen Landschaften häufiger mit Kerberos ergänzt, ein Ticket-basiertes Autorisierungssystem.
Geht es um dezentrale Systeme (Mashup etc.) kommt gerne der Begriff “federated” ins Spiel, siehe etwa https://en.wikipedia.org/wiki/Federated_identity. Als ein technischer Ansatz dann OAuth.
Obwohl da heute schon vieles existiert ist es am Ende ziemliche Bastelarbeit.
Übrigens folgt aus Single-Sign-On nicht sofort Single-Sign-out. Häufig ist es einfacher die Logis zu koordinieren, als die Logouts. Greift man nach dem zentralen Login auf eine ins SSO integrierte Anwendung zu, muss die halt in dem Moment den Login erben, getriggert durch den Zugriff. Macht man aber ein logout, erfahren davon die einzelnen Anwendungen erst mal nichts. Und der zentrale Logout weiß nicht, mit welchen Anwendungen man gearbeitet hatte und wo er den Logout sonst noch hinschicken soll.
Na gut, genug schwarz gesehen. Insgesamt gibt es da etluiche Ansätze aber keine Auto-Magie. Man muss schon konkreter festlegen, was man alles in das SSO reinpacken will.


#15

Und zu lemonldap-ng nur mein Eindruck von der ersten Webseite: die sagen es ist ein WebSSO. D.h. das System schränkt sich zunächst auf Anwendungen ein, di eman mit HTTP(S) benutzt. Außerdem sieht es zunächst nach einem System für eine zentral gemanagte Infrastruktur aus, also nicht Schwerpunkt federated. Allerdings ist da auch von OpenID die Rede (den Begriff hatte ich oben noch vergessen), was wiederum in Richtung federated geht. Wenn ich es recht verstehe, ist es aber ein Identity provider, d.h. das Identity Management in dem System wir auch von draußen zur Authentisierung abfragbar gemacht. Möchte man also dieses System für SSO verwenden und auch andere Web-Anwendungen in das SSO anbinden, müssen diese Anwendungen breit sein dem OpenID-Provider im Lemon-System zu vertrauen. So, jetzt höre ich mal auf zu texten…


#16

Ich glaube, das Wichtigste habe ich verstanden, @rjung: Wenn ich mal mit jemandem gepflegt zum Thema LDAP, SSO, OpenIP und Co. fachsimpeln und ganz viel lernen möchte, dann weiß ich jetzt, mit wem das geht! :slight_smile:
Machst Du sowas auch beruflich? Und hättest Du Lust das noch was weiter zu diskutieren?
Und ich suche gerade eine gut passende Kategorie für das Thema: vielleicht:
https://bonn.community/c/Bonn-digital und später mache ich noch mal was IT-lastiges als Unterkategorie auf?


#17

@Sascha_Foerster Ja, ich mache IT beruflich und dabei Schwerpunkt Web-Infrastrukturen und Analyse von Performance-Problemen. Allerdings bin ich relativ spezialisiert, Webserver Apache und Tomcat (bei den beiden bin ich Projektmitglied), bei Analyse von Performance-Problemen allgemein Web- und Java-Umfeld. Bei mir wehen aber ab und zu Mal auch Fragestellungen aus dem Umfeld vorbei, wie etwa SSO. Da hat sich in den letzten 20 Jahren was angesammelt. Du kannst mich ruhig anpingen, wenn es mir zu viel wird, versuche ich es zu sagen :wink:


#18

Und guck, jeden Tag gibt es was neues zu dem Thema. Vielleicht müssen wir uns mal eine Technik-Ecke hier suchen, wo wir über SSO und Login-Technologie unterhalten können:


#19

Spannend! +1 für ein Eckchen in der Technikecke :slight_smile:


#20

Hi, ich baue auch für “Euskirchen” an ein paar Lösungen. LDAP ist eine vertrackte Kiste für mich, ich habe einen LDAP Server laufen , kann den auch “ansprechen” und Inhalt schreiben. Wenn ich den z.B. mit qdPM verbinden möchte komme ich nicht weiter. Hast du " so aus der Ferne" eine Idee oder ein HowTo das mich weiter bringen könnte. Ich baue mir auch gerne eine neue Spiellandschaft auf, wenn es mich weiter bringt.

Wie ich sehe hat die Site jetzt auch OAuth-2.0, ich kleiner “Einzelkämpfer” komme da nicht hinterher.