Shibboleth im vhb-Verbund - Grundlagen

toc

Rechte an den verkörperten Dienstleistungsergebnissen

Der Auftragnehmer räumt dem Auftraggeber das dauerhafte, nicht übertragbare, unbeschränkte, unwiderrufliche Nutzungsrecht an den Dienstleistungsergebnissen, Zwischenergebnissen und vereinbarungsgemäß bei der Auftragserfüllung erstellten Dokumenten ein.

Erlaeuterung

Nach erfolgreicher Kursbuchung am vhb Portal (Punkte 1 - 3), meldet sich ein Studierender am LMS einer Traegerhochschule (Anbieter eines vhb-Kurses, Punkt 4) an. Er waehlt am vhb Authentifizierungsblock seine Heimathochschule aus (oder klickt auf den Deep-Link direkt im Kursbuchungsportal der vhb) und wird auf den entsprechenden IdP seiner Heimathochschule umgeleitet, an dem er sich authentifiziert bzw. per Single Sign-On einloggt ist (Punkt 5). Nach erfolgreicher Authentifizierung (oder SSO) werden die vuuid vom IdP der Heimathochschule und die Kursbuchungsattribute sowie vhb-Nutzerdaten vom IdP der vhb abgefragt und aggregiert am LMS bereitgestellt (Punkt 6).

Die vuuid ist ein schacPersonalUniqueCode mit dem Prefix urn:mace:terena.org:schac:personalUniqueCode:de:<SCOPE>:vuuid:, der eine pseudonymisierte Matrikelnummer als Schluessel-Attribut im vhb-Verbund bereitstellt.

• Die vuuid kann auf einfache Weise im Attribute Resolver der Identity Provider der Traegerhochschulen der vhb aus der Matrikelnummer generiert werden
• Durch den Einsatz der vuuid werden keinerlei personenbezogene Daten zwischen den Traegerhochschulen bei Login in LMSe ausgetauscht
• IdPs der Traegerhochschulen muessen nur einen schacPersonalUniqueCode mit dem Prefix urn:mace:terena.org:schac:personalUniqueCode:de:<SCOPE>:vuuid: innerhalb des vhb-Verbundes freigeben

Entsprechende Konfigurationen sind unter Shibboleth_Konfiguration beschrieben.

An Shibboleth im vhb-Verbund teilnehmende Learning Management Systeme (LMS) sind innerhalb der DFN-AAI in einer Entity Category vhb-member (http://aai.dfn.de/category/vhb-member) zusammengefasst. Dies ermoeglicht neben organisatorischen Vorteilen unter anderem auch eine einheitliche und einfache Freigabe der vuuid an den Identity Providern der Traegerhochschulen.

• In der Entity Category vhb-member sind nur LMS bzw. Shibboleth Service Provider zusammengefasst
• Identity Provider sind nicht Bestandteil der Entity Category
• Fuer die Entity Category vhb-member muss an IdPs der Traegerhochschulen nur die vuuid freigegeben werden
• Das Kursbuchungsportal der vhb (https://kurse.vhb.org/sp) ist nicht Bestandteil der Entity Category. Zur Registrierung und Rueckmeldung an der vhb muessen die Traegerhochschulen weiterhin zumindest die Matrikelnummer freigeben

Entsprechende Konfigurationen sind unter Shibboleth_Konfiguration beschrieben.

An Shibboleth im vhb-Verbund teilnehmende Learning Management Systeme (LMS) werden durch eine dedizierte Service Provider Application (https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApplicationOverride), mit eigenem Metadatensatz in die DFN-AAI eingebunden

• Evtl. bereits existierende Shibboleth-Anbindungen eines LMS koennen weiterhin unveraendert betrieben werden
• Die vuuid wird nur bei Logins aus dem vhb-Verbund uebermittelt
• Die Aggreggierung von vhb Kursbuchungsattributen findet nur bei Logins aus dem vhb-Verbund statt
• Ein LMS muss die Shibboleth-Authentifizierung in geeigneter Weise verarbeiten
• Ein LMS kann einen embedded WAYF Service fuer vhb-Studierende bereitstellen um einen einfachen Login fuer Studierende aller Traegerhochschulen direkt am LMS zu ermoeglichen

Entsprechende Shibboleth-Konfigurationen sind unter Shibboleth_Konfiguration beschrieben, die Implementierung eines entsprechenden Plugins fuer Moodle ist unter Vhb_Authentifizierungsblock beschrieben.

Der Shibboleth Service Provider stellt dem LMS im Kontext der entsprechenden Service Provider Application Kursbuchungsattribute in Form von eduPersonEntitlements bereit.

• Jedes LMS im vhb-Verbund erhaelt von der vhb ausschliesslich Kursbuchungsattribute fuer Kurse, die auf dem jeweiligen LMS bereitgestellt werden
• Kursbuchungsattribute repraesentieren immer ein Tupel aus Rolle und Kursschluessel (etwa Rolle student, Kursschluessel LV-0815)
• Ein LMS muss mindestens das Enrollment fuer Studierende (Rolle: student) implementieren
• Ein LMS kann zudem noch das Enrollemnt fuer die Kursevaluation (Rolle: evaluator) und Gaeste (Rolle: guest) implementieren

Details und ein entsprechendes Plugin fuer Moodle sind unter Shibboleth_Einschreibungsplugin beschrieben.

Von dem Kursbuchungsportal der vhb wird direkt in die LMS der Traegerhochschulen verlinkt

• Die entsprechenden Deep-Links enthalten einen Kursschluessel
• Ein LMS muss einen Handler bereitstellen, der auf Basis des im Deep-Link enthaltenen Kursschluessels direkt einen entsprechenden vhb-Kurs aufruft

Details zu Deep-Links sind unter Vhb_Authentifizierungsblock beschrieben.

Learning Management Systeme im vhb-Verbund legen bei Anmeldung von vhb-Nutzern via Shibboleth lokale Benutzerkonten an. Diese Konten muessen nach Ende der Nutzungsdauer automatisch geloescht werden. Dies ist zum einem aus dem Gebot zur Datensparsamkeit abzuleiten zum Anderen auch technisch notwendig, da Login-Namen bei einzelnen Hochschulen im vhb-Verbund wiedervergeben werden und diese Login-Namen bei bestimmten LMS (z.B. Moodle) als Primaerschluessel fuer lokale Benutzerkonten dienen. Wird ein Account nicht rechtzeitig geloescht, kann so Account-Hijacking entstehen.

An Shibboleth im vhb-Verbund teilnehmende Learning Management Systeme (LMS) muessen ein geeignetes Verfahren zur Benutzerdeprovisionierung implementieren. Moegliche Verfahren sind etwa:

• Verifizierung von Accounts mittels Shibboleth Attribute-Queries (nur fuer Shibboleth-Accounts geeignet)
• Verifizierung von Accounts durch Benutzer: Benutzer werden per E-Mail aufgefordert, sich innerhalb einer Frist einzuloggen und so das Bestehen Ihres Accounts und ihre Nutzungsberechtigung nachzuweisen. Benutzer, deren Account an der Heimathochschule geloescht oder gesperrt ist, koennen dies nicht. Entsprechend koennen solche lokalen Accounts aus dem LMS geloescht werden. Dieses Verfahren ist fuer beliebige Authentifizierungstypen anwendbar.

Ein Plugin, das die zweite Variante implementiert ist fuer Moodle unter Deprovisionplugin beschrieben.