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
Bonn im Wandel Joint-Venture
Ach, du meinst den SSO, den discourse mitbringt, mit google, facebook und twitter. Ok, ich dachte du meintest etwas, was @Sascha_Foerster -spezifisich ist 
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.
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.
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.
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.
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):
Das sehe ich ähnlich. Es ist schon eine ziemlich große Aufgabe und eine die auf keinen Fall scheitern sollte Im Zweifel lieber der klassische Weg.
@rjung Hast du zufällig Erfahrungen mit ldap oder sso Zeugs?
@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.
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…
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! 
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?
@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
2 Like
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:
1 Like
Spannend! +1 für ein Eckchen in der Technikecke
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.
So ganz auf die Schnelle wird das schwierig, aber vielleicht kommen wir schrittweise weiter. Wenn ich bei qdPM nachsehe, finde ich folgendes Screen-Shot der Konfigurationsmaske für die LDAP-Anbindung:
Einige Felder dort finde ich selbst auch nicht selbsterklärend, die msiten sollten wir aber in der Lage sein korrekt zu setzen. Kryptisch: “Use LDAP Login” und “Default Group”. Die erklären sich evtl. eher, wenn man nachschaut, wofür qdPM das LDAP verwendet.
Die anderen Felder legen fest, wie qdPM das LDAP abfragt:
LDAP Server Name: das wäre der Name, unter dem der LDAP-Server via TCP angesprochen werden soll. Könnte auch “localhost” sein, wenn auf der gleichen VM wie qdPM.
LDAP server port: Der TCP-Port auf den der Server horcht, im Default meist 389.
LDAP base DN: wird bei der Einrichtung des LDAP-Servers festgelegt. Das ist der Pfad zu dem Verzeichnisteil, in welches Du Deine User einträgst. Die Pfade sind hierarchisch aufgebaut. Im Beispiel “o=MyCompany, c=US” steht das c für Country, also das Land, in dem Deine Organisation beheimatet ist, das o steht für Organization, und oft gibt es drunter, also hier davor, noch ein ou=… für eine Organizational Unit, also eine Abteilung in der Organisation. Das DN steht für Distinguished Name. Ein Distinguished Name ist ein solcher Pfad im Vereichnis. Hier konkret ist es nicht der name eines Users, sondern der oberste Pfad unter dem irgandwo alle Deine user zu finden sein werden. Die Anwendung wird beim Suchen von Usern den gesamten Baum unterhalb des angegebenen DN durchsuchen.
LDAP uid: uid steht für User Identity. Hier wird aber gar keine user identity angegeben, sondern wie das Attribut im LDAP heißt, in welches Du die id einträgst, für die bei der Anmeldung der Eintrag im LDAP gesucht wird. Häufig wird dort wirklich “uid” einzutragen sein. Beispiel: Der User will sich mit dem Usernamen kurt anmelden, dann ist die Frage, in welches Attribut (Feld) Du das kurt bei der Useranlage im LDAP einträgst. Wie gesagt, meistens “uid”. Man kann das in LDAp alles ändern, aber das macht die Konfig der nutzenden Clients schwer. Deshalb hält man sich lieber erst mal an einfache Beispiele.
LDAP user filter: ein LDAP-Verzeichnis kann groß sein und evtl. gibt es dort ganz viele Objekte, die ein Attribut “uid” haben, aber gar keine user in Deinem Sinne sind. Deshalb kann man weitere Bedingungen (Filter-Ausdrücke) angeben, um die Suche einzugrenzen. Das Beispiel objectClass=posixGroup schränkt die Suche nach Objekten ein, die vom Typ posixGroup sind (also Gruppen-Einträge). Ich hätte allerdings eher objectClass=posixAccount erwartet. Bei einem einfachen Verzeichnis kannst Du das aber wohl erst mal leer lassen, also die Suche nicht weiter einschränken.
LDAP email attribute: hier geht es wieder nur darum, wie das Attribut heißt, in dem Du für die user deren email-Adresse im LDAP-Server eingetragen hast. Das qdPM holst sich dann wenn es einen user gefunden hat aus diesem Attribut (Feld) die Emailadresse des Users.
LDAP user dn: damit qdPM überhaupt einen User im LDAP-Server suchen kann muss es sich selbst am LDAP-Server anmelden. Man kann entweder zulassen, dass der LDAP-Server anonym durchsucht wird. Das ist unsicherer aber zunächst einmal einfahcer aufzusetzen. Ich würde das empfehlen um erst mal zu sehen, ob Du die anderen felder richtig hinbekommst. Das anonyme durchsuchen (anonymous bind) muss beim Konfigurieren des LDAP-Servers erlaubt werden. Soll qdPM das dann benutzen, bleibt “LDAP user dn” und “LDAP password” leer. Das anonymous bind erlaubt in der Regel nur die User-Suche, die Abfrage der wichtigsten Attribute der User und die Prüfung des Passworts. bei der Passwort-Prüfung ist wichtig zu wissen, dass es nicht um das Auslesen des Passworts aus dem LDAp-Server geht, sondern der Client (qdPM) schickt dem LDAP-Server das Passwort (was der User zum beispiel gerade eingetippt hat) zur Überprüfung, und der LDAP-Server sagt, ob es korrekt war oder nicht.
Die Alternative zum anonymous bind ist das Einrichten eines LDAP-Users für technischen Zugriff, also zum Bespiel ein LDAP-User qdpm, der diese rechte bekommt und den Du mit Seinem Passwort dann unter LDAP User dn und LDAP password einträgst. Dabei wird der User mit vollem dn=Distinguished Name eingetragen, also zum Beispiel “uid=qdpm,ou=Free Chicken,o=Save The World,st=Nordrhein Westfalia,c=DE”. Es muss halt der richtige Pfad zu diesem User-Objekt sein, also dorthin zeigen, wo Du es im LDAP-Baum angelegt hast. Weil das leicht schief gehen kann, vielleicht erst mal mit anonymous bind anfangen.
Ich höre jetzt erst mal auf, aber es kann natürlich auch sein, dass Du schon beim Anlegen des LDAp-Servers Schwierigkeiten hattest. Dann müsstest Du mal berichten, was das für ein LDAp-Server ist, und was Du schon getan hast.
Falls zugriff auf ldap nicht klappt, lohnt es in dessen Doku zu suchen, wie man das Logging geschwätzig machen kann. Dann sieht man, welche Anfragen ankommen und kann evtl. erkennen, was an diesen nicht richtig ist.
Viel Erfolg wünscht,
Rainer
1 Like
Danke dir für die Ausführung, LDAP bleibt erst einmal ein Projekt. Habe meine Forum Seite mit Oauth2 für twitter google und facebook erweitert. Das bringt etwas Komfort und funktioniert nach dem 2ten Anlauf dann jetzt auch.
Inzwischen kenne ich mich ein bisschen besser mit LDAP, ActiveDirectory und Co. aus. Aber vielleicht sollte der Fokus fürs Forum erstmal aufs Motivieren der Menschen liegen, sich überhaupt hier aktiv zu beteiligen, oder? 
@Andi: Ich habe mir erlaubt hier nach Monaten der Stille noch mal eure leeren Kategorien aufzuräumen. Ich bin und bleibe offen für Ideen, aber so richtig bewährt hat es sich bisher nicht, viele Kategorien anzulegen, die niemand nutzt. Daher gibt es aktuelle nur noch eine Bonn-im-Wandel-Kategorie, die ich vielleicht auch eher ins allgemeine Thema „Nachhaltigkeit“ umwidmen werde.
Hallo Sascha, ja gerne! Tatsächlich habe ich eine Weile lang ja mal versucht Menschen im Bonn im Wandel Umfeld für das bonn.community zu begeistern. Leider hat das nie wirklich Früchte getragen. Fühle dich frei alles so umzugestalten wie es dir sinnvoll erscheint. Wenn ich es zeitlich hinbekomme, schaue ich auch mal wieder rein und überlege was sinnvoll sein könnte. Vor allem wie du schon schreibst in Hinblick auf Menschen motivieren 
(Vor allem die als intern gedachten Kategorien sind damit obsolet denke ich. Ich bin mir grad nicht 100% sicher, ob es dort Dinge gibt, die ich selber aufräumen müsste…wenn du auf sowas stößt ping mich gerne an)
Hallo lieber Sascha und Andreas,
derzeit wollen viele neue und alte lokale Klimaschutz-Initiativen und Akteure der Nachhaltigkeit sich vernetzen, ihre Angebote untereinander bekannt machen. Es fällt ihnen jedoch schwer, sich auf eine gemeinsame digitale Kommunikationsplattform zu einigen, weil jede*r eigene Präferenzen hat.
Bonn.Community könnte da m.E. eine gute (Zwischen)Lösung sein. Man muss das Rad ja nicht neu erfinden. Bonn im Wandel arbeitet ja derzeit auch an einer übergreifenden online Plattform.
Am 6.12. gibt es ein Special GreenDrinks Mixer bei der X-mas Feier im Ökozentrum Bonn. Vielleicht könnte man dort auch auf Bonn.Community hinweisen. Ich bastel gerade an der GreenDrinks FB Einladung.
LG, Sandra
1 Like
HI @sprufer: ich habe auch noch mal geschaut, wie viele lokale Nachhaltigkeits-Initiativen Gruppen auf Facebook betreiben. Es sind so viele. Jetzt könnte man diskutieren, wie nachhaltig Facebook ist… Aber ich finde schon mal ein gutes Zeichen, dass die Plattform hier schon seit 4 Jahren fleißig ihren Dienst tut. Und die Tür steht offen für alle Initiativen, die ein lokales Forum brauchen.