WebSecurity LDAP

Aus THM-Wiki
Wechseln zu: Navigation, Suche

Übersicht

Dieser Artikel enstand im Rahmen unserer Projektarbeit des Masterkurses WebSecurity im SS08. Wir haben überprüft ob eStudy mit der LDAP-Nutzungsordnung des ITS konform ist. Dazu wurde zunächst der Authentifikationsmechanismus von eStudy untersucht - genauer jedoch nur die LDAP relevanten Teile. Dabei waren vor allem die Daten von Intresse, die eStudy vom LDAP abfragt und in welcher Weise diese verarbeitet oder sogar in der Session oder der Datenbank gespeichert werden. Ausserdem war es natürlich wichtig wozu eStudy diese Daten verwendet. Um eine rechtliche Bewertung abzugeben, haben wir das ITS direkt angesprochen. Eine funktionale Bewertung haben wir selbstständig durchgeführt, d.h. wir haben uns bei jeder Nutzung der LDAP-Daten die Frage gestellt, ob diese Nutzung überhaupt Sinn macht - aus Benutzersicht sowie aus Sicht des Betreibers. Aus den gewonnen Informationen haben wir dann ein Fazit gezogen, einige kleine Änderungen an eStudy vorgeschlagen und natürlich die rechtlich erforderlichen Schritte gegenüber dem ITS abgeklärt.

Da wir kein Intresse daran hatten auf jedem unserer Entwicklungssysteme einen LDAP-Server aufzusetzten und entsprechend zu konfigurieren, haben wir eine vollständige Entwicklungsumgebung für eStudy inkl. der entsprechenden Serverdienste und Entwicklungswerkzeuge erstellt. Wer Intresse daran hat, sollte sich den Artikel Howto_Virtual_eStudy_Development ansehen.

Was ist LDAP ?

Als LDAP-Server bezeichnet man mehrere Komponenten. Einen Directory-Server der ein Verzeichnis auf Basis der LDAP Spezifikation bereitstellt und einen LDAP-Client, der mittels Lightweight Directory Access Protocol mit dem Directory-Server kommuniziert. Die Abkürzung LDAP bezeichnet also streng genommen nur das Kommunikationsprotokoll im OSI Layer 5 zwischen einem Verzeichnis-Server und einem Client. Mit diesem können Informationen beliebiger Art im Directory-Server in hierarchischer Form verwaltet und zur Verfügung gestellt werden. Diese können vom Client - zum Teil anonymisiert - abgefragt werden. Sensiblere Informationen können serverseitig durch Access Control Lists (ACLs) besonders geschützt werden und sind erst nach erfolgreicher Authentifizierung sichtbar. Die aktuelle Version V3 ist in mehreren RFCs spezifiziert.RFC4510 bietet dazu einen Überblick.

Warum und wozu LDAP ?

LDAP ist für performantes Suchen ausgelegt und ist daher besonders gut für Verzeichnisse geeinget die eher selten geändert und schnell durchsucht werden. Die bekannteste Nutzung dürften Personenverzeichnisse sein, z.B. an der FH zur Benutzerauthentifikation. Ein weiteres Beispiel ist das Speichern von Anwendungseinstellungen die Netzwerkweit verfügbar sind. Mittels LDAP lassen sich tausende Benutzer zentral verwalten und können sich an den verschiedensten Systemen einloggen - Windows-Domänen, Unix/Linux Systeme und selbst in Webanwendungen wie eStudy. Benutzer Authentifikation ist jedoch nicht der einzige Anwendungsbereich, denn durch die frei definierbare Baumstruktur ist LDAP sehr flexibel.

Weitere Informationen finden sich in Wikipedia LDAP

Estudy Authentifizierung via LDAP

Allgemein

Estudy bietet die Möglichkeit sich als Benutzer gegenüber einem Verzeichnisdienst zu authentifizieren und damit Zugang zum Portal zu erhalten. Wir haben zunächst einfach überprüft wo im Code überhaupt LDAP Daten verwendet werden um einen ersten Überblick zu bekommen.

Klasse/Datei welche Stelle/Funktion Verwendung
/web/common/classes/class.auth.inc.php Zeilen: 198/205 function validateLogin(...); 218 $_SESSION[] Authentifizierung an LDAP-Server, falls vorhanden
/web/common/classes/class.ldaplogin.inc.php Zeilen: alles Klasse für den LDAP-Login
/web/common/classes/class.passwords.inc.php Zeilen: 399 public static function sendMessageByLoginWithPasswordProblems(...) Passwort entspricht nicht den eStudy-Richtlinien (Link zur Passwortänderung falls LDAP-User)
/web/common/classes/class.tempLogin.inc.php Zeilen: 150 function connectLDAP Prüft, ob der LDAP-Server erreichbar ist
/web/news/classes/class.news.inc.php Zeilen: 261 public function echoWelcomeNote Zeigt User-Info falls über LDAP vorhanden ( keine Verarbeitung dieser Informationen erlaubt. Und hier auch nicht sinnvoll!)
/web/news/news.php Zeilen: 92-94 $_SESSION[...] Ausgabe einer Rolle aus LDAP, falls existent (hier wird anscheinend was vom LDAP in der Session gespeichert)
/web/user/classes/class.editUser.inc.php Zeilen: 87;161;185;298 $_SESSION[...] Passwortänderung für LDAP-User
/web/user/classes/class.overview.inc.php Zeilen: 515 public function getLDAPInfo() Link zur Passwortänderung für LDAP-User
/web/user/changepassword.php Zeilen: 44 $_SESSION[...] hier werden LDAP Infos in der Session gespeichert, die nicht unbedingt notwendig bzw. privat (ldap-group) sind.
/web/anmeldung.php Zeilen: 43;57-58;63-64;115-117;122 Abhandlung der Anmeldung an eStudy
/web/login.php Zeilen: 87;110-111;116;144-145;167;220 $authResult Bei ausgeschaltetem LDAP-Server; 144: connectLDAP() Server erreichbar? Generell: Abhandlung der Authentifikation anhand der Variablen $authResult. 220: Aufruf von validateLogin(...) -> Hier wird kommuniziert!
/web/tlogin.php Zeilen: 82-83;86;90;92;95;116-117;134 Temporärer Login, falls LDAP-Server nicht erreichbar. connectLDAP() prüft auf Verfügbarkeit


FH-LDAP

Das ITS der Fachhochschule Giessen-Friedberg verwaltet seine Benutzer mit Hilfe eines FH eigenen LDAP-Servers, der allen Mitgliedern der Fachhochschule als öffentlicher Dienst zur Verfügung steht.

Weitere Informationen über diesen und weitere angebotene Dienste des ITS findet man auf deren Homepage: http://www.dvz.fh-giessen.de

Um uns die Arbeit zu erleichtern und um wirklich nachvollziehen zu können, wie die Struktur des LDAP unserer FH aussieht, haben wir in unserem virtuellen Testsystem einen LDAP-Server nachgebildet, der in etwa dem der FH entspricht. Dieser stellt alle nötigen Attribute eines Benutzers zur Verfügung, die eStudy benötigt.
Ermöglicht wurde uns der Nachbau durch die erweiterte Dokumentation des LDAP-Dienstes der FH, welche man ebenfalls auf der Homepage vom ITS in einem speziellen Benutzerbereich findet. Dokumentation LDAP-Verzeichnisdienst

Die Nachfolgende Abbildung zeigt grafisch die Struktur (den Baum) des Verzeichniseintrags eines Benutzers.

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
Verzeichnisbaum

Jeder Eintrag eines Benutzers stellt einen Knoten im Verzeichnisbaum dar. Eingepflegt und verwaltet werden die Daten im LDAP Data Interchange Format LDIF.

Ein Beispieleintrag eines Benutzers Peter Lustig sieht folgendermaßen aus:


dn:   uid=lustig,ou=People,ou=mni,ou=Giessen,dc=fh-giessen-friedberg,dc=de
objectClass:  top
objectClass:  gifb-person
objectClass:  inetOrgPerson
objectClass:  posixAccount
objectClass:  shadowAccount
objectClass:  gifb-mailPerson
ou: Giessen
ou: MNI
cn: Peter Lustig
displayName:  Peter Lustig
sn: Lustig
givenName:  Peter
uid:  lustig
description:  Student
uidNumber:  1001
gidNumber:  1001
homeDirectory:  /home/lustig
loginShell: /bin/bash
gecos:  Peter Lustig, mni
shadowMin:  1
shadowMax:  180
shadowWarning:  22
shadowInactive: 1
shadowExpire:   -1
gifb-maildrop:  lustig@mailserv.fh-giessen.de
mail: peter.lustig@loewenzahn.de

Nicht öffentliche Attribute wurden in diesem Beispiel nicht erwähnt, da deren Werte nicht für externe Augen bestimmt sind. Und auch wenn es sich hierbei um einen Beispieleintrag handelt, möchten wir uns dabei an die Vorgaben des ITS halten. Öffentliche Attribute sind von allen FH-Angehörigen anonym abrufbar.

Die Verwendung und Verabeitung der Daten wird über die LDAP-Nutzungsordnung des ITS geregelt.

Eine Überprüfung auf Konformität seitens eStudy gegenüber eben erwähnter ist auch Teil dieser Ausarbeitung.

Dennoch ist es unvermeidlich für diesen Bericht die fehlenden nicht öffentlichen Attribute zu erwähnen, da einige von ihnen zum Teil verarbeitet und in einer Datenbank gespeichert werden. Darauf werden wir aber später zu sprechen kommen.

Für den/die Interessierte(n) Leser ein kleines Beispiel wie man den FH internen LDAP abfragt. Anhand dessen wird auch die Erklärung der Authentifizierung eines Benutzers mit der LDAPLogin-Klasse im folgendem Abschnitt klarer.

Anonyme Abfrage des Suchpfades

Um den Suchpfad (dn) eines Benutzers heraus zu finden setzt man folgenden Befehl ab:

ldapsearch -x -ZZ  -b "dc=fh-giessen-friedberg,dc=de" "(uid=<hg-nummer>)" dn

Dieser Befehl liefert folgende Antwort:
(in unserem Fall)

# extended LDIF
#
# LDAPv3
# base <dc=fh-giessen-friedberg,dc=de> with scope sub
# filter: (uid=hg12903>)
# requesting: dn 
#

# hg12903, People, mni, Giessen, fh-giessen-friedberg.de
dn: uid=hg12903,ou=People,ou=mni,ou=Giessen,dc=fh-giessen-friedberg,dc=de

# search result
search: 3
result: 0 Success

# numResponses: 2
# numEntries: 1

In ihm enthalten ist der Suchpfad (dn)

dn: uid=hg12903,ou=People,ou=mni,ou=Giessen,dc=fh-giessen-friedberg,dc=de

Abfrage der Attribute

Den Suchpfad benutzt man dann, um sich gegenüber dem LDAP zu authentifizieren und alle Attribute über einen Eintrag ab zu fragen:

 ldapsearch -x -ZZ -W -b "dc=fh-giessen-friedberg,dc=de" -D "uid=hg12903,ou=People,ou=mni,ou=Giessen,dc=fh-giessen-friedberg,dc=de" "(uid=hg12903)"

Die Ausgabe sparen wir uns an dieser Stelle :) Ein Blick in die Manpage von ldapsearch sei geraten.

Estudys Authentifizierungs Vorgang

Estudy stellt eine Klasse zur Verfügung, welche die Kommunikation und die Authentifizierung eines Clients gegenüber einem LDAP-Server abwickelt. Diese Klasse trägt den Namen LDAPLogin. Siehe Abbildung:

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
LDAPLogin-Klasse

Schaut man sich die Implementierung genauer an, fällt sofort auf, dass diese Klasse speziell an die Struktur des FH eigenen LDAP-Server angepasst ist und für eine allgemeine Verwendung zur Authentifizierung gegenüber eines beliebigen LDAP-Server nicht geeignet ist.

Dies ist für unsere Betrachtung in Bezug auf Sicherheit und Schutz der personenbezogenen Daten nicht besonders relevant, aber dennoch erwähnenswert.

Am besten lassen sich die Operationen der Klasse an Hand eines Logins eines Benutzers erklären. Dabei wird auch bewusst, welche zusätzlichen Klassen bei einer Authentifizierung über LDAP mit ins Spiel kommen.

Wir starten unsere Betrachtung mit folgendem vereinfachtem Sequenzdiagramm:

LDAP-Login


Login Szenario

Ausgangssituation

Ein Benutzer befindet sich auf der Startseite des Portals, hat den Einloggen-Link betätigt und seine Kombination aus Benutzername und Passwort in das Eingabeformular eingetragen. Diese Aktion bestätigt er mit einem Klick auf den Einloggen Button.

Screenshot eStudy Loginformular

Benutzername und Passwort werden per POST an das Skript login.php übergeben. Ab diesem Zeitpunkt wird der Authentifizierungsmechanismus von eStudy angestoßen. Durch die Nummerierung im Sequenzdiagramm sind die einzelnen Beschreibungsschritte nachvollziehbar.

Authentifizierungs Vorgang

1. Ein Objekt der Klasse tempLogin wird instanziiert. Dieses Objekt wird im Falle eines fehlerhaften Logins dazu verwendet um zu testen, ob der Server überhaupt konnektierbar ist.

2. Die Methode validateLogin() der Auth-Klasse wird aufgerufen. Benutzername und Passwort werden als Parameter übergeben. Diese Methode dient zur Überprüfung des Benutzernamens, des Passwortes und weiterer Berechtigungen. Für den Fall, dass über die Einstellungen von eStudy LDAP-Login verwenden oder LDAP-Login erzwingen aktiviert wurde, geht es weiter mit Schritt 3.

3. Ein Objekt der Klasse tempLogin wird instanziiert.

4. Die Methode connectLDAP() der tempLogin-Klasse wird aufgerufen. Diese prüft, ob der LDAP-Server überhaupt erreichbar ist. Den Namen des Servers erhält die Methode über den in den Einstellungen eingetragenen Namen des Servers oder dessen IP. Der Port wird in Abhängigkeit, ob LDAP über SSL verwendet wird oder nicht, gewählt.

5. Konnte eine Verbindung hergestellt werden liefert die Methode true zurück und es geht weiter mit Schritt 6.

6. Ein Objekt der Klasse LDAPLogin wird instanziiert. Der Konstruktor der Klasse bekommt folgende Parameter übergeben, welche wiederum durch die Einstellungen festgelegt sind:

  • server - Serername oder IP
  • baseDN - Wurzel Suchpfad
  • filter - Den Filter der Suchanfrage
  • protocol - Die LDAP-Version

Merkwürdigerweise werden hier im Konstruktor auch die Attribute definiert, welche vom Verzeichnisdienst über den Benutzer abgefragt werden. Die Attribute im einzelnen mit Sichtbarkeit im LDAP:

Attribute
Attribut Zuordnung eStudy Sichtbarkeit im LDAP
uid Login öffentlich
mail Email öffentlich
givenname Vorname öffentlich
sn Nachname öffentlich
ou department öffentlich
userclass UserGroup privat


7. Die Methode authenticateUser() der LDAPLogin-Klasse wird aufgerufen. Als Paramter erwartet sie Benutzername und Passwort. Diese Methode wickelt eine ganze Reihe von Aufgaben ab beginnend mit Schritt 8, falls weder Benutzername noch Passwort leer sind.

8. Die Mehode connect() der LDAPLogin-Klasse wird aufgerufen. Sie stellt eine Verbindung zum LDAP-Server her und gibt diese zurück. Sollte in den Einstellungen ein Passwort oder Benutzername gesetzt werden wird sich ggf. mit dieser Kombination am LDAP-Server authentifiziert. Wir gehen in unserer Situation davon aus, dass diese nicht gesetzt wurden.

Nach diesem Schritt wird eine anonyme Such-Abfrage an den LDAP-Server abgesetzt. Aus deren Resultat wird anhand des Filters der Suchpfad herausgesucht. Im Filter landet der Benutzername. Daraufhin authentifiziert man sich über Angabe des ermitteltnden Suchpfades und des übergebenen Parameters Benutzername mittels eines bind-Aufrufs am Server.

Sollte die Authentifizierung erfolgreich gewesen sein, wird eine zweite Suchanfrage auf die gewünschten Attribute abgesetzt und die Verbindung zum Server über einen unbind-Aufurf beendet.

Es folgt die Zuordung der einzelnen Attribute in die interne Darstellung von eStudy.

Das Attribut UserClass wird zur internen Rolle von eStudy, die der Benutzer trägt, gemapped. Diese Rolle wird zusätzlich in einer Sessionvariable ldapGroup zur späteren Verwendung gespeichert.

Daraufhin folgt Schritt 9.

9. Aufruf der Methode alreadyRegistered(). Es wird überprüft, ob der Benutzer bereits registriert ist.

10. Aufruf der Methode create Shortname(). Anhand der über alreadyRegistered() gewonnenen Information, wird ein Kurzname für den Benutzer erstellt. Wenn der Benutzer schon registriert ist, geht es weiter bei Schritt 11, andernfalls bei Schritt 12.

11. Aufruf der Methode updateUser(). Die Informationen über den Benutzer aus dem LDAP werden in der Datenbank gespeichert.

12. Aufruf der Methode createUser(). Der Benutzer wird in der Datenbank angelegt und seine Attribute werden in dieser gespeichert.

Die Schritte 13 und 14 stellen lediglich das Ende und den Rücksprung aus ihren jeweiligen Funktionsaufrufen dar.

Für unsere Betrachtung ist ihr Wert vorerst nicht weiter von Belang. Wir gehen davon aus, dass keine weiteren Fehler aufraten und die Authentifizierung erfolgreich war. Der Benutzer hat also Zugang zum Portal erhalten.

Schritt 11 und 12 sind für unseren Bericht aber durchaus interessant. Hierbei kommt nämlich Punkt 5 der Nutzungsordnung des ITS ins Spiel.

Die vom LDAP abgefragten Attribute werden in der Datenbank gespeichert. Dies stellt einen Verstoß gegen diesen Punkt dar. Um die Nutzungsordnung zu Unterschreiben, muss ein entsprechendes Verfahrensverzeichnis erstellt und vom Datenschutzbeauftragten der FH genehmigt werden.

Ablauf des Logins am LDAP

Als erstes wird ein anonymer connect am LDAP-Server durchgeführt. Das Connect bekommt die Wurzel des LDAP-Servers mitgeteilt. Von dort aus wird ein anonymer bind mit einem Filter gestartet. Der Filter ist die sogenannte “uid” des sich authentifizierenden Benutzers (in unserem Falle eine hgNummer der FH). Der (erste anonyme) bind liefert ein Ergebnis, in dem der Komplette Eintrag der passenden uid vom Blatt bis hin zur Wurzel enthalten ist. Ein Search-Aufruf gibt die Attribute vom directory node (DN) an, die weiterverarbeitet werden sollen. Nach einem unbind erfolgt dann der bind() zur Authentifizierung mit der entsprechenden UID und liefert die gewünschten Attribute. Danach wird wieder unbind() aufgerufen und es erfolgt ggf. eine Aktualisierung der Einträge in eStudy mittels updateuser() oder createUser(), für den Fall, dass Änderungen an den Nutzerdaten vorgenommen wurden.

LDAP Nutzungsordnung

Nr. Nutzungsbedingung Übereinstimmung Bemerkungen / Fragen
1 Rechner- und Softwaresysteme, die am hochschulweiten Authentifizierungsdienst partizipieren sollen, und die nicht vom ITS betreut werden, müssen dem ITS zuvor angezeigt werden. JA
  • Laut Anfrage beim ITS ok
2 Die unter 1. genannten Rechnersysteme müssen sich auf dem Campus und im Netz der Hochschule befinden. JA
  • Laut Anfrage beim ITS ok
3 Angriffe gegen den hochschulweiten Authentifizierungsdienst haben ohne Ausnahme zu unterbleiben. Die an den hochschulweiten Authentifizierungsdienst angebundenen Systeme sind sicherheitstechnisch auf dem aktuellen Stand zu halten (insofern sie nicht von ITS selbst betreut werden). Benutzerpassworte dürfen keinesfalls mitgeschnitten oder auf andere Weise Dritten offenbart werden. Kompromittierte Systeme sind ITS umgehend anzuzeigen.
4 Benutzerpassworte dürfen ausschließlich zur unmittelbaren Durchführung der Authentifizierung bei den Benutzern abgefragt werden und nur zu diesem Zweck verarbeitet werden. Eine Verarbeitung der Benutzerpassworte, die nicht unmittelbar und ausschließlich die Authentifizierung gegen den hochschulweiten Authentifizierungsdienst dient, ist in jedem Fall verboten. Die Übertragung der Passworte im Netz erfolgt ausnahmslos über gesicherte Verbindungen, die auf den offiziellen X.509-Zertifikaten (FH-GIFB CA) der Hochschule basieren. JA eStudy überprüft, das Passwort bei LDAP-Anfragen nicht. Ist aber optional einstellbar. Es sollte also unbedingt dafür Sorge getragen werden, das diese Option nicht genutzt wird.
5 Daten, die vom hochschulweiten Authentifizierungsdienst abgefragt werden, dürfen ohne eine datenschutzrechtliche Abklärung nicht weiterverarbeitet werden, indem sie z.B. in einer Datenbank gespeichert werden. Ebenso ist die Weitergabe dieser Daten (z.B. über einen LDAP-Proxydienst) nicht zulässig. Vor einer Weiterverarbeitung ist ein Verfahrensverzeichnis zu erstellen, das dem Datenschützer der Hochschule sowie ITS vorgelegt werden muss. Erst wenn die genannten Stellen der Weiterverarbeitung schriftlich zugestimmt haben, ist eine Weiterverarbeitung möglich. Es muss ein Verfahrensverzeichnis erstellt werden, dass beschreibt aus welchem Grund die abgefragten Attribute in der Datenbank gespeichert werden sollen und was mit diesen Daten passiert. Liste der betroffenen Attribute
6 ITS behält es sich vor bei Verstößen gegen eine oder mehrere der oben genannten Auflagen die Zugriffsrechte- und Möglichkeiten je nach Schwere des Verstoßes ggf.ohne Vorwarnung zu entziehen.
7 Die hier getroffenen Regelungen können von ITS jederzeit erweitert oder verändert werden. Über Änderungen werden die Betroffenen rechtzeitig informiert.

Bei der Authentifizierung am LDAP abgefragte und gespeicherte Attribute des Verzeichnisses

Für folgende Attribute muss, wie in der obigen Tabelle LDAP Nutzungsordnung ersichtlich ist, ein Verfahrensverzeichnis erstellt werden.

Gespeicherte LDAP Attribute in eStudy

  • uid
  • mail
  • givenname
  • sn
  • ou

In der Session gespeicherte Attribute

  • userclass

userclass ist ein nicht öffentliches Attribut!

Best Practices

Da die Kommunikation mit einem LDAP-Server immer sehr organisationsspezifisch stattfindet, lassen sich keine generellen "best practices" definieren. Ein bedenklicher Punkt unserer Seite war der anonyme connect-Aufruf im LDAP-Verzeichnis um einen entsprechenden search path zur späteren Authentifizierung gegenüber eStudy zu definieren. Auf Anfrage beim ITS ergaben sich aber keine sicherheitsrelevanten Bedenken an der anonymen Anfrage. Sämtliche nicht öffentlichen Attribute sind erst nach erfolgreicher Authentifizierung abrufbar.

Fazit

Die derzeitige Implementierung von eStudy ist zu unflexibel und FH spezifisch um allgemein genutzt zu werden. Eine wirklich allgemein verwendbare Implemtierung ist nur mit etwas mehr Aufwand zu realisieren, da die hierarchische Struktur von LDAP extrem flexibel ist.

Die Option zur Überprüfung des Passwortes muss in jedem Fall deaktiviert bleiben. Innerhalb der FH-Version von eStudy sollte über eine vollständige Entfernung dieser Funktionalität nachgedacht werden. Sinnvoll erscheint uns eine Kopplung mit der Einstellung LDAP Login. Die Überprüfung sollte nur bei deaktiviertem LDAP-Login stattfinden. Andernfalls ist die Sicherheit der Passworte dem Betreiber des LDAP-Servers zu überlassen.

Für die verwendeten Attribute ist ein Verfahrensverzeichnis zu erstellen. Die Benutzung des privaten LDAP-Attributes userclass zum Zuordnen der Benutzer zu eStudy Benutzgruppen ist wichtig. Das Speichern in der Session ist jedoch sinnlos, da die eStudy-Benutzergruppen bereits in der Datenbank gespeichert sind. Userclass wird innerhalb von eStudy zur Zeit lediglich für die Welcome-Nachricht benutzt. Die Angabe der FH-weiten Benutzergruppe ist innerhalb von eStudy irrelevant, da eStudy seine eigenen - bereits vom LDAP abgeleiteten - Benutzergruppen verwendet. Die Userclass sollte daher aus der Session und der Verwendung in news.php entfernt werden. Eventuell sollte - für den Fall des es nicht entfernt wird - in der Liste der personebezogenen Daten erwähnt werden, dass userclass in der Session und nicht in der Datenbank gespeichert wird. Die Nutzung und Speicherung aller anderen Attribute ist unserer Ansicht nach legitim und sinnvoll. Alternativ wäre es auch möglich für jede Nutzung der öffentlichen Attribute eine extra LDAP-Abfrage durchzuführen, was jedoch zu unnötiger Netz- und LDAP-Last führen würde,da die Attribute ohnehin öffentlich und für jeden FH Angehörigen abrufbar sind.

Links

LDAP

Allgemein