Anlage Systembeschreibung und Daten zur Rahmendienstvereinbarung zu Einführung und Betrieb des Meta Directory mit den daran angeschlossenen Quell- und Zielsystemen (RDV Meta Directory) Vorbemerkungen Überblicksweise wird das Meta Directory als Gesamtsystem vorgestellt und die im Meta Directory an den Thüringer Hochschulen benötigten Datenfelder werden beschrieben. Die Einführung und der Betrieb des Meta Directory erfolgt im Rahmen des Projekts Integrierende Benutzer- und Ressourcenverwaltung an den Thüringer Hochschulen (Codex Meta Directory). Es handelt sich um ein thüringenweit koordiniertes Projekt. Diese Anlage reflektiert den aktuellen Arbeitsstand im Projekt Codex Meta Directory unter Berücksichtigung der Spezifika an den Thüringer Hochschulen und konzentriert sich auf die für den Abschluss der Rahmendienstvereinbarung wesentlichen Aspekte. Für eine tiefer gehende Betrachtung des Projekts Codex Meta Directory wird auf die Feinspezifikation Spezifikation Meta Directory Stufe 1 der Hochschulen in Thüringen und auf die Aktualisierung des Schemas Schemadokumentation Codex-Schema 2.0 verwiesen. Inhaltsverzeichnis 1. Systembeschreibung des Meta Directory 2. Personenbezogene Daten des Meta Directory und ihre Anwendungen 2.1. Personenbezogene Daten im Überblick 2.2. Daten zur Identifizierung von Personen 2.3. Anwendungsorientierte personenbezogene Daten 2.4. Technisch orientierte Daten 3. Behandlung freiwilliger Daten 4. Grundsätze zum Sicherheitskonzept des Meta Directory
Anlage Systembeschreibung und Daten zur RDV Meta Directory Seite 2 von 15 1. Systembeschreibung des Meta Directory Ein Meta Directory ist ein Rahmenwerk, das die Integration unterschiedlicher Verzeichnisse und anderer Informationsressourcen, wie zum Beispiel Datenbanken, gestattet und unterstützt. Die Hauptanwendung für ein Meta Directory liegt heute im Bereich der Verwaltung von digitalen Identitäten und Rollen, dem so genannten Identitäts- und Rollenmanagement. Eine eindeutige Identifizierung von Personen und die Zuordnung gültiger Rollen sind die notwendigen Voraussetzungen für die sichere Funktion von IT-Diensten, beispielsweise für die autorisierte Benutzung von Portalfunktionalitäten zur rechnergestützten Forschung, Lehre und Verwaltung an den Thüringer Hochschulen. Das Integrationspotential des Meta-Directory-Paradigmas basiert auf folgenden technologischen Aspekten: Ein LDAP-konformer Verzeichnisdienst wird für die Abspeicherung der zu integrierenden Daten verwendet. Das Lightweight Directory Access Protocol (LDAP) hat sich zu einem Standard für die Verwaltung von Benutzern und Ressourcen entwickelt. Verzeichnisdienste bieten außerdem ein flexibles und leicht erweiterbares Datenmodell. Synchronisationsmechanismen auf der Basis sogenannter Konnektoren und Join Engines ermöglichen den Datenimport und -export. Mit Hilfe von Script- Sprachen und programmiertechnischen Erweiterungen in Form von Application Program Interfaces (APIs) sind komplexere Regeln und Arbeitsabläufe modellierbar. Die Abbildung zeigt das Integrationsszenario für die Einführung und Anwendung des Meta Directory an den Thüringer Hochschulen. Abbildung: Meta-Directory-Szenario an den Thüringer Hochschulen
Anlage Systembeschreibung und Daten zur RDV Meta Directory Seite 3 von 15 Die Datenbanken der Hochschulverwaltung und der Bibliothek sind Datenquellen für das Meta Directory. Über die entsprechenden Synchronisationsmechanismen werden lediglich die für das Identitäts- und Rollenmanagement und die Anwendungen des Meta Directory benötigten Daten übernommen. Dabei steht HISSVA für die notwendigen Daten der Beschäftigten, HISSOS für die notwendigen Studierendendaten und das lokale Bibliothekssystem LBS für die notwendigen Daten der Bibliotheksbenutzer. Die zusätzliche Datenbank THUAPOS als Organisationssystem für andere Personen dient der Aufnahme von notwendigen Personendaten, die nicht aus den Datenbanken der Hochschulverwaltung und der Bibliothek gewonnen werden können, wie zum Beispiel für Gäste der Thüringer Hochschulen. Eine wichtige Anwendung des Meta Directory ist der Bereich der Authentifizierung und Autorisierung. LDAP-fähige Internetportale ermöglichen eine Anmeldung von Benutzern und die Zuteilung von Rechten mit Hilfe von Verzeichnisdiensten, die ein so genanntes Authentifizierungs- und Autorisierungssystem bilden. Auch der Zugriff auf das Drahtlosnetzwerk (WLAN) und die Anmeldung im Virtual Private Network (VPN) an der jeweiligen Hochschule erfolgt über den Authentifizierungsservice. Das Authentifizierungs- und Autorisierungssystem erhält die notwendigen Benutzerdaten über einen Konnektor vom Meta Directory. Auf der Grundlage dieses integrierten Verfahrens ist eine einheitliche Anmeldung für WLAN, VPN und Portalfunktionalitäten realisierbar. Provisioning an den Thüringer Hochschulen bedeutet, allen Beschäftigten, Studierenden und Bibliotheksbenutzern die für ihre rechnergestützte Arbeit notwendigen Ressourcen zur Verfügung zu stellen. Bisher erforderte das aufwendige Routinetätigkeiten der Benutzeradministration. Die Benutzeradministration umfasst beispielsweise das Einrichten der E-Mail-Adresse mit Mailbox, die Ausgabe der Thüringer Hochschul- und Studentenwerkskarte thoska+, sowie die Eintragung als Benutzer in den betriebssystemorientierten Verzeichnissen der Rechnerpools, sowohl zentral im Rechenzentrum als auch dezentral in den Fakultäten und Fachgebieten. Die Arbeit der Administratoren erfährt durch Standardkonnektoren des Meta Directory zu den betriebssystemorientierten Verzeichnissen, wie z.b. Microsoft Active Directory Services (ADS) für Windows oder Novell Directory Services (NDS) für verschiedene Betriebssysteme, eine wesentliche Unterstützung. Diese betriebssystemorientierten Verzeichnisse übernehmen die Daten aus dem Meta Directory, wobei die Autonomie der dem Meta Directory im Sinne eines Zielsystems nachgeordneten administrativen Bereiche erhalten bleibt. Ein Abgleich der Daten mit dem Meta Directory findet nur bei Bedarf statt. Das System zur Selbstauskunft gibt allen im Meta Directory verzeichneten Personen die Gelegenheit, die über sie im Meta Directory gespeicherten Daten zu überprüfen. Der Zugriff erfolgt nur aus dem Rechnernetz der jeweiligen Hochschule lesend ausschließlich auf die eigenen Daten. Die elektronische Selbstauskunft ist eine wichtige Voraussetzung für die informationelle Selbstbestimmung. Zu den klassischen Aufgaben von Verzeichnisdiensten zählen elektronische Adressund Telefonbücher. Im Zusammenhang mit dem E-Mail-System wird die hochschulinterne Abfrage von E-Mail-Adressen angeboten. Ein hochschulinternes elektronisches Telefonbuch setzt aktuelle Daten aus dem Bestand der Telekommunikationsanlage (TK-Anlage) voraus.
Anlage Systembeschreibung und Daten zur RDV Meta Directory Seite 4 von 15 Verzeichnisdienste spielen auch eine wichtige Rolle beim Aufbau einer Public Key Infrastructure (PKI) für Anwendungen mit erhöhten Sicherheitsbedürfnissen, beispielsweise bei der elektronischen Prüfungsverwaltung. Eine PKI ist die Voraussetzung für den Übergang von der Authentifizierung durch Benutzername/Passwort zur zertifikatsbasierten Anmeldung, für das Signieren von Dokumenten und E-Mails sowie für die Verschlüsselung. Die jeweilige Hochschule benötigt für den Aufbau einer PKI eine vertrauenswürdige Zertifizierungsinstanz, welche die Identität der zu registrierenden Benutzer beglaubigt. Die organisatorischen Abläufe zur Erstellung und Verwaltung von Zertifikaten können durch das Meta Directory optimiert werden. Die zahlreichen durch das Meta Directory unterstützten Anwendungen erfordern auch die Abspeicherung personenbezogener Daten im Meta Directory. Die benötigten Datenfelder werden im Folgenden näher erläutert. 2. Personenbezogene Daten des Meta Directory und ihre Anwendungen 2.1. Personenbezogene Daten im Überblick Die Spezifikation der Daten, die im Meta Directory abgespeichert werden müssen, erfolgt in Abhängigkeit von den bereits weiter oben beschriebenen, zu integrierenden Anwendungen. Der hier definierte Datensatz ist thüringenweit einheitlich und stellt einen Konsens dar, der sich aus den unterschiedlichen Prioritäten an den beteiligten Hochschulen ableitet. Die benötigten personenbezogenen Daten lassen sich prinzipiell in drei Kategorien einteilen: Daten zur Identifizierung von Personen und zum Aufbau eines hochschulweiten Identity Managements, anwendungsorientierte personenbezogene Daten sowie technisch orientierte Daten zum Aufbau der verzeichnisinternen Strukturen Technisch betrachtet werden die Daten auf Verzeichniseinträge für Personen, Rollen und Kontakte abgebildet. Eine Person kann dabei mehrere Rollen und mehrere Kontakte besitzen. Ein Beschäftigter kann beispielsweise gleichzeitig als Student eingeschrieben und Bibliotheksbenutzer sein. Rollen dienen der Abbildung komplexerer Zusammenhänge, wie zum Beispiel der Vergabe von Rechten entsprechend der organisatorischen Zugehörigkeit. Ein weiteres technisches Detail ist die Verwendung von Assoziationen. Eine Objekt-Assoziation stellt eine eindeutige Referenz zwischen einem Eintrag im Meta Directory und dem Objekt in dem angeschlossenen System her. Die Assoziation ist ein verzeichnisinternes Attribut, das nicht ausgelesen wird. Die Tabelle gibt zunächst einen Überblick über die im Meta Directory der Thüringer Hochschulen vorhandenen Daten. Lfd. Nr. Daten (Attributbezeichnung im Meta Directory) 1. Familienname (surname, sn) 2. Vorname (givenname) 3. Namensvorsätze (thuedunameprefix) Kurzbeschreibung Identifizierung von Personen und Generierung von Basisdaten, z.b. E-Mail-Adresse, Anzeigename Siehe 1. Siehe 1.
Anlage Systembeschreibung und Daten zur RDV Meta Directory Seite 5 von 15 Lfd. Nr. Daten (Attributbezeichnung im Meta Directory) 4. Namenszusätze (thuedunameextension) 5. Titel (thuedutitle) 6. Akademischer Grad (thueduacademictitle) 7. Künstler- oder Ordensname (thuedupseudonym) 8. Anzeigename (displayname) 9. Anrede (thuedusalutation) 10. Geburtsdatum (thuedudateofbirth) 11. Geburtsname (thuedunameatbirth) 12. Geburtsort (thueduplaceofbirth) 13. Benutzername (uid) 14. Passwort (thuedusimplepassword) 15. E-Mail-Adresse (mail, rfc822mailbox) 16. Bevorzugte Sprache (preferredlanguage) 17. Benutzerzertifikat (usercertificate) 18. Chipkartennummer (thueducardnumber) 19. Zugehörigkeit (edupersonaffiliation) 20. Primäre Zugehörigkeit (edupersonprimaryaffiliation) 21. Berechtigungen (edupersonentitlement) 22. Tage bis zum Ablauf der Gültigkeit (thuedudaystoexpire) 23. Status eines Personen- oder Rolleneintrages (thuedustatus) 24. POSIX-GECOS-Informationsfeld (gecos) 25. POSIX-Gruppennummer (gidnumber) 26. Benutzerverzeichnis (homedirectory) 27. Login Shell (loginshell) Kurzbeschreibung Siehe 1. Siehe 1. Siehe 1. Siehe 1. Generierter Anzeigename eines Benutzers Repräsentation des Geschlechts einer Person für die Identifizierung und eine korrekte Kontaktaufnahme Eindeutige Identifizierung von Personen beim Auftreten von Namenskonflikten Siehe 10. Siehe 10. Login-Name einer Person für die Benutzung von IT-Diensten der Hochschule Initiales Passwort zur Synchronisation mit anderen Verzeichnissen Generierung einer E-Mail-Adresse für die Benutzer der IT-Dienste der Hochschule bevorzugte Sprache eines Benutzers für mehrsprachige Anwendungen Zertifikatsbasierte Authentifizierung und Zertifikatslebenszyklus Von spezifischen Anwendungen benötigte Chipkartennummern Bildung von Benutzergruppen und Vergabe von Rechten in den IT-Systemen der Hochschule Spezifikation der dominierenden Beziehung einer Person zur Hochschule Rechte eines Benutzers für spezifische Ressourcen Aus einem Ablaufdatum generierter Wert für die Gültigkeit eines Verzeichniseintrages Status eines Personen- oder Rolleneintrags im Meta Directory für die Abbildung des Lebenszyklus zusätzliche Benutzerinformationen für Anwendungen in POSIX-konformen Systemen Nummer der Unix Gruppe in der ein Benutzer Mitglied ist Verzeichnispfad eines Benutzers für seine Dateien(Home Directory) Login Shell für POSIX-konforme Systeme
Anlage Systembeschreibung und Daten zur RDV Meta Directory Seite 6 von 15 Lfd. Nr. Daten (Attributbezeichnung im Meta Directory) 28. POSIX-Benutzernummer (uidnumber) 29. Rollentyp (thueduroletype) 30. Personalkategorie (thuedujobtype) 31. Funktion (thuedufunction) 32. Name der Organisation (Hochschule) (organizationalname, o) 33. Strukturzugehörigkeit (organizationalunitname, ou) 34. Kostenstelle (thueducostallocation) 35. Sachkontonummer (thueduimpersonalaccountnumber) 36. Rollenspezifische Benutzerkennung (thueduuserid) 37. Bibliotheksbenutzertyp (thuedulibraryusertype) 38. Bibliotheksbenutzerstatus (thuedulibraryuserstatus) 39. Bibliotheksbenutzernummer (thuedulibrarycodenumber) 40. Studiengang (thueducourseofstudy) 41. Fachsemester (thuedusemesterofcoursestudy) 42. Angestrebter Abschluss (thueduqualification) 43. Hörerstatus (thuedustudenttype) 44. Art des Studiengangs (thueducourseofstudytype) 45. Art des Studiums (thuedustudytype) 46. Immatrikulationsdatum (thuedudateofmatriculation) 47. Studierendenstatus (thuedustudentstatus) Kurzbeschreibung eindeutige Nummer eines Benutzers in einem POSIX-konformen System Rollentyp, wie zum Beispiel Mitarbeiter oder Student Charakter der Beschäftigung zur Ermittlung der primären Zugehörigkeit bzw. der primären Rolle einer Person an der Hochschule Funktionen im Kontext der Hochschule zur Ableitung von Rollen, Rechten und benötigten Ressourcen in den IT-Systemen Festlegung der organisatorischen Zugehörigkeit zu einer Hochschule bei einem Meta Directory für mehrere Hochschulen Ableitung von Rechten und Vergabe von Ressourcen in den jeweiligen Bereichen; Unterstützung der dezentralen Administration Ableitung der Strukturzugehörigkeit und Unterstützung von abrechnungsbezogenen Anwendungen Unterstützung von buchführungsnahen Prozessen in angeschlossenen Systemen Benutzername oder Schlüsselnummer aus angeschlossenen Systemen, die nicht vollständige Namen von Personen erfassen oder diese Kennung zur eindeutigen Identifikation benötigen Abbildung IT-relevanter Eigenschaften und Privilegien für Bibliotheksbenutzer Abbildung IT-relevanter Eigenschaften und Privilegien für Bibliotheksbenutzer Barcode, der mit dem Bibliotheksbenutzerausweis verknüpft ist, z.b. auf der multifunktionalen Chipkarte thoska+ Einordnung von Studierenden zur Abbildung auf Verzeichnishierarchien, Benutzergruppen und Mailing-Listen; Berechtigungsvergabe, beispielsweise für Anmeldevorgänge Siehe 40. Siehe 40. Siehe 40. Siehe 40. Siehe 40. Siehe 40. Datenkonsolidierung und Steuerung des Identitätslebenszyklus für Studierende
Anlage Systembeschreibung und Daten zur RDV Meta Directory Seite 7 von 15 Lfd. Nr. Daten (Attributbezeichnung im Meta Directory) 48. Exmatrikulationsdatum (thuedudateofexmatriculation) 49. Quellenangabe für Kontaktdaten (thueducontactdatasource) 50. Semantikangabe für Kontaktdaten thueducontactsemantics) 51. Telefonnummer (telephonenumber) 52. Telefaxnummer (FacsimileTelephoneNumber) 53. Gebäude (thueduhouseidentifier) 54. Raum (thueduroomidentifier) 55. Straße (thuedupostaladdress) 56. Adresszusatz (thuedupostaladdressextension) 57. Postleitzahl (thuedupostalcode) 58. Stadt (thuedupostalcity) 59. Land (thuedupostalcountry) 60. Homepage (thueduurl) 61. Instant Messaging Number (thueduinstantmassagingnumber) 62. Gültigkeitsdatum /Beginn (thuedustartdate) 63. Gültigkeitsdatum /Ende (thueduexpirydate) 64. Identifikator für Verzeichniseinträge (thueduidentifier, cn, common name) 65. Interne Personalnummer (workforceid) 66. Interne Beschäftigungsnummer (nur zur Objektassoziation verwendet) 67. Interne Seriennummer für die organisatorische Zugehörigkeit (nur zur Objektassoziation verwendet) 68. Matrikelnummer (thuedustudentnumber) 69. Interne Studiengangsnummer (nur zur Objektassoziation verwendet) Kurzbeschreibung Siehe 47. Angabe des Quellsystems zur Ableitung von Aussagen über die Datenqualität Abhängig von der Semantik im Quellsystem, wie zum Beispiel Privat- und Dienstanschrift Telefonnummer für ein Kontaktdatenverzeichnis Telefaxnummer für ein Kontaktdatenverzeichnis Identifizierung des Arbeitsplatzes eines Beschäftigten zur Koordinierung der Ressourcenverwaltung, inklusive des Netzwerkmanagements, sowie für ein Kontaktdatenverzeichnis Siehe 53. Straße und Hausnummer der postalischen Adresse einer Person Erweiterung der postalischen Adresse einer Person Postleitzahl als Bestandteil der postalischen Adresse einer Person Name des Orts als Bestandteil der postalischen Adresse einer Person Name oder Kürzel des Landes als Bestandteil der postalischen Adresse einer Person Referenz auf die Homepage einer Person in Form eines Uniform Ressource Locator (URL) Nummer innerhalb eines Instant Messaging Systems für kurze Textnachrichten Beginn der Gültigkeit einer hochschulspezifischen Rolle oder eines Kontaktdatenobjekts Ablauf der Gültigkeit einer hochschulspezifischen Rolle oder eines Kontaktdatenobjekts Eindeutige Identifizierung von Personen, Rollen und Kontaktdaten innerhalb des Meta Directory, anwendungsunabhängiger Name Eindeutige Zuordnung von Verzeichniseinträgen zwischen Meta Directory und HISSVA Objektassoziation zu den mit HIS vereinbarten Datenstrukturen für Beschäftigte Objektassoziation zu den mit HIS vereinbarten Datenstrukturen für Beschäftigte Eindeutige Zuordnung von Verzeichniseinträgen zwischen Meta Directory und HISSOS Objektassoziation zu den mit HIS vereinbarten Datenstrukturen für Studierende
Anlage Systembeschreibung und Daten zur RDV Meta Directory Seite 8 von 15 Lfd. Nr. Daten (Attributbezeichnung im Meta Directory) 70. Interne Bibliotheksbenutzernummer (nur zur Objektassoziation verwendet) 71. Referenz auf die Rollen (thueduroledn) 72. Referenz auf die primäre Rolle (thueduprimaryroledn) 73. Referenz auf die Kontaktdaten (thueducontactdn) 74. Primäre Referenz auf die Kontaktdaten (thueduprimarycontactdn) 75. Referenz auf den Rolleninhaber bzw. auf den Inhaber der Kontaktdaten (roleoccupant) 76. Referenz auf ein Personenobjekt (seealso) Kurzbeschreibung Eindeutige Zuordnung von Personeneinträgen zwischen Meta Directory und PICA Verzeichnisinterne Referenz von einer Person zu ihren hochschulspezifischen Rollen Verzeichnisinterne Referenz von einer Person zu ihrer primären Rolle Verzeichnisinterne Referenz von einer Person zu ihren Einträgen für Kontaktdaten Verzeichnisinterne Referenz von einer Person zu ihrem primären Eintrag für Kontaktdaten Verzeichnisinterne Referenz von einer Rolle bzw. einem Eintrag für Kontaktdaten zur zugeordneten Person Verzeichnisinterne Referenz von einem funktionalen Account zu zugeordneten natürlichen Personen Tabelle: Überblick zu personenbezogenen Daten im Meta Directory In den nächsten Abschnitten folgt eine detaillierte Aufstellung der einzelnen Datenfelder mit einer kurzen Beschreibung der Anwendung und des Zwecks sowie der Semantik. 2.2. Daten zur Identifizierung von Personen 2.2.1. Familienname, Vorname, Namensvorsätze, Namenszusätze Familienname, Vorname, Namensvorsätze und Namenszusätze dienen der Identifizierung einer Person beim Eintragen in das Meta Directory sowie der Generierung von Basisdaten wie E-Mail-Adresse und ggf. Login-Name. Die Datenfelder Familienname, Vorname besitzen in Verbindung mit dem Geburtsdatum (siehe dort) für die eindeutige Identifizierung einer Person beim Eintragen ihrer Daten in das Meta Directory eine Schlüsselfunktion. Nach erfolgreicher Eintragung stehen die in den Datenbanken HISSVA, HISSOS und LBS eindeutigen Schlüssel zur Identifizierung im Meta Directory zur Verfügung. 2.2.2. Titel und akademischer Grad Titel und akademischer Grad einer Person dienen der korrekten Abbildung eines in Deutschland üblichen Namens. Zu den in Deutschland üblichen Titeln gehören Beamtentitel, wie zum Beispiel Oberregierungsrat, aber auch Professorentitel. Die Datenfelder sind von Seiten der akademischen Anwendungen notwendig. Es gehört zu den Rechten einer Person, mit dem korrekten Titel und/oder dem akademischen Grad angesprochen zu werden. 2.2.3. Künstler- oder Ordensname Der Künstler- oder Ordensname wird zur verlässlichen Generierung einer E-Mail- Adresse bzw. eines Anzeigenamens verwendet.
Anlage Systembeschreibung und Daten zur RDV Meta Directory Seite 9 von 15 2.2.4. Anzeigename Die Verwendung des Anzeigenamens ist rein technisch geprägt. Er wird aus bereits vorhandenen Namensbestandteilen und nach hochschulspezifischen Vorgaben beim Import von Daten in das Meta Directory generiert. Der Anzeigename besteht im Regelfall aus einer normalisierten Kombination von Namensbestandteilen, die z.b. der Anrede oder Identifikation in Systemen dienen. Der Anzeigename soll in künftigen Ausbaustufen des Meta Directory vom Benutzer geändert werden können und ist dann wie eine freiwillige Angabe (siehe Punkt 3.) zu behandeln. 2.2.5. Anrede Die Anrede gibt Auskunft über das Geschlecht einer Person. Es handelt sich dabei um die verzeichnisinterne Repräsentation des Geschlechts. 2.2.6. Geburtsdatum, Geburtsname, Geburtsort Geburtsdatum, Geburtsname und Geburtsort dienen der eindeutigen Identifizierung einer Person beim Auftreten von Namenskonflikten. So können zum Beispiel die im HISSVA verwalteten Beschäftigten gleichzeitig als Student im HISSOS eingeschrieben sein. In diesem Fall muss überprüft werden, ob es sich um ein und dieselbe Person handelt. 2.3. Anwendungsorientierte personenbezogene Daten 2.3.1. Benutzername Der Benutzername spezifiziert den Login-Namen einer Person für die Benutzung von IT-Diensten der Hochschule. Der Benutzername wird beim ersten Eintragen einer Person in das Meta Directory generiert. Der Benutzername wird vom Authentifizierungs- und Autorisierungssystem benötigt und kann auch mit den Benutzerverzeichnissen in den Fakultäten abgeglichen werden. 2.3.2. Passwort Da sich kein Benutzer direkt am Meta Directory anmelden darf, wird das Passwort lediglich zur Passwortsynchronisation mit anderen Verzeichnissen herangezogen. So kann zum Beispiel ein initiales Passwort generiert und anschließend in die angeschlossenen Applikationen synchronisiert werden. Ebenso können vom Benutzer durchgeführte Passwortänderungen in die angeschlossenen Systeme übertragen werden, so dass die Benutzer alle IT-Dienste der Hochschule mit dem gleichen Passwort nutzen können. 2.3.3. E-Mail-Adresse Das Datenfeld E-Mail-Adresse enthält die an der Hochschule gültige E-Mail-Adresse eines Benutzers. Die E-Mail-Adresse wird beim ersten Eintragen einer Person generiert. Eine an der Hochschule gültige E-Mail-Adresse ist die Voraussetzung für den Nachrichtenaustausch zur Organisation des Arbeits- und Studienalltags sowie zur Inanspruchnahme der portalgestützten Dienste, wie die elektronische Anmeldung und Prüfungsverwaltung. 2.3.4. Bevorzugte Sprache Die bevorzugte Sprache dient der Sprachauswahl in lokalisierten, d.h. mehrsprachigen Anwendungen, z.b. personalisierten Portalen oder anderen Webanwendungen. In der Praxis existieren zumeist systemweite, für alle Benutzer geltende Voreinstellungen. Die Verwaltung soll zukünftig durch Benutzer über ein Portal erfolgen, was zu einer Erhöhung des Serviceniveaus bei einer Vielzahl von IT-Anwendungen führen
Anlage Systembeschreibung und Daten zur RDV Meta Directory Seite 10 von 15 soll. Die Standardeinstellung ist deutsch. Andere, vom Beschäftigten vorgenommene Einstellungen sind freiwillig (siehe 3.). 2.3.5. Benutzerzertifikat Die Speicherung des Zertifikats im Verzeichnis unterstützt die zertifikatsbasierte Authentifizierung und den Zertifikatslebenszyklus, insbesondere die Benachrichtigung von Benutzern über den baldigen Ablauf des Zertifikats. 2.3.6. Chipkartennummer Die Chipkartennummer enthält anwendungsspezifische Nummern von einer oder mehreren Chipkarten, die einer Person oder deren Rollen zugeordnet sind. Die Chipkartennummer(n) werden benötigt, um sie in die entsprechenden Anwendungen wie zum Beispiel ein Drucksystem, ein Zeiterfassungs- oder Zutrittssystem zu synchronisieren. 2.3.7. Zugehörigkeit und primäre Zugehörigkeit Die Datenfelder für die Zugehörigkeit bzw. die primäre Zugehörigkeit spezifizieren die Beziehung einer Person zur Hochschule auf oberster Ebene. Die Zugehörigkeit bzw. die primäre Zugehörigkeit ermöglichen eine Kategorisierung von Personen und sind damit die Basis für die Bildung von generischen Benutzergruppen und die automatische Vergabe von Rechten in den Zielsystemen. Mögliche Werte für diese Datenfelder sind zum Beispiel Mitarbeiter, Student, Bibliotheksbenutzer und Gast. Der Wert des Datenfeldes für die primäre Zugehörigkeit sollte sich auch bei den Werten für die Zugehörigkeit wieder finden. Außerdem sind auch die Werte für die Rollentypen aus dem Wertevorrat der Zugehörigkeiten abgeleitet. 2.3.8. Berechtigungen Es soll die Vergabe von speziellen Berechtigungen für dedizierte Anwendungen ermöglicht werden. Das eher technisch geprägte Attribut ist vergleichbar mit der Bildung von Benutzergruppen. Es wird generiert oder von einem Administrator gesetzt. Zielsysteme sind alle Anwendungen mit Berechtigungsverwaltung. Die Angabe ist freiwillig (siehe 3.). 2.3.9. Tage bis zum Ablauf der Gültigkeit Der aus einem Ablaufdatum generierte Wert dient der Steuerung des Lebenszyklus von Personen- Rollen- und Kontaktdateneinträgen und damit auch dem allgemeinen Identitätslebenszyklus. Dieses Attribut wird benötigt, um nicht mehr benötigte personenbezogene Daten automatisiert löschen zu können. 2.3.10. Status eines Verzeichniseintrages Der Status von Personen-, Rollen- und Kontaktdateneinträgen im Meta Directory dient der Abbildung von Bearbeitungszuständen in Abhängigkeit von den jeweiligen Arbeitsabläufen. So kann zum Beispiel das Löschen einer Rolle und der damit verbundenen Ressourcen die vorherige Information des jeweiligen Benutzers per E-Mail erfordern. 2.3.11. POSIX-konforme Daten POSIX-GECOS-Informationsfeld, POSIX-Gruppennummer, Benutzerverzeichnis, Login Shell, POSIX-Benutzernummer enthalten Daten für POSIX-konforme Systeme, wie zum Beispiel UNIX/Linux.
Anlage Systembeschreibung und Daten zur RDV Meta Directory Seite 11 von 15 2.3.12. Rollentyp Der Rollentyp erlaubt eine Kategorisierung der personengebundenen Rollen. Die bisher definierten Werte Mitarbeiter, Student, Gast und Bibliotheksbenutzer stellen eine Teilmenge des Wertebereiches für die weiter oben bereits definierte Zugehörigkeit dar. 2.3.13. Personalkategorie Die Personalkategorie gibt Auskunft über den Charakter der Beschäftigung zur Ermittlung der primären Zugehörigkeit bzw. der primären Rolle einer Person an der Hochschule. So ist zum Beispiel ein Studierender, der gleichzeitig als Beschäftigter der Personalkategorie wissenschaftliche Hilfskraft tätig ist, primär als Student anzusehen. 2.3.14. Funktion Das Datenfeld enthält Werte für die Funktionen bzw. Positionen einer Person innerhalb des Kontexts der Hochschule. Beispielwerte sind Rektor, Kanzler, Dekan, stellvertretender RZ-Leiter, Administrator usw. Aus diesen Werten lassen sich Rollen, Rechte und benötigte Ressourcen ableiten. So besteht unter anderem die Möglichkeit, in Abhängigkeit von der Funktion Mailing-Listen zu generieren, um beispielsweise alle Administratoren der Hochschule über eine neue Sicherheitslücke und die entsprechenden Gegenmaßnahmen zu informieren. 2.3.15. Name der Organisation (Hochschule) Die Festlegung der organisatorischen Zugehörigkeit zu einer Hochschule ist bei einem Meta Directory notwendig, das von mehreren Hochschulen benutzt wird. So besteht zum Beispiel die Notwendigkeit, beim Personalisieren der multifunktionalen Chipkarte thoska+ oder bei der Generierung einer E-Mail-Adresse die beteiligten Einrichtungen voneinander zu unterscheiden. 2.3.16. Strukturzugehörigkeit Das Datenfeld für die Strukturzugehörigkeit enthält den Namen einer Organisationseinheit der Hochschule. Aus der Strukturzugehörigkeit sind vor allem Rechte und notwendige Ressourcen in den jeweiligen Organisationseinheiten ableitbar. Es handelt sich dabei um eine wichtige Voraussetzung für die Unterstützung der dezentralen administrativen Bereiche durch das Meta Directory. 2.3.17. Kostenstelle Das Datenfeld spezifiziert die Kostenstelle bzw. die Kostenstellen, denen ein Beschäftigter zugeordnet ist. Von der Kostenstelle leitet sich die Strukturzugehörigkeit ab. Sie wird in einigen Zielsystemen, wie zum Beispiel der Verwaltungssoftware für die TK-Anlage, benötigt. 2.3.18. Sachkontonummer Die mit einer Rolle assoziierte Sachkontonummer dient der Unterstützung von buchführungsnahen Prozessen in angeschlossenen Systemen. 2.3.19. Rollenspezifische Benutzerkennung Die rollenspezifische Benutzerkennung enthält ein Login Kennzeichen oder eine Schlüsselnummer aus einem an das Meta Directory angeschlossenen System. Es dient zur eindeutigen Identifikation einer Person in angeschlossenen datenverarbeitenden Systemen, die z.b. nicht notwendigerweise mit allen Namensbestandteilen arbeiten oder den Inhalt des Attributs als Primärschlüssel für entsprechende Personendatensätze verwenden.
Anlage Systembeschreibung und Daten zur RDV Meta Directory Seite 12 von 15 2.3.20. Bibliotheksbenutzertyp und -status Bibliotheksbenutzertyp und -status beschreiben den Typ bzw. den Status einer Person, gebunden an ihre Rolle eines Bibliotheksbenutzers zur Abbildung IT-relevanter Eigenschaften und Berechtigungen. 2.3.21. Bibliotheksbenutzernummer Die Bibliotheksbenutzernummer ist für den Barcode auf dem Bibliotheksbenutzerausweis bestimmt. Die Aufnahme in das Meta Directory erlaubt die Abstimmung mit der Ausgabe der Thüringer Hochschul- und Studentenwerkskarte thoska/thoska+. 2.3.22. Studiengangs-relevante Daten Die Datenfelder für Studiengang, Fachsemester, angestrebter Abschluss, Hörerstatus, Art des Studiengangs, Art des Studiums, Art des Studiums und Immatrikulationsdatum dienen der Einordnung von Studierenden und ihrer Zuordnung zu den Lehrveranstaltungen. Jeder Studierende kann in mehreren Studiengängen eingeschrieben sein. Jedem Studiengang ist ein Fachsemester zugeordnet, in dem sich der Studierende bezogen auf den betreffenden Studiengang gerade befindet. Angestrebter Abschluss und Hörerstatus sind ebenfalls damit verknüpft. Der Hörerstatus erlaubt darüber hinaus auch die Einteilung in Mitglieder und Angehörige. Die Informationen werden mit jeder Einschreibung und Rückmeldung aktualisiert. Damit existiert die Möglichkeit, Studierende auf Verzeichnishierarchien, Benutzergruppen und Mailing-Listen abzubilden, die von Studiengang, Fachsemester, angestrebtem Abschluss und Hörerstatus abhängen. 2.3.23. Studierendenstatus und Exmatrikulationsdatum Studierendenstatus und Exmatrikulationsdatum werden zu Datenkonsolidierungszwecken heran gezogen, können aber auch für Autorisierungsvorgänge relevant sein. Sie dienen weiterhin der Steuerung des Identitätslebenszyklus. 2.3.24. Quellenangabe für Kontaktdaten Das Datenfeld enthält die Information, aus welchem Quellsystem das Kontaktdatenobjekt stammt (HISSOS, HISSVA, THUAPOS, Bibliothek). Die Herkunft gibt Aufschluss über die Datenqualität und ist wichtig für Systeme mit Qualitätsanforderungen und für Datenkonsolidierung. 2.3.25. Semantikangabe für Kontaktdaten Die Semantik von Kontaktdaten, wie z.b. Adressen, ist abhängig von ihrer jeweiligen Semantik im Quellsystem. Beispiele sind Privat- und Dienstanschrift bei Mitarbeitern, Heimat- oder Semesteranschrift bei Studierenden. Die Zielsysteme entscheiden, welche Kontaktdaten sie benötigen, z.b. wären für ein Telefonbuch nur Dienstanschriften relevant. 2.3.26. Telefonnummer und Telefaxnummer Die Datenfelder enthalten die dienstlichen Telefon- und Telefaxnummern, unter denen eine Person zu erreichen ist. Für die Synchronisation dieses Attributs ist eine Verbindung zur Datenbank der TK-Anlage notwendig. Die Anwendungen für diese Daten reichen vom hochschulinternen elektronischen Telefonbuch über ein umfassendes Kontaktdatenverzeichnis bis hin zum Facility Management im Zusammenhang mit der Bereitstellung von Telekommunikationsressourcen. 2.3.27. Gebäude und Raum Diese Datenfelder identifizieren ein Gebäude und einen Raum der Hochschule, der dem Beschäftigten als Arbeitsplatz zugeordnet ist. Die Datenfelder unterstützen die
Anlage Systembeschreibung und Daten zur RDV Meta Directory Seite 13 von 15 Koordinierung der Verwaltung von Benutzern und technischen Ressourcen, inklusive dem Netzwerkmanagement. 2.3.28. Straße, Adresszusatz, Postleitzahl, Stadt, Land Die Adresse besteht aus den Feldern Straße (Straße und Hausnummer), einem Adresszusatz, einer Postleitzahl, dem Namen der Stadt und dem Namen oder dem Kürzel des Landes. Sie dient der Abspeicherung von postalischen Adressen einer Person für den Abgleich zwischen den Systemen und für ein Kontaktdatenverzeichnis. Die Angabe weiterer als der amtlichen Meldeadressen ist freiwillig (siehe 3.). 2.3.29. Homepage und Instant Messaging Number Die Referenz auf die Homepage einer Person in Form eines Uniform Ressource Locator (URL) oder die Nummer innerhalb eines Instant Messaging Systems für kurze Textnachrichten kann Bestandteil von Kontaktdaten sein und wird ausschließlich durch den Benutzer selbst, z.b. über ein Portal gepflegt. Die Angaben sind freiwillig (siehe 3.). 2.3.30. Gültigkeitsdatum/Beginn, Gültigkeitsdatum/Ende Die Datenfelder spezifizieren das Datum, an dem die Gültigkeit einer hochschulspezifischen Rolle oder eines Eintrags für Kontaktdaten beginnt bzw. abläuft. Grundlage hierfür können zum Beispiel der Rückmeldestatus eines Studierenden oder die Befristung eines Beschäftigten sein. Dieses Datum steuert Prozesse, wie die Änderung der Zugehörigkeit von Student nach Mitarbeiter, andere Statusänderungen sowie die Freigabe der an eine Rolle gebundenen Ressourcen. 2.4. Technisch orientierte Daten 2.4.1. Identifikator für Verzeichniseinträge Der Identifikator dient der eindeutigen Identifizierung einer Person, einer Rolle oder eines Kontaktdateneintrags innerhalb des Meta Directory. Da ein Meta Directory viele Anwendungen unterstützen soll, existiert die Notwendigkeit eines abstrakten anwendungsunabhängigen Namens. Es wird ein 128 Bit großer Globally Unique Identifier (GUID) verwendet, der beim Eintrag in das Verzeichnis generiert wird. 2.4.2. Interne Personalnummer Die Personalnummer identifiziert einen Beschäftigten an der jeweiligen Hochschule eindeutig. Die hier verwendete Personalnummer entspricht nicht der durch die zentrale Gehaltstelle vergebenen Personalnummer. Innerhalb der Datenbank HISSVA sind Beschäftigte über ihre interne Personalnummer lebenslang eindeutig identifizierbar. Damit können nach der Eintragung im Meta Directory die Einträge des Meta Directory und die Beschäftigtendaten des HISSVA durch eine Assoziation mit der internen Personalnummer eindeutig aufeinander abgebildet werden. Für einige hochschulinterne Arbeitsabläufe ist die interne Personalnummer unverzichtbar, wie zum Beispiel für die multifunktionale Chipkarte thoska/thoska+. 2.4.3. Matrikelnummer Die Studierendennummer, auch als Matrikelnummer bezeichnet, identifiziert einen Studierenden an der Hochschule eindeutig und ist lebenslang gültig. Innerhalb der Datenbank HISSOS sind Studierende über ihre Matrikelnummer eindeutig identifizierbar. Damit können nach der Eintragung im Meta Directory die Einträge des Meta Directory und die Studierendendaten des HISSOS eindeutig aufeinander abgebildet
Anlage Systembeschreibung und Daten zur RDV Meta Directory Seite 14 von 15 werden. Für viele hochschulinterne Arbeitsabläufe ist die Matrikelnummer unverzichtbar, wie zum Beispiel bei Einschreibevorgängen. 2.4.4. Interne Beschäftigungsnummer, interne Seriennummer für die organisatorische Zugehörigkeit, interne Studiengangsnummer, interne Bibliotheksbenutzernummer Die Datenbank-internen Nummern dienen der technischen Realisierung einer Objektassoziation zwischen dem Meta Directory und den mit den Quellsystemen vereinbarten Datenstrukturen zur Synchronisation. 2.4.5. Referenzen auf die Rollen, die Kontaktdaten und Referenz auf die primäre Rolle bzw. die primären Kontaktdaten Die Referenzen stellen den verzeichnisinternen Bezug zwischen dem Eintrag einer Person und den jeweils zugeordneten Rolleneinträgen bzw. Kontaktdateneinträgen her. Rollen- und Kontaktdateneinträge werden dabei eindeutig durch ihren verzeichnisinternen Identifikator identifiziert. 2.4.6. Referenz auf den Rolleninhaber bzw. den Inhaber der Kontaktdaten Jeder Rollen- und Kontaktdateneintrag enthält eine Referenz, die den verzeichnisinternen Bezug zu dem jeweiligen Eintrag der zugeordneten Person, also des Rolleninhabers bzw. des Inhabers der Kontaktdaten, herstellt. 2.4.7. Referenz auf die Inhaber eines funktionalen Accounts Funktionale Accounts enthalten Referenzen, die den verzeichnisinternen Bezug zu den zugeordneten Personen herstellen. Dies dient u.a. der besseren Steuerung des Lebenszyklus eines funktionalen Accounts. 3. Behandlung freiwilliger Daten Die nachfolgend genannten Daten sind freiwillig bzw. erhalten durch die Möglichkeit, dass Beschäftigte vorgegebene Standardbelegungen ändern können, den Charakter von freiwilligen Daten. Auf diese Daten sind die Regelungen des 4 der Rahmendienstvereinbarung anzuwenden: Anzeigename (siehe Abschnitt 2.2.4), Bevorzugte Sprache (siehe Abschnitt 2.3.4), Berechtigungen (siehe Abschnitt 2.3.8) und Straße, Adresszusatz, Postleitzahl, Stadt, Land (siehe Abschnitt 2.3.28) Homepage und Instant Messaging Number (siehe Abschnitt 2.3.29). 4. Grundsätze zum Sicherheitskonzept des Meta Directory Das Meta Directory mit sämtlichen darin enthaltenen Daten ist entsprechend der jeweils aktuellen technischen und organisatorischen Möglichkeiten vor Missbrauch, Manipulation und Ausspähung zu schützen. Dazu ist an den jeweiligen Hochschulen ein Sicherheitskonzept auf Basis der Feinspezifikation Spezifikation Meta Directory Stufe 1 der Hochschulen in Thüringen zu erstellen. Es muss vor Inbetriebnahme des Meta Directory vorliegen und insbesondere folgende Punkte regeln:
Anlage Systembeschreibung und Daten zur RDV Meta Directory Seite 15 von 15 Die Aufgabe des Meta Directory besteht darin, konsolidierte Daten über Konnektoren zur Verfügung zu stellen bzw. zu generieren. Keine Applikation erhält ohne einen Konnektor Zugriff auf das Meta Directory. Benutzer haben keinen direkten Zugriff auf das Meta Directory. Benutzer, deren Identitäten im Meta Directory verwaltet werden, können sich nur über ein Portal am Meta Directory anmelden, um Zugriff auf die der jeweiligen Identität zugeordneten Daten zu erlangen. Im Meta Directory werden so genannte funktionsbezogene Benutzer, zum Beispiel für den Zugriff der Konnektoren, verwaltet. Diese funktionsbezogenen Benutzer stellen keine zu verwaltenden Personen im herkömmlichen Sinne dar. Funktionsbezogene Benutzer greifen lesend und schreibend auf das Meta Directory zu. Die Art und Weise des Zugriffs dieser funktionsbezogenen Benutzer ist so zu gestalten, dass die Kommunikationsbeziehungen und der Datenaustausch mit dem Meta Directory auf das erforderliche Mindestmaß eingeschränkt werden. Für die einzelnen Funktionen wird festgelegt, welche Einträge und Attribute der funktionsbezogene Benutzer lesen bzw. schreiben darf. Diese Rechte sind im Sicherheitskonzept zu dokumentieren. Die Verbindung zwischen entfernten Konnektoren auf anderen Rechnern und dem Meta Directory wird ausschließlich verschlüsselt hergestellt. Der Meta Directory Server befindet sich in einem dafür vorgesehenen Servernetz. Dieses Servernetz muss durch geeignete Maßnahmen vor unerwünschtem Zugriff aus dem Internet geschützt sein.