LDAP - Authentifizierung

1. LDAP - Authentifizierung LDAP – Authentifizierung Dienstag, 16:30-18:00 Uhr, Panorama 1 Hendrik Brummermann brummermann@his.de Wilfried Jauer jauer@his.de

2. Themen Wie erfolgt die Authentifizierung in LSF/QIS-Anwendungen? Welche technischen Möglichkeiten zur Authentifizierung gibt es insgesamt in diesem Umfeld? Wie wird bestimmt, was tatsächlich benutzt wird? Wie verbinde ich LSF/QIS mit einem LDAP-Server? Wer nutzt was? Nicht: Was ist LDAP?

3. Benutzerzugang • Der Standard-Benutzerzugang zu LSF/QIS-Funktionen erfolgt über Login und Passwort. • Keine weitere Technik erforderlich(z. B. Chipkartenleser, Biometrie ...) • Probleme: • Ein Nutzer hat viele Passwörter • Passwörter müssen verteilt werden • Passwörter können ausgespäht werden • Lösung: • LDAP, ...(?)

4. Benutzer und Rollen Ein Nutzer hat viele Rollen ... Prof. Müller als Dekan des Fachbereichs Naturwissenschaften: Als Lehrender bietet er Veranstaltungen an Als Prüfer benotet er Prüfungen Als Mittelbeauftragter überprüft er die Mittel seines Fachbereichs Als Uni-Angehöriger liest er Emails Als Mitarbeiter stellt er Reiseanträge Als Teilnehmer an der leistungsorientierten Kostenerfassung verbucht er zeitbezogen seine Aufwände Für jede Rolle ein eigenes Passwort? + Wenn ein Passwort korrumpiert wird, sind die anderen nicht betroffen. - So viele Passwörter kann man sich nicht merken.

5. Passwörter bereiten Arbeit Passwörter müssen verteilt werden Wie und wo werden Passwörter erzeugt und wie kommen sie auf einem sicheren Wege zum Benutzer? Benutzer vergessen Passwörter. Passwörter müssen sicher aufbewahrt werden Schön wäre es, jemand anders würde sich um die Passwörter kümmern ... Oft gibt es bereits eine funktionierende Passwort-Infrastruktur! Authentifizierungsserver

6. Authentifizierungskonzepte LSF und QIS erlauben die Anbindung an eine Reihe unterschiedlicher Authentifizierungsserver (die von einer Hochschule bereits betrieben werden). Darüber hinaus werden hochschuleigene Authentifizierungskonzepte unterstützt (Beispiel Uni Ulm, TU Hamburg-Harburg, RWTH Aachen). Wenn es so etwas nicht gibt: Eigene Passwortverwaltung in Datenbanken (wahrscheinlich mit oben genannten Problemen)

7. Authentifizierung wird konfiguriert Wie die Authentifizierung tatsächlich durchgeführt wird, wird konfiguriert.  LoginConf.xml

8. Aufgaben der Authentifizierung in QIS/LSF Aufgaben Die Authentifizierung stellt sicher, dass der Benutzer derjenige ist, der zu sein er vorgibt. Es wird eine Zuordnung zwischen Login und internen Datenbank-Schlüsseln durchgeführt (grobe Rollenbestimmung). Es werden anwendungsspezifische Rollen ermittelt. Beispiel: LSF-Person ist Fachbereichsadministrator für FB 12 grob fein

9. Funktionsprinzip Automatische Rollenermittlung: Konfigurierung mit LoginConf.xml • Funktionsprinzip: • In LoginConf.xml ist eine Liste von Login-Überprüfungen angegeben. • Die Liste wird der Reihe nach abgearbeitet, bis eine Überprüfung erfolgreich war. • Die Login-Überprüfung liefert einen ID-Begriff und eine Rolle bzw. alle Rollen. • Eine Login-Überprüfung kann sein: • Eine Datenbankabfrage • Ein Serveraufruf (ldap, radius, imap)

10. Beispiel • Beispiel: • LSF mit Belegen, es gibt Passwörter in der sospos-Datenbank für Studenten, ansonsten keine Passwort-Infrastruktur • Prüfe, ob Login und Passwort in der LSF-Datenbank vorkommen. Wenn ja ok, breche ab. • Prüfe, ob Login und Passwort in der sospos-Datenbank vorkommen. Wenn ja ok, breche ab. • Wenn nichts mehr zu prüfen ist, ist das Loginungültig

11. Beispiel • 2. Beispiel: • QISPOS mit Studenten- und Prüferfunktionen, es gibt Passwörter in der sospos-Datenbank für Studenten und Prüfer, ansonsten keine Passwort-Infrastruktur • Prüfe, ob Login und Passwort in der sospos-Datenbank als Student vorkommen. Wenn ja: ok, breche ab. • Prüfe, ob Login und Passwort in der sospos-Datenbank als Prüfer vorkommen. Wenn ja: ok, breche ab. • Wenn nichts mehr zu prüfen ist, ist das Loginungültig sos_acc k_ppruef

12. Probleme Probleme: Kommt eine Login-Passwort-Kombination (zufällig?) in mehreren Datenbanken/Tabellen vor? Gehört diese Kombination einer einzigen Person oder zwei verschiedenen? Sicherstellen, dass das nicht der Fall ist! Daraus folgt, dass „Single Sign On“ so nicht möglich ist! (Eine Person, die gleichzeitig Student und Prüfer ist, müsste mit zwei verschiedenen Logins operieren)

13. Beispiel • 3. Beispiel: • LSF ohne Studentenlogin, alle „privilegierten“ Benutzer sind in LDAP gespeichert. • Prüfe, ob Login und Passwort in LDAP gültig sind. Wenn ja: ok, mache weiter. • Nur wenn die vorhergegangene Abfrage erfolgreich war:Bestimme zu dem Login die zugehörige Personal-ID. Wenn ja: ok, breche ab. • Wenn nichts mehr zu prüfen ist, ist das Loginungültig

14. Beispiel • 4. Beispiel: • LSF mit Studentenlogin, alle „privilegierten“ Benutzer sind in LDAP gespeichert. • Prüfe, ob Login und Passwort in LDAP gültig sind und lese zusätzlich die „Rolle(n)“.Wenn ja: ok, mache weiter. • Nur wenn die vorhergegangene Abfrage erfolgreich war:Bestimme zu dem Login je nach LDAP-Rolle(n) die zugehörige Personal-ID und/oder die Matrikelnummer. Wenn ja: ok, breche ab. • Wenn nichts mehr zu prüfen ist, ist das Loginungültig

15. Probleme Probleme: Zur Zeit wird nur EINE Rolle verarbeitet! Bei mehreren Rollen:Wie sieht die entsprechende LDAP-Anfrage aus, vorausgesetzt, der LDAP-Server hat überhaupt eine entsprechende Struktur? Anmerkung: Wenn Hochschulen ihren LDAP-Server aus HISSVA und HISSOS speisen, wird nicht unbedingt eine Zusammenführung bei Personen vorgenommen, die in beiden Systemen vorkommen.

16. Technik • Fragestellungen: • Struktur der KonfigurationsDatei LoginConf.xml • Wie sieht eine Datenbankanfrage aus? • Wie sieht eine Anfrage an einen Authentifizierungsserver aus? • Wie findet die Ermittlung der anwendungsspezifischen Rollen statt?

17. Struktur Struktur der Konfigurationsdatei LoginConf.xml <login version="1.0"> <!–Globale Angaben, nicht ändern!--> <global> <!–Welche Typen von Authentifizierungs-Servern?--> <authentication-plugins> <!–Welche Rolle in welcher Datenbank?--> <role-db> </global> <!–Liste der Authentifizierungs-Versuche--> <auth> </login>

18. Protokolle Unterstützte Protokolle <authentication-plugins> <db>de.his.security.auth.DBAuth</db> <ldap>de.his.security.auth.LdapAuth</ldap> <mail>de.his.security.auth.MailAuth</mail> <mifare>de.his.security.auth.MifareAuth</mifare> <radius>de.his.security.auth.RadiusAuth</radius> <unknown>de.his.security.auth.UnknownAuth</unknown> <tuhh>de.his.security.auth.TUHHAuth</tuhh> <x509>de.his.security.auth.X509Auth</x509> <url>de.his.security.auth.OldURLDispatcher</url> </authentication-plugins>

19. Rollen und Datenbanken Rollen und Datenbanken Workaround für „Design-fehler“: LSF merkt sich die „userid“ (zum Beispiel „4711“). Ob 4711 eine Personal- oder eine Matrikelnummer ist, kann über die Rolle ermittelt werden. <role-db> <admin>lsf</admin> <lehrender>lsf</lehrender> <fachbereich>lsf</fachbereich> <forschung>lsf</forschung> <stgadmin>lsf</stgadmin> <raumverwalter>lsf</raumverwalter> <student>sospos</student> <pruefer>sospos</pruefer> </role-db>

20. Technik Der wichtigste Abschnitt ist <auth> : Dieser Abschnitt ist immer von der Hochschule anzupassen, da in der Auslieferungsversion eine Demo-Einstellung voreingestellt ist. Siehe Konzept: LokaleVariationen.html

21. Protokolle <auth> <!-- Beispiel für normale LSF-Datenbankabfrage --> <lsf active="y" type="db" database="lsf"> <!-- Beispiel fuer normale SOSPOS-Datenbankabfragen --> <sospos active="y" type="db" database="sospos„> <sospospruefer active="y" type="db" database="sospos"> <!-- **** Beispiele fuer externe Authentifizierungen **** --> <!-- Authentifizierung gegen einen IMAP-Server (UNVERSCHLUESSELT!) --> <imap active="n" type="url"> <!-- Beispiel fuer eine Authentifizierung gegen einen Radius-Server --> <radius active="n" type="url"> <!-- Beispiel fuer Auth-Verfahren der TU-Harburg --> <tuhh active="n" type="tuhh"> <!-- Beispiel fuer simple LDAP-Auth (siehe Doku fuer weitere Moeglichkeiten) --> <ldap active="n" type="ldap"> <extern-sospos active="n" type="db" database="sospos"> <extern-lsf active="n" type="db" database="lsf"> <!-- Anmeldung mit Smartcard (benoetigt besondere SQL-Statements) --> <smartcardBaseactive="n" type="x509" /> <smartcardStudent active="n" type="db" database="sospos"> <smartcardPruefer active="n" type="db" database="sospos"> </auth>

22. LDAP-Beispiel • <!-- Beispiel fuer simple LDAP-Auth --> • <ldap active="n" type="ldap"> • <connect> • <server>bv1.ruf.uni-freiburg.de</server> • <port>636</port> • <security>SSL</security> • <username>uid=[url:username],ou=people,dc=uni-freiburg,dc=de</username> • <password>[password]</password> • <attributes>uid,cn</attributes> • </connect> • </ldap> Alternativ: TLS Attribut: „Rolle(n)“ ?

23. URL-Maskierung Warum [url:username]: Beispiel (IMAP): [username]:[password]@imap.his.de username: admin password: xxx@imap.example.com/ Jetzt wird nicht der eigentlich beabsichtigte Server abgefragt, sondern imap.example.com, den ich als „böser“ Nutzer aufgesetzt habe. Bei der URL-Maskierung werden Sonderzeichen wie @ umgesetzt (%40).

24. Ermittlung der Datenbank-ID Nachfolgender Select für Studenten: <extern-sospos active="y" type="db" database="sospos"> <test>authenticated</test> <select>SELECT sos.mtknr, 'student' AS bereich, sos.nachname AS nachname, sos.vorname AS vorname, sos.geschl AS geschl FROM sos WHERE mtknr = [username] </select> <break/> </extern-sospos> Im Select fehlt die Abfrage auf Passwort: Statt dessen: <test>authenticated</test> <break/> heißt: Keine weiteren Abfragen. Rolle („bereich“)

25. Ermittlung der Datenbank-ID Nachfolgender Select für Lehrpersonen: <extern-lsf active="n" type="db" database="lsf"> <test>authenticated</test> <select>SELECT r_pernutzer.pid, personal.nachname AS nachname, personal.vorname AS vorname, personal.geschl AS geschl, nutzer.login AS username, r_kollektionnutzer.kollid ASrole FROM r_kollektionnutzer, r_pernutzer, nutzer, personal, k_kollektion where personal.pid = r_pernutzer.pid AND r_kollektionnutzer.nid = r_pernutzer.nid AND nutzer.nid = r_pernutzer.nid AND r_kollektionnutzer.kollid = k_kollektion.kollid AND login = '[username]' ORDER BY r_kollektionnutzer.kollid</select> <RoleMapping> <break /> </extern-lsf>

26. Ermittlung von Rollen Rollenermittlung: <RoleMapping> <_1>admin</_1> <_2>gast</_2> <_3>lehrender</_3> <_4>fachbereich</_4> <_5>student</_5> <_6>fachbereich</_6> <_7>forschung</_7> <_8>stgadmin</_8> <_9>raumverwalter</_9> </RoleMapping> Die Tags <_n> verweisen aufr_kollektionnutzer.kollid. Die internen Rollennamen („admin“, „gast“, ...) sind unabhängig von den Datenbankeinträgen. Die internen Rollennamen werden in conf/languages/[sprache].txt extern umgesetzt.

27. Probleme Probleme: Mehrere Rollen können zur Zeit nur innerhalb einer einzigen Abfrage ermittelt werden. (Der Select liefert mehrere Zeilen, die Spalte mit dem Namen „role“ wird ausgewertet.) TODO?: Mehrere Rollen werden über mehrere Anfragen hinweg gesammelt (Eigentlich überflüssig bei zentralem LDAP)

28. Wer setzt LDAP mit LSF/QIS ein? Uni Bamberg (Microsoft) Uni Freiburg (OpenLDAP) FH Harz (Sun One Directory Server, Version 5.2) FH Oldenburg/Ostfriesland/Wilhelmshaven (Novell eDirectory 8.7.x) Uni Potsdam (Sun) ... Weiterführende Literatur: Authentifizierung und Rollen (HTML) Danksagung: Herrn Roland Conradshaus, Uni Duisburg-Essenfür die ersten wichtigen Schritte bei der Realisierung gegen externe Authentifizierungsserver