19. Mrz 2021
Start der Testphase für Zentralen Anmeldedienst
Im Rahmen der Projekte E-Campus und IDM@ULB beginnt ab 19.03.2021 die Testphase für die schrittweise Übernahme der E-Learning Dienste der MLU in ein zentrales Anmeldesystem (Central Authentication Service).
Ein Beitrag von Andreas Helms, Felix Pahlow und Kristina Haase
Bisher können die meisten Webdienste der MLU schon mit einem Passwort genutzt werden, trotzdem ist eine separate Eingabe der Zugangsdaten in jedem Dienst notwendig. In einem ersten Schritt können sich nun die Mitarbeiter:innen der Bibliothek mit ihren zentralen Zugangsdaten im Lernmanagementsystem ILIAS für interne Weiterbildungen anmelden.
Für alle Nutzer:innen der Universität wird der Dienst für Echtzeitabstimmungen und -Feedback ARSnova auf zentrale Anmeldung umgestellt.
Der große Mehrwert des Single-Sign-Ons ergibt sich durch die Anbindung mehrerer Dienste. Einmalig zentral angemeldet, können innerhalb einer Sitzung, ohne eine weitere Anmeldung, alle an den zentralen Anmeldedienst angeschlossenen Dienste verwendet werden.
Im Laufe dieses Jahres sollen noch Stud.IP und ILIAS nahezu vollständig angebunden werden und die zentrale Anmeldung an den E-Learningdiensten somit für alle Nutzer:innen zur Verfügung stehen.
Wie funktioniert die Anmeldung bei ILIAS konkret?
Oberhalb des Eingabefeldes für die Zugangsdaten befindet sich ein Bild als Link zur Anmeldung über CAS, ein Klick darauf leitet Sie weiter zur Seite login.uni-halle.de
Überprüfen Sie noch einmal in der Adressleiste https://login.uni-halle.de und geben Sie die Anmeldedaten ein. Nach der Anmeldung werden Sie an ILIAS oder ARSNova zurück geleitet und sind angemeldet.
Eine Kurzanleitung finden Sie auch im Video Zentrale Anmeldung in ILIAS und ARSnova.
Für Nerds: Und wie funktioniert das technisch?
Das soll an einem Beispiel erklärt werden. Dazu nehmen wir an, dass die Dienste Stud.IP und ILIAS bereits an den CAS-Dienst angeschlossen sind.
Die Studentin Anna möchte Stud.IP benutzen. Dazu ruft sie in ihrem Browser die Stud.IP-Seite der MLU auf. Das Stud.IP prüft nun, ob Anna bereits vor Kurzem das StudIP benutzt hat (d. h. ob eine gültige Session besteht). Geprüft wird dies anhand eines Cookie, das bei einer früheren Sitzung vom Stud.IP gesetzt worden wäre. Dieses Cookie wird als Session-Cookie bezeichnet.
Da Anna gerade erst den Browser gestartet hat, gibt es noch keine gültige Session. Anna muss sich daher beim Stud.IP anmelden, um mit dem Stud.IP arbeiten zu können. Sie klickt daher auf den Knopf zum Anmelden über CAS. Das Stud.IP leitet den Annas Browser dann weiter zum CAS-Dienst.
Der CAS-Dienst prüft nun selber, ob bei ihm eine gültige Session für Anna besteht. Das wäre z.B. der Fall, wenn Anna bereits vorher einen anderen Dienst benutzt hat, bei dem sie sich über CAS eingeloggt hat. Geprüft wird dies wieder anhand eines Cookies und zwar an einem Cookie, das vom CAS-Dienst bei einer vorherigen Sitzung gesetzt wurde (dem CASTGC-Cookie).
Da Anna sich heute noch nicht über CAS angemeldet hat, findet das CAS keine gültige Session und zeigt dann ein Anmeldeformular an. Anna gibt jetzt ihre Anmeldedaten ein (Nutzerkennzeichen und Passwort) und der CAS-Dienst prüft jetzt gegen die zentrale Nutzerverwaltung der MLU, ob diese Daten gültig sind. Wenn dies der Fall ist, leitet der CAS-Dienst den Browser von Anna zurück zum Stud.IP. Dabei wird vom CAS-Dienst eine Session für Anna erstellt und die Information darüber als sogenannte Ticket-Granting-Ticket (TGT) im CASTGC-Cookie in Annas Browser gespeichert.
Das Stud.IP muss jetzt prüfen, ob das TGT tatsächlich vom CAS-Dienst stammt. Dazu fragt das Stud.IP beim CAS-Dienst an, ob das TGT gültig ist. Dies geschieht im Hintergrund, Anna bekommt davon nichts mit. Als Antwort bekommt das Stud.IP nun die Information, ob das TGT gültig ist (was hier mal annehmen) zusammen mit Daten über Annas Benutzerkonto. In diesem Fall wird dies unter anderem ihr Benutzerkennzeichen, ihr tatsächlicher Name und ihre E-Mailadresse sein.
Das Stud.IP erstellt nun selber eine eigene Session für Anna und speichert die Information darüber in dem Session-Cookie in Annas Browser.
Nun kann Anna mit dem Stud.IP arbeiten.
Nach einer Weile möchte Anna ILIAS benutzen. Sie geht nun auf die ILIAS-Seite der MLU. Da sie dieses heute noch nicht benutzt hat, hat das ILIAS keine gültige Session für Anna. Anna wählt die Anmeldung über CAS. Das ILIAS leitet daher den Browser zum CAS-Dienst weiter. Dabei wird das TGT aus dem CASTGC-Cookie, das der CAS-Dienst bereits vorher gesetzt hatte, an das CAS übergeben. Der CAS-Dienst prüft nun erneut, ob das TGT gültig ist (d. h. ob eine gültige Session am CAS für Anna existiert) und sendet diese Information an das ILIAS zurück zusammen mit den Daten über Annas Benutzerkonto. Da Anna sich bereits vorher erfolgreich angemeldet hat, hat sie eine gültige Session am CAS und daher wird die Login-Seite nicht noch einmal angezeigt und der Browser wird direkt wieder zum ILIAS zurück geleitet ohne dass Anna auch nur eine CAS-spezifische Seite angezeigt wird. Nun kann Anna mit ILIAS arbeiten, ohne ihre Benutzerdaten extra dafür eingegeben zu haben.
Über Andreas Helms
- Mitarbeiter/in
Wird es im Zuge der Umstellung auf einen zentralen Anmeldedienst auch eine Moeglichkeit geben, seinen Account-Login mit einem 2FA abzusichern?
Eine OTP Funktion koennte zum Beispiel in die Loewen-App integriert werden. Alternativ koennten USBKeys (z.B. FIDO u2f) akzeptiert werden. Insbesondere als Dozent finde ich es wichtig, dass die Daten meiner Studierenden nicht nur an einem Passwort haengen.
Es ist zumindest angedacht, die zentrale Anmeldeseite perspektivisch durch
Mehrfaktorauthentifizierung (MFA) weiter abzusichern. Ob und wann das konkrete
Gestalt annimmt, ist in der gegenwärtig sehr angespannten Personalsituation
nicht abzusehen.