zu moodle
da hab ich gestern das ldapsync plus plugin entdeckt.
Das provisioniert die User aus LDAP, es lässt sich da aber bei den neu provisionierten Usern eine alternative LoginMethode einstellen (SAML, oidc,…)
Dann wird also LDAP nur dazugenutzt alle User zu synchronisieren und die globalen Gruppen zu erstellen. Der Login geht dann über die dort ausgewählte Methode.
Man muss also keine REST API mehr programmieren um sowwas zu können.
Als LoginMethode empfehle ich da das OIDC Plugin im Zusammenspiel mit keycloak (was stark an MS Anbindungen geprägt ist). Da funktioniert der Logout nämlich sehr gut.
LDAP Login ist aber dann parallel nicht mehr möglich, anders wie beim oauth2 plugin. (Aber das braucht man dann auch nicht mehr)
cool, danke für die Rückmeldung.
SSO login & logout klappt mittlerweile auch einwandfrei mit dem auth_saml2 plugin (kann sein, dass das bereits core feature ist wie auth_ldap).
Als ich das gefixt bekommen habe konnte ich den ersten Beitrag mit der Tabelle nicht mehr aktualisieren und habe dann den neuen Beitrag vergessen
Wir haben bei allen Diensten den Login ausschließlich via SSO/Keycloak, sodass bei Moodle kein anderer Login möglich ist; es wird direkt zur Login-Maske weitergeleitet. Login via LDAP bzw direkt via Moodle-Maske wäre security nicht so schick.
Leider läuft zum Schuljahresbeginn noch der LDAP sync via auth_ldap, damit man nicht warten muss, bis sich jeder user zum ersten mal bzw. zum neuen Schuljahr neu eingeloggt hat, damit die gruppe/klasse aktualisiert wird. Das auth_saml2 hat da leider nix eingebaut und das via API zu machen hatte ich bisher keine Zeit.
Funktioniert, aber tatsächlich fühlt sich das leider nicht als vorzeigbare Variante an, ebenso fühle ich die Variante via LDAP server (Sync Plus) nicht, von dem LDAP Kram will man ja mit zeitgemäßem IdaM via OIDC o SAML2 eigentlich weg. .
Hi.
Ohne jetzt nochmal alles von oben bis unten lesen zu müssen: Wie ist das mit bestehenden User-Accounts, wenn man umstellt? Bleibt das alles so erhalten wie es war? Es ändert sich also lediglich der Anmeldeprozess und alles andere bleibt wie es vorher war?
(für mich in Sachen moodle und Nextcloud entscheidend).
Danke nochmal,
Michael
P.S.: Keycloak ist offensichtlich kein Selbstläufer. Da wäre eine FoBi oder ein Workshop beim nächsten Treffen (z.B. in Essen → Linuxhotel) eine gute Sache, oder? Ich habe gesehen, dass die auch ganz offizielle Fortbildungen zum Thema Keycloak im Angebot haben
ja, du kannst das SSO via SAML2 parallel zum bisherigen Login/Account laufen lassen.
Auf der Login Seite von Moodle hat man dann einfach eine zusätzlichen Anmelde-Button, der ans SSO weiterleitet.
In den Einstellungen gibts entsprechende Möglichkeiten zur Anpassung /admin/settings.php?section=authsettingsaml2
Einmal der „Dual Login“
Solltest dann aber das Erstellen via SSO vll deaktivieren, kann sein, dass der LDAP sync dann einen Konflikt bekommt, weil es den User dann bereits via SAML2 gibt. Ggf. testen…
Hallo.
Ich habe in einer Testinstallation (moodle 5.2.x) das Plugin „auth_saml2 plugin“ installiert und aktiviert. Danach habe in den SAML2-Settings unter moodle zunächst das Feld „IdP metadata xml“ mit den Einstellungen gefüttert, die bei keycloak angezeigt werden (wurde so von moodle akzeptiert).
Wenn ich danach die moodle-5-Startseite aufrufe, sehe ich aber trotzdem nur den normalen Login und nicht den Button „Login via SAML2“, der nun ja eigentlich zusätzlich erscheinen sollte, oder?
Kann das ein Problem mit dem aktuellen moodle5-Theme sein oder fehlt hier noch eine andere Einstellung? Wie gesagt: Aktiviert ist SAML2 unter Plugins → Authentifizierung bereits und der Debug-Mode ist in den Einstellungen ebenfalls aktiviert:
Dennoch erscheint diese Meldung, wenn ich in der Übersicht auf „Einstungen prüfen“ klicke:
Authentifizierungseinstellungen prüfen - SAML2
In order to use this test, plugin needs to be configured,
enabled and debugging mode should be enabled in plugin settings.
Danke nochmal für einen Tipp, @Tobi vielleicht?
Michael
Ja, bei BBB ist das dort – aber SAML2 steht unter „Authentifizierung“. Ich wüsste nicht, wie / wo ich das Plugin sonst noch aktivieren sollte. Ein paar Screenshots:
Aber auf der Startseite / Anmeldeseite ist nichts davon zu sehen …
Ok – man muss das Zertifikat auf der SAML2-Seite erneuern und (vermutlich) auch alle Caches löschen (moodle). Danach erscheint die neue Anmeldung auch auf der Startseite:
Die Weiterleitung zum edulution-Keycloak funktioniert dann zwar - aber weiter geht es leider nicht: "Es ist ein Fehler aufgetreten. Ungültiger Request."
Ich habe die XML-Dateien von moodle bei keycloak als SAML-Client importiert. Sollte doch eigentlich so passen?
mal in den logs nach genauere Fehlermeldung schauen?
ist bissel raten. üngültig könnte halt cert oder mapping oder sonstwas sein
so als idee: schau mal ob du überhaupt ein gültiges zetifikat in moodle fü saml2 angelegt hast. https://<moodledomain>/auth/saml2/cert.php das ist in moodle etwas sehr unübersichtlich…
Auf der Konfigurationsseite https://<moodledomain>/admin/settings.php?section=authsettingsaml2
war das etwas seltsam, weil er anfangs kein zert hatte,
dann hatte ich da (1) ein key hinterlegt das (2) neu erzeugt gespeichert. dann die Konfigurationsseite neu geladen (sonst war noch das alte zert drinnen.. ggf. caches löschen…) dann (3) die .xml mit den Metadaten für Keycloak heruntergeladen.
Die musste man dann in keycloak hochladen und danach dann die IdP metadaa xml aus keycloak in moodle kopieren.
Hi.
Ich habe das gerade nochmal probiert: Die XML-Datei moodle bei Keycloak importiert und die IdP-Settings von Keycloak bei Moodle hinterlegt.
Es geht wieder einen Schritt weiter – aber ganz will es noch nicht funktionieren:
Mein Username existiert bereits im System, da ich mich zuvor schon mal per LDAP angemeldet habe. Wenn ich nun die neue SAML2-Methode wähle, kann ich mich zwar anmelden, doch dann erscheint die moodle-Fehlermeldung:
Anmeldefehler
Sie haben sich erfolgreich als '<mein-Login>' angemeldet, sind aber nicht berechtigt, auf Moodle zuzugreifen.
In den Einstellungen des SAML2-Plugins habe ich beide Einstellungen bzgl
Nutzer/innen automatisch erstellen : Ja / Nein
(auth_saml2 | autocreate Standard: Nein)
ausprobiert. Ändert aber leider nichts.
Erst als ich nochmal Deinen Screenshot oben
genauer beachtet habe und die Einstellung in meinem Profil von LDAP auf SAML2 umgestellt habe, ging es. Das bringt natürlich gleich die nächste Frage mit sich: Kann man das in einem Rutsch für alle User (nachträglich) ändern?
Vermutlich ist es nun nur noch eine Kleinigkeit?
Ach ja: Dann war da noch die Sache mit dem Mapper unter Keycloak. Ich habe ein paar Attribute gegenseitig zugeordnet; bin aber nicht sicher, ob es damit getan ist.
Und noch etwas: Ich habe (nachdem ich ChatGPT auch bzgl der Fehlermeldung gefragt hatte) die folgende Einstellung für den SAML-Client unter Keycloak vorgenommen: „Encrypt assertions“ ausgeschaltet.
(Zusätzliche Infos dazu (von ChatGPT generiert – ohne Anspruch auf Richtigkeit):
"Eine kleine Anmerkung zu deinem Setup: Da du die Metadaten sauber in beide Richtungen importiert hast, würde ich die Verschlüsselung zunächst deaktiviert lassen. Für eine interne Moodle-/Keycloak-Installation hinter HTTPS ist die Kombination
HTTPS Transportverschlüsselung
SAML Assertion Signierung
in der Praxis sehr häufig ausreichend.
Die Verschlüsselung bringt bei SAML zusätzliche Komplexität (Zertifikatsmanagement, Schlüsselrotation, Plugin-Kompatibilität), ohne dass sie in vielen Umgebungen einen großen Zusatznutzen bringt.)"
Vielleicht hast Du ja noch einen guten Tipp.
Viele Grüße,
Michael
hab nen tipp
die authentifzierungsmethode kannst du in einem rutsch über einen datenbank befehl machen. damit migrierst du alle bestehenden accounts…
wenn du die accounts aber weiterhin mit ldap importieren lässt… hilft das für neue accounts nicht bzw müsstest du die db änderung wiederholt täglich machen.
alternativ kannst du das ldap modul wechsel zu ldapsync plus… da lässt sich dann für neue accounts eine andere authenfizerungsmethode einstellen irgendwo…
oder dir reicht aus dass die accoutns aus keycloak heraus on the fly entstehen.. was meist für die schule ja net so toll ist weil man ja mit vollen klassen arbeiten will
den db befehl findest du sicher per ki..
hier ist eine alte quelle…
ich weiss ncith mehr genau wo ich das damals gefunden habe.. https://moodle.org/mod/forum/discuss.php?d=244403
Ich hab’s gerade gefunden … steht auch bereits oben … ich hatte es bisher nur nicht verstanden: Man muss die Einstellung
Beliebiger Authentifizierungstyp zulässig:
(auth_saml2 | anyauth, Standard: Nein)
auf JA einstellen
Danach wird auch ein Profil akzeptiert, das bereits vorhanden ist, aber bei dem zuvor „LDAP-Server“ stand. Nun klappt die Anmeldung also wie gewünscht über SAML2.
Aber trotzdem Danke für’s Mitdenken, @sucher. Ich hatte etwas ähnliches auch gerade gesucht und dann einen SQL-Befehl erhalten, der alle Profile der User geändet hätte UPDATE mdl_user SET auth = 'saml2' WHERE auth = 'ldap';
Das habe ich aber nicht durchgeführt, weil es so natürlich viel einfacher geht.
Nachtrag:
Es bleibt aber ein ganz generelles Problem bzw eine Frage diesbezüglich:
Ob die Anmeldung nun über LDAP oder keycloak läuft, ist zunächst vielleicht gar nicht so entscheidend. Wichtiger wäre es ja, dass man (wie schon mal von @thoschi vorgeschlagen) eine komplette Strukur für alle Kurse inkl Oberstufenkurse/Gruppen/Zugehörigkeiten an nur einer Stelle anlegen oder importieren kann und diese Struktur dann auf allen Plattformen weiter verwenden kann?
das ist super pauschal. nach meinem verstaendnis gibt es einerseits nicht „die eine struktur“ die man für alle abbilden kann. andererseits sind ja alle „plattformen“ unterschiedlich und sind meistens ja nicht unbedingt auf den bereich „schule“ fixiert.
ein idp ist für authentifizierung und autorisierung von users zuständig. die kann man bissel in gruppen verschachteln und dann mit attributen schön nach standardprotokollen ldap, oidc, saml2, … an dienste übergeben, wenn sie die gleiche sprache sprechen… das wars erstmal.
was du meinst sind ja irgendwelche dienstspezifischen synchronisationsskripte, die optimalerweise eine vorhandene api der jeweiligen dienste ansprechen um deinem verstaednis entsprechend eine struktur in abhängigkeit deiner userstruktur anzulegen. ich vermute die meisten schulen sind tatsächlich mit manuell anlegen besser bedient, da niemand diese skripte a anlegen will und b warten/updaten (muss man ja mit den änderungen der dienste / api auch anpassen… manuelles wird meistens mit der datenbank einfach upgegraded und bleibt erhalten) will.
das gehört hier nicht in den thread rein.
Hi.
Ok, dann hier nur als Link: Es war weiter oben in Beitrag 6:
Aber es geht eben leider wie Du sagst nicht pauschal. Also ggf demnächst in einem neuen Thread weiter…
Noch eine Anmerkung zu dem, was ganz oben im allerersten Beitrag steht:
Das kann ich so bestätigen und es ist auch mit moodle v5.2 immernoch so: Der User bleibt einfach angemeldet, wenn man bei Keycloak eine Session abmeldet.
Ja eine Source of Truth zu haben… ist ein gutes Ziel.. aber das haben wir…
Der CSV Import findet in den AD statt… ich wüsste nicht wieso du das anders machen wollen würdest… und von daher ist eigelich klar dass alle user und gruppen daten immer auf dem lml server prio1 haben und alle andere platformen sich es davon auf irgendeinen weg ziehen… und wenns ueber den umweg keycloak geht ist es ja auch recht… aber soweit ich das bei den meisten platformen kenne werden accounts bei oidc logins immer on the fly kreiert und nicht alle auf einmal…
Zum moodle logout… das kommt ein bissle daruf an welches plugin man nimmt. offensichtlich ist der login nicht mit dem saml plugin implementiert.
ohne externe plugin koennte man auch das oauth2 modul nehmen und so den login ermoeglichen. aber auch hier ist meines wissen, stand 2026 der logout nicht implementiert. es gibt aber einen code vorschlag der schon ziemlich alt ist und von release zu release verschoben wird… ekiena hnung weiso die moodle leute eine moderne authenfizierung nicht als hoehere prio einstufen.
was es dann auch noch gibt als dritte variante das ms365 oidc plugin… mit dem geht der logout.. aber da steht ms365 drauf was mich aber nciht weiter juckt, weil es ja tortzdem opensource ist das plugin…
Zur Logout Problematik:
Unser neues Moodle wird hinter einem reverse Proxy (Traefik) sein, da kann man Moodle hinter dem SSO-Login „verstecken“ und dann die logout route (https://<moodledomain>/login/logout.php?sesskey=<key>) auf den Logout des IdP umleiten. Wenn man das einmal hat geht das bei allen Diensten, auch jenen, die keine sso Protokolle sprechen.
Mache das aber mittlerweile via authentik und nicht via keycloak. wenn ich dazu komme mache ich bei Interesse mal einen Thread dazu.
führt das nicht dazu, dass der Logout-Link im Moodle dann nicht nur die Moodle-Sitzung beendet, sondern einen IdP-weiten Logout bei allen anderen Webdiensten auslöst (sofern diese das unterstützen)? Das wäre aus Nutzersicht durchaus unerwartetes Verhalten und je nach Anzahl und Art der verwendeten Dienste auch mal ärgerlich.
Hi Buster,
so sollte das m.M.n. auch sein. Eine Single-Sign-On Sessions sollte auch via SSO-Logout beendet werden. Für einen User, der Moodle aufruft, sich dann via SSO einloggt und dann wieder ausloggt (und wieder auf der Login-Seite von Moodle landet) ist es nicht ersichtlich/nachvollziehbar ob er nur aus Moodle raus ist oder komplett ausgeloggt ist. Mit einem Klick auf den Login Button in Moodle wäre er wieder drin, er müsste bei Standardkonfiguration also nach dem Logout aus Moodle zusätzlich manuell auf die IdP Seite wechseln und dort nochmal einen zentralen Logout durchführen. Einmal einloggen aber zweimal ausloggen… das ist nicht intuitiv und endet mit weiterhin aktiven Sessions… das werte ich als unsauber implementiert bzw. Sicherheitslücke (auch die Sessiontime reduzieren ist Pfusch).
Das finde ich btw. bei Authentik sehr schön, beim Logout einer Applikation landet man direkt auf der Logoutseite vom IdP/Authentik, der fragt ob man sich ganz ausloggen sollte.
Auch hier sollte man sicherstellen, dass der zentrale Logout auch wirklich alle aktiven Sessions killt! Bringt ja nix, wenn die Leute denken sie wären zentral aus allem ausgeloggt obwohl sie dann doch noch in einzelnen Dienste eingeloggt sind.
Das sind alles vermeidbare Risiken, aber viele Dienste, wie auch Moodle, sind oft halt nicht so zuverlässig was den Logout angeht.. daher die Taktik via reverseproxy (+ authentik middleware).
der Standard beschreibt zwei Szenarien: Logout in der eigenen Anwendung (nur beim eigenen Service Provider (SP)) oder Logout bei allen SP, wobei letzteres vom Identitätsanbieter (IdP) vermittelt werden muss, weil nur der IdP alle bei ihm registrierten SP kennt. Szenario 1 kommt ohne IdP aus. Szenario 2 setzt voraus, dass der SP den Standard vollständig implementiert und IdP-initiierte Logouts unterstützt.
Ich wollte nur darauf aufmerksam machen, dass Leute unterschiedliche Erwartungen haben können. Deine Erwartung scheint Szenario 2 zu sein, meine wäre Szenario 1.
Welches Szenario ausgelöst wird, entscheidet letztlich der Programmierer der Anwendung (des Authentifizierungsplugins) oder der Administrator, der das konfiguriert, wenn der Programmierer ihm die Wahl lässt. Wenn du gleichzeitig etliche SP und den IdP selbst betreibst, kannst du da versuchen in jeder Anwendung den Login/Logout-Link als globalen Login einzurichten. Sobald externe Dienstleister ins Spiel kommen, wird oftmals nur Szenario 1 unterstützt, weil da der SP nur seine eigenen Cookies und Sessiondaten in der Anwendung verwerfen muss.
