Identitätsmanagement an Hamburgs Hochschulen

Transkript

1 Zeitraum: 11/ /2007 Version 1.0 Autor: Helge Kampf HK-Businessconsulting Kelloggstraße Hamburg Das diesem Bericht zugrunde liegende Vorhaben wurde mit Mitteln des Bundesministeriums für Bildung und Forschung unter dem Förderkennzeichen 01PI05007D gefördert. Die Vertwortung für den Inhalt dieser Veröffentlichung liegt beim Autor.

2 Inhalt I Zusammenfassung, Einordnung und Beitrag zu förderpolitischen Zielen... 5 II Komprimierte Darstellung... 6 II.1 Situation und Kontext zu Beginn des Projektes... 6 II.1.1 Motivation... 6 II.1.2 IT-Infrastruktur... 6 II.1.3 Förderprogramm ecampus... 7 II.1.4 Wechsel der E-Governce-Plattform für Studierende der UHH... 8 II.1.5 Projektorgisation... 8 II.2 Plung und Ablauf des Vorhabens... 9 II.2.1 Zielsetzung... 9 II.2.2 Integratives Identitätsmagement...10 II.2.3 Produkt- und Dienstleisterauswahl...11 II.2.4 Datenschutz und -sicherheit...11 II.2.5 Umsetzungsstrategie und -pl...12 II.2.6 Projekt UHH II.2.7 Projekt HAW II.2.8 Projekt GOLEM...15 II.2.9 Projekt SimSpector...15 II.3 Wissenschaftlicher und technischer Std...17 II.4 Zusammenarbeit mit deren Stellen...18 III Detaillierte Darstellung...19 III.1 Erzielte Ergebnisse...19 III.1.1 Produkt- und Herrstellerentscheidung...19 III Marktalyse und Trends...19 III Hersteller...21 III Produktempfehlung...25 III.1.2 Digitale Identität Versuch einer Definition...26 III Anwendungsfall...26 III Kontexte...26 III Identifikator...27 III.1.3 Grundzüge eines Identitätsmagementsystem...28 III Datenhaltungsdienste...29 III Sicherheitsdienste...29 III Verwaltungsdienste...30 Std: Seite 2 von 82

3 III Mehrwertdienste...31 III.1.4 Hochschulübergreifendes Identitätsmagement...31 III Zentrales vs. verteiltes Verzeichnis...32 III Schichtenarchitektur...33 III Partielle Ebene...34 III Lokale Ebene...36 III Regionale Ebene...37 III Überregionale Ebene...38 III Identifizierung und Registrierung digitaler Identitäten...40 III Datenbereinigung...41 III.1.5 Datenschutzrechtliche Aspekte...41 III Datenarten...41 III Zulässigkeit...42 III Erforderlichkeit, Datenvermeidung und -sparsamkeit...42 III Zweckbindung...42 III Trsparenz und Korrekturrechte...42 III.1.6 IT-Servicemagement...43 III Prozessorientierung...43 III Umsetzungskontext ITIL...44 III.1.7 Identitätsmagementsystem im RRZ der Universität Hamburg (UHH-)..46 III Systemarchitektur...46 III Rechnersysteme und -netze...46 III Applikation...48 III Konzeptuelles Datenmodell und Attribute...49 III IT-Prozess...52 III Identifizieren und Registrieren...52 III (De-)Provisionieren und Archivieren...53 III Zuggsberechtigungen...54 III.1.8 Identitätsmagementsystem der Hochschule für gewdte Wissenschaften Hamburg (HAW-)...55 III IDM-Architektur...55 III Usermagement...56 III Accessmagement...57 III Provisioning...58 III Experiementiersystem HAW Std: Seite 3 von 82

4 III Ausggslage...59 III Migration auf Novell IDM III Projektsachstd...61 III KoOP-Pilotsystem...63 III IM-System KoOP...64 III Hochschulübergreifendes Corporate Directory...65 III.1.9 Ähnlichkeitsprüfung digitaler Personenidentitäten (SimSpector)...66 III Merkmalseigenschaften und -kdidaten...67 III Schreibweisennormalisierung und Alphabet...68 III n-gramm-zerlegung...69 III Bloomfilter...71 III Ähnlichkeitsbestimmung...72 III Digitale Identitäten inspizieren...73 III.1.10 Intermediäres System zur Kopplung von E-Learning-Plattformen (GOLEM)..74 III Systemumgebung...74 III Server...75 III Client Adapter...77 III.2 Voraussichtlicher Nutzens und Verwertbarkeit der Ergebnisse...78 III.2.1 Generelle Aspekte...78 III.2.2 Projektspezifische Aspekte...79 III UHH III HAW III GOLEM...80 III SimSpector...80 III.3 Beispiele ähnlicher Vorhaben bei deren Stellen...81 III.3.1 Codex (Thüringen)...81 III.3.2 Saxis (Sachsen)...81 III.3.3 KIM-IDM (Karlsruhe)...82 Std: Seite 4 von 82

5 I Zusammenfassung, Einordnung und Beitrag zu förderpolitischen Zielen Die förderpolitischen Ziele des hier vorliegenden Verbundprojektes KoOP (Hochschulübergreifende Kooperation für das E-Learning Hamburger Hochschulen) werden prinzipiell im Rahmen von E-Learning-Dienste für die Wissenschaft durch den Förderschwerpunkt Neue Medien in der Bildung zur Etablierung von E-Learning in der Hochschullehre bestimmt. In diesem Verbundprojekt haben sich die Hochschule für bildende Künste Hamburg (HfbK), die Hochschule für Musik und Theater Hamburg (HfMT), die Hochschule für Angewdte Wissenschaften Hamburg (HAW Hamburg), die Universität Hamburg (UHH) mit den zentralen Einrichtungen Rechenzentrum (RRZ) und Interdisziplinäres Zentrum für Hochschuldidaktik (IZHD), das Institut für Informationsmagement Bremen GmbH (ifib) und das Multimedia Kontor Hamburg ggmbh (MMKH) als Konsortialführer partnerschaftlich zusammen geschlossen. Die Partner haben das gemeinsam erklärte Ziel, die vorhdenen Ressourcen und Kompetenzen für das digitale Studieren (E-Learning) effektiv zu vernetzten und zu koordinieren. Dadurch soll eine dauerhafte Qualitäts- und Serviceverbesserung für Studierende und Lehrende erreicht werden. Das Teilvorhaben IT-Magement mit dem Arbeitspaket Identitätsmagement im Rahmen von KoOP fokussieren hauptsächlich auf die Aufgabenfelder Nutzerbetreuung und Integration der IT- und E-Learning-Infrastrukturen mit dem Ziel der Schnittstellenoptimierung aus der Förderlinie E-Learning-Integration mit zusätzlich hochschulübergreifendem Charakter. Ziel der Verbundpartner war im oben berschriebenen Kontext, über einen bewussten Steuerungsprozess die orgisatorische wie auch IT-technische Infrastruktur hochschulintern wie auch hochschulübergreifend dahingehend zu verändern resp. weiterzuentwickeln, um Potenziale im Bereich Studien begleitender Vorgänge durch prozessuale und technische Innovation der IT-Ldschaft auszuschöpfen und diese teilw. im Nachgg in eine systematische und nachhaltige Nutzung überführen zu können. Die den Hamburger Hochschulen entwickelten hochschulübergreifenden, intermediären und föderativen sowie kostensparenden Identitätsmagementkonzepte und die nachfolgende Erprobung hd entsprechender Labor- und Pilotsysteme haben Wege aufgezeigt, wie autorisierte, gesicherte, verzögerungsfreie und je nach Nutzergruppe abgestufte Zugänge zu resp. Zugriffe auf wissenschaftliche Lern- und Lehrmaterialien sowie Community-Foren aber auch Verwaltungsdaten, z. B. Prüfungsdaten, implementiert werden können. Hierdurch wird, gerade in Hinblick auf den Bologna-Prozess, eine Basis begründet, über die sich Effizienz, Qualität und Akzeptz in der Nutzung von E-Learning- und eteaching-angeboten weiter steigern lässt. Diese aufgezeigten Wege gilt es als weiterführende strategische Aufgabe, zu konsolidieren und zu erweitern und vor allem zu institutionalisieren, um damit die hochschulweite wie auch hochschulübergreifende Integration von E-Learning, d.h. ihre Prozesse hinsichtlich Wissensvermittlung bzw. Lernkultur strukturiell weiter vorzutreiben und zu etablieren sowie orgisatorische und technische Möglichkeiten zu schaffen, E-Learning- und eteaching-dienste für ein lebenslges Lernen unentgeltlich wie auch gewinnbringend einer wachsenden Klientel ggf. weltumspnend zur Disposition zu stellen. Std: Seite 5 von 82

6 II Komprimierte Darstellung II.1 Situation und Kontext zu Beginn des Projektes II.1.1 Motivation 1 Seit geraumer Zeit ist in der Bundesrepublik Deutschld ein Wdel von der Industrie- hin zur Informations- und Kommunikationsgesellschaft zu beobachten, in deren Produktionsprozessen die Ressource Wissen einen immer größeren Stellenwert einnimmt. Auch fordert die zunehmende Internationalisierung sowie die intensive interdisziplinäre Verzahnung in Gleichtakt mit schneller werdenden Innovationszyklen und sinkender Halbwertszeit des geeigneten Wissens ein flexibles und lebenslges Lernen. Betroffen von diesem Wdel sind hauptsächlich die Bildungsbereiche und damit die Hochschulen per se, die sich im Rahmen ihres Auftrages neuen Aspekten in der inhaltlichen und strukturiellen Wissensvermittlung, -disposition sowie -aufbereitung als auch der Verwaltung in Forschung und Lehre über soziologische wie auch territoriale Grenzen hinweg stellen müssen. Dieser Reform kn sich die Metropolregion Hamburg als Wissenschafts- und Wirtschaftsstdort nicht entziehen, sondern muss sich, dem im Zuge des sog. Bologna- Prozesses steigenden Wettbewerbsdruck Rechnung tragend, aktiv der Vernetzung entsprechender Institutionen in lokaler, (über-)regionaler wie auch internationaler Ausrichtung widmen, um mit Blick auf Forschung Exzellenzzentren resp. cluster zum Aufbau von Wissensallizen zu schaffen und hinsichtlich Lehre Schlagworte wie E-Learning, Distce Learning, Learning on Demd, Computer based Training (CBT) resp. Web based training (WBT) hin zu einem sog. Blended Learning inhaltlich, prozessual und technisch auszugestalten. Diese Migration von einer belehrten zu einer lernenden Gesellschaft führt zum Leitbegriff der digitalen Medienkompetenz und die Aufgabe der Hochschulen Hamburgs wird es u. a. sein, jetzt und in Zukunft, gemeinsam diese Kompetenz mit infrastrukturiellen Mechismen in orgisatorischer wie auch technischer Sicht zu unterstützen, um den effektiven und effizienten Umgg mit neuen Informationsträgern und kälen resp. deren Inhalte zu ermöglichen. Damit Hamburg zu einem modernen, leistungsstarken, serviceorientierten, effizienten und wettbewerbsfähigen Wissenschaftsstdort werden kn, gilt es der o. g. Herausforderung gerecht zu werden. Zu diesem Zweck entstden Initiativen und Aktivitäten im Rahmen diverser, hauptsächlich vom BMBF und dem Ld Hamburg geförderter Projekte, in das sich das hier betrachtete Vorhaben KoOP komplementär, aber auch weiterführende Aktivitäten schiebend eingliedert. II.1.2 IT-Infrastruktur Die jeweiligen IT-Orgisationen der Hamburger Hochschulen sind unterschiedlich gestaltet, sind aber im Wesentlichen dezentral orientiert. Durch den Betrieb getrennter Netzwerkstrukturen besteht allen Hochschulen eine technische Aufspaltung zwischen dem Verwaltungsbereich und dem wissenschaftlichen Bereich, so dass die E-Governce- und E- Learning-Plattformen getrennt voneinder betrieben werden. Die IT-Versorgung der Verwaltung ist entscheidend abhängig vom Netzwerk der Freien und Hsestadt Hamburg (FHHNET) und den dort betriebenen Anwendungen. Zur Erfassung der 1 Die hier beschriebenen Beweggründe betreffen mehr oder weniger alle Hochschulen Hamburgs, sodass hier grundsätzliche, einheitliche Gründe und Hauptmotive niedergelegt sind. Std: Seite 6 von 82

7 studentischen Identitäten werden zentraler Stelle in den Hochschulen z. B. Anwendungen der HIS GmbH und zum Teil FlexNow, ein Produkt der Universität Bamberg, genutzt. Die HISSysteme (insbesondere das Zulassungsmodul HISZUL und das Studentenverwaltungsmodul HISSOS) werden im FHHNET betrieben. Die Mitarbeiterdaten der Hamburger Hochschulbeschäftigten werden in dem Personalverwaltungssystem PAISY erfasst und geführt. Davon unabhängig werden z. B. der HAW die Verwaltungsmitarbeiter/innen zusätzlich im Verzeichnisdienst (Active Directory) parallel erfasst und administriert. Betrachtet m aus der Sicht der Identitätsdatenerfassung bei Beginn der Zugehörigkeit einer Person zur jeweiligen Institution (Immatrikulation oder Arbeitstritt), entdeckt m durchaus Gemeinsamkeiten in den zur Erfassung von Identitätsdaten verwendeten Applikationen. Durch die physikalische Trennung des Verwaltungsnetzes vom Wissenschaftsnetz ist jedoch kein direkter technischer Zugg (z. B. in Form eines so gennten Konnektors) zu diesen Personendatenerfassungssystemen (Datenbken) möglich allerdings ist die semiautomatische Übermittlung der erforderlichen Daten in Form einer Datei realisierbar. Da ein direkter Übergg zwischen den Netzen nicht existiert, werden die hochschuleigenen Benutzer- resp. Accountverwaltungen mehr oder weniger mittelbar, d.h. teilautomatisiert oder gar händisch gepflegt. Jede Hochschule erfasst seine Dienstenutzer, d.h. Bedienstete, Studierende, Gäste usw. dezentral, sodass makroskopisch betrachtet für eine natürliche Person mehrere digitale Identitäten existieren können. Hierbei kn es aufgrund eines fehlenden zentralen resp. föderativen Identitätsmgement bei gemeinsamer Nutzung bestimmter E- Learning-Anwendungen zu ungewollten Dubletten kommen. Ein allumfassende Aufbau- wie auch Ablauforgisation mit dedizierten Servicevereinbarungen für die Verteilung rollenbasierter Zugriffs- und Nutzungsberechtigungen von E-Learning- Diensten, die für die Workflow-Gestaltung in den entsprechenden IT-Systemen dient, existiert innerhalb der Hochschulen wie auch über sie hinweg nicht oder nur rudimentär. II.1.3 Förderprogramm ecampus Ziel von ecampus 2, ein im Rahmen des elearing-förderprogramm der Behörde für Wissenschaft und Forschung der Hsestadt Hamburg (BWF) gefördertes Projekt, ist es, hochschulübergreifend die Modernisierungspotentiale neuer IuK-Technologien im Bereich der Verwaltung, des Hochschulmarketings und der Lehr- und Forschungsorgisation zu bewerten und gemeinsame Hdlungsvorschläge zur Entwicklung integrierter Dienstleistungen zu entwickeln. Während der ersten Phase des o. g. Vorhabens (Abschluss Frühjahr 2006), kurz ecampus I, befasste sich die Arbeitsgruppe Basisdienste mit der Thematik Authentifizierung, Autorisierung und Accounting (triple A), insbesondere unter dem Aspekt des sog. SSO (Single Sign- On), darauf abzielend, für die Hochschulen Hamburgs eine ldesweite Identity Magement Lösungen 3 konzeptionell unter Berücksichtigung bereits bestehender bzw. geplter Verzeichnisdienste und der am Markt existierenden Ansätze zu diskutieren. Die zweite Phase (Beginn Frühjahr 2007), kurz ecampus II, hat nun zum Ziel, über ein Identity Magement Systems einen konsolidierten Bestd der Studierenden- und Mitarbeiter- Identitäten der Hamburger Hochschulen bereit zu stellen, grundlegende Verfahren für das vgl. M. Gennis, S. Gradm, S. Winklmeier: IDM@eCampus.HH Identity Magement am Hochschulstdort Hamburg; In: Proceedings of the 1st Workshop Integriertes Informationsmagement Hochschulen (IIM 2007), Karlsruhe, Deutschld, März 2007, S , ISBN Std: Seite 7 von 82

8 Magement dieser Identitäten zu etablieren und dieses System soweit möglich in Teilbereichen auch schon operational verfügbar zu machen. II.1.4 Wechsel der E-Governce-Plattform für Studierende der UHH Parallel zum Aufsetzen einer neuen modernen Lösung für das Identitätsmagement resp. der Ablösung der obsoleten zentralen Benutzerverwaltung fd der UHH ein Wechsel der E-Governce-Plattform für Studierende statt, sodass für beide Vorhaben eng verzahnte Abstimmunsprozesse im jeweiligen Projektfortschritt notwendig waren. Die Einführung des Studienaufbaus in den Bachelor-Master-Studiengängen erfordert gerade in Hinblick auf Studien begleitende Prüfungen einen höheren Aufwd Administration. Gleichzeitig sollen die Studierende in die Lage versetzt werden, ihr Studium relativ ortsunabhängig orgisieren, kontrollieren und gestalten zu können, indem das Campusmagementsystem STiNE 4 als neue Governce-Plattform u. a. folgende Dienste zur Verfügung stellt: Online Bewerbungen Verstaltungsauswahl Anzeige der zu absolvierenden Module und Links zu Prüfungsordnungen Informationen über Voraussetzungen zu Verstaltungen und Vorbereitungsmaterialien Abfrage der erbrachten Studienleistungen Bescheinigungen Änderungsmitteilungen wie beispielsweise Adresskorrekturen. Diese intensive Einbindung der Studierenden, wie auch die der Lehrenden und Verwaltenden, in die jeweiligen IT-gestützen Prozesse im Universitätsalltag führt unweigerlich zu einem rollenspezifischen und differenziert autorisierten Zugg zu involvierten IT-Ressourcen resp. IT-Services. II.1.5 Projektorgisation Im Rahmen des vom BMBF geförderten Projektes KoOP (Konzeption und Realisierung hochschulübergreifender Orgisations- und Prozessinnovation für digitales Studieren ) sollen mit Unterstützung orgisatorischer und infrastrukturieller Mechismen die sog. digitale Medienkompetenz gesteigert werden. Zu diesem Zweck haben sich folgende Hochschulen Hamburgs resp. hochschulnahe Einrichtungen zu einem Verbundprojekt zusammengeschlossen: Hochschule für bildende Künste (HfbK) Hochschule für Musik und Theater Hamburg (HfMT) Hochschule für Angewdte Wissenschaften Hamburg (HAW) Universität Hamburg (UHH) mit den zentralen Einrichtungen Rechenzentrum (RRZ) und Interdisziplinäres Zentrum für Hochschuldidaktik (IZHD) Institut für Informationsmagement (ifib) Mulitmedia Kontor Hamburg ggmbh (MMKH) Das Gesamtvorhaben untergliedert sich in zwei Themenblöcke: IT-Magement Schaffung einer neuen Lern- und Lehrkultur - Awareness 4 Studien-Infonetz (s. ) Std: Seite 8 von 82

9 Aus diesen Themenblöcken entspringen sich mehr oder weniger gegenseitig bedingende Hdlungsstränge, in denen unterschiedliche Schwerpunkte hinsichtlich infrastrukturielltechnologischer Architekturen einerseits und orgisationskultureller Prozesse dererseits gesetzt sind. Das Teilvorhaben der UHH lässt sich unter den Punkt IT-Magement subsumieren, dessen Aufgabenspektrum inhaltlich u. a. die Entwicklung entsprechender Basisdienste zur Schaffung bestimmter IT-Infrastrukturen für die Integration von E-Governce- und E-Learningplattformen beinhaltet, um einen effektiven Zugg zu digitaler Lernmaterialien und Medien und deren effiziente Nutzung zu gewähren. II.2 Plung und Ablauf des Vorhabens II.2.1 Zielsetzung Mit Anlauf des Projektes existierten getrennt voneinder operierende E-Governce- und E-Learning-Plattformen in getrennten Netzen, die aber aus Effizienz- und Akzeptzgründen interagieren sollen und auch müssen; dies zum einen, um z. B. den Administrationswd redundt gehaltener Daten in verschiedenen Benutzer- resp. Accountverwaltungen drastisch zu reduzieren, und zum deren, um dem Anwender einen unifizierten und komfortablen Zugg für die Nutzung der bereitgestellten Diensten der unterschiedlichen Applikationssysteme beider Plattformen in Hinblick auf Verstaltungs-, Studierenden-, Zulassungsund Prüfungsverwaltung zu ermöglichen. Im Zuge der Bachelor/Masterstudiengänge werden sicher auch althergebrachte Prozesse verändert werden müssen, aber auch die Bereitstellung weiterer elektronischer Dienste (z. B. elektronische Klausuren, Self-Assessment, elektronische Leistungsnachweise usw.), die nicht losgelöst einem Inseldasein frönen können, wird ins Spiel kommen. Gleichzeitig müssen aus den eben gennten Gründen effektive Prozesse und Orgisationen aufgesetzt werden, die den IT-Betrieb und -Produktion flkieren, um die Bereitstellung der Dienste resp. Applikationen zu sichern und den Anwender in deren Nutzung zu unterstützen. Diese prozessorientierte Sichtweise führt ggf. zum Aufbrechen bestehender orgisatorischer und technischer Strukturen mit ihren hierarchischen und funktionalen Barrieren, sodass teilw. rezentralisierende und/oder föderale Architekturen mit ausgeprägten Vertrauensstellungen entstehen werden. Eine direkte Kopplung der Applikationssysteme der Plattformen E-Gorvernce und E- Learning scheint aus datenschutzrechtlichen, inhaltlichen und/oder systemischen Aspekten heraus evident nicht gegeben, so dass hier ein oder mehrere intermediäre Systeme, die I- dentitätsmagementdienste liefert, zum Einsatz kommen müssen, über die dn dezidierte (Teil-)Objekte im Zugriff beider Plattformen stehen. Über diesen Weg der indirekten Interoperabilität wird eine logische Interaktivitätsmöglichkeit beider Plattformen konstruiert und die Netztrennung überwunden. In diesem gesamten Spnungsfeld gilt es, involvierte Sachverhalte zu thematisieren und die Gesamtproblematik der Interdependenzen der involvierten IT-Systeme zu erfassen und zu erörtern. Gleichzeitig müssen aus den eben gennten Gründen effektive Prozesse, Orgisationen und Vereinbarungen aufgesetzt werden, die den IT-Betrieb und -Produktion flkieren, um die Bereitstellung integrierter und konvergierender Dienste resp. Applikationen zu sichern und den Anwender aller Hochschulen Hamburgs in deren Nutzung zu unterstützen. Diese prozessorientierte Sichtweise führt ggf. zum Aufbrechen bestehender orgisatorischer und technischer Strukturen mit ihren hierarchischen und funktionalen Barrieren, so- Std: Seite 9 von 82

10 dass teilw. rezentralisierende in Relation zu dezentralen föderalen Architekturen mit ausgeprägten Vertrauensstellungen entstehen werden. Durch die Einführung einer mit den Projektpartnern abgestimmten Gesamt-IDM-Lösung soll eine zukunftssichere, flexible und auf einer stdardisierten Architektur aufbauende Lösung für die Verwaltung der Identitäten im Hochschulverbund geschaffen werden. Die Lösung muss die Daten- und damit die Informationsqualität verbessern sowie die Durchlauf- und Bearbeitungszeiten nachhaltig reduzieren, um vor allem den Studierenden, sowohl als Kunden der jeweiligen Hochschule wie auch im Rahmen gemeinschaftlicher E-Learning- Angebote wiederum als Kunden aller Hochschulen Hamburgs, einen reibungslosen Zugg zu entsprechenden IT-Systemen zu ermöglichen. Zudem muss die gestrebte Lösung dem internationalen Charakter der Hochschulen Rechnung tragen. Die Abdeckung der gesamten Komplexität der heterogenen IT-Infrastruktur steht im Vordergrund, um mit kalkulierbaren Aufwänden die benötigte Datenkonsolidierungen zu erreichen. Um dies zu erreichen und den aktuell funktionierenden Betrieb aufrechtzuerhalten, werden Teile der neuen Gesamt-IDM-Lösung temporär als produktive Parallelwelt aufgebaut. Diese Strategie ermöglicht eine schrittweise, sog. weiche Migration der involvierten Benutzer- resp. Accountverwaltungen gebotener Services ohne Beeinträchtigung der Funktionalität, die für den Endbenutzer weitgehend trsparent vonstatten geht. II.2.2 Integratives Identitätsmagement Als integratives Identitätsmagement (IDM) sei hier die Verwaltung von Entitäten (Personen und Objekten) mit ihren in einem bestimmten Kontext eingenommenen, mit bestimmten Rechten versehenen Rollen verstden. Hierfür wird jeder Entität den sie beschreibenden Merkmalen ein eindeutiger Identifikator zugeordnet. Das hier betrachtetet IDM stellt hauptsächlich auf die technische Gestaltung von Prozessen unter dem Aspekt der Effizienz, Flexibilität sowie Sicherheit ab und weniger auf den soziologischen Tenor, dem Recht auf informationeller Selbstbestimmung von Personen (Hdeln unter Pseudonymen), ohne jedoch datenschutzrechtliche Bestimmungen aushebeln zu wollen. Grundlegender Zweck der Verwaltung von Personenidentitäten ist die Schaffung und Löschung eineindeutiger digitaler Identitäten sowie deren Verteilung, um somit Zugriffe auf IT- Ressourcen (z. B. E-Learningwendungen und deren Module, ITSysteme und Netzinfrastruktur usw.) abzusichern; d.h. erlöschen für eine Person bestimmte, ihr zugeordnete Zugriffsrechte auf IT-Ressourcen z. B. durch Ausscheiden als Mitarbeiter oder Exmatrikulation als Studierender, so werden der entsprechenden Person die vergebenen Zugriffsrechte zeitnah entzogen, und der Zugriff auf die bestimmten IT-Ressourcen ist blockiert. Das IDM soll Mechismen wie Single-Sign-On (SSO) und/oder Passwortsynchronisation unterstützen, sodass nach einmaligem Login und nach Passwortänderung zeitnah die Identität eines Nutzers für einen bestimmten Zeitraum für den jeweiligen Anwendungsprozess auf ggf. unterschiedlichen dedizierten Systemen gesichert zur Verfügung steht und der Nutzer somit auf alle Ressourcen seiner Rolle und Berechtigung (Autorisation) gemäß zugreifen kn. Dieser Eintritt in das System kn ggf. qualifiziert über ein entsprechendes Authentisierungsverfahren erfolgen, das mittels Verifikationsmethoden die Urheberschaft (Authentizität) des Logins überprüft und damit die reale Identität des Nutzers konstatiert und ihn somit identifiziert. In diesem Gesamtszenario hält auch der Begriff der Provisionierung Einzug, der den umfassenden Prozess beschreibt, der für die Automatisierung aller Schritte sorgt, die für die Synchronisation, Bereitstellung und Verwaltung von Benutzer- oder System-Zugriffsberechtigungen auf Basis von rollenbasierten Zugriffskontrollkonzepten in Hinblick auf die heterogenen Zielsysteme der Plattformen E-Governce und E-Learning notwendig sind. Std: Seite 10 von 82

11 Das konzertierte Hdeln mehrerer Hochschulen im Dissens zur ihren Autonomien lässt vermuten, dass das zugrunde liegende System eine föderative vernetzte Struktur aufweisen wird, die aber unter Zuhilfenahme von Replikations-, Verweis- und Weiterleitungsmechismen (z. B. Chaching, Shadowing, Referrals, Chaining, Multicast, Provisioning etc.) makroskopisch betrachtet wie ein zentrales System mit den entsprechenden Vorteilen wirken kn. Als infrastrukturielle Basistechnologie haben sich Systeme wie (Meta-)Verzeichnisse mit ihren dazugehörigen Diensten etabliert. Konkret in diesem Kontext zu betrachtete Entitäten wären Personen, Orgisationen, Räume, Verstaltungen und IT-Infrastrukturkomponenten mit ihren Relationen zueinder, aber auch die Korrelationen (trsitive Relationen) in Bezug auf weitere Abhängigkeiten. II.2.3 Produkt- und Dienstleisterauswahl Nach Sichtung des Marktes und Produktevaluation infrage kommender Datenhaltungsdienste mit integrierbaren Identitätenmagementfunktionalität fiel die Wahl auf das Identitätenrepository der Fa. Novell mit dem Verwaltungstool Identity Mager Vers. 3 (kurz IDM3) auf Basis des Verzeichnisdienstes e-directory. Der IDM3 ist zuständig für die Synchronisation der Daten und Durchsetzen der für diesen Synchronisationsprozess formulierten und aktivierten Policies zwischen dem e-directory und den geschlossenen Systemen. Die über uni- resp. bidirektionale Konnektoren (Subscriber und/oder Publisher im Identity Mager Driver) gebundenen Systeme können u. a. aus Anwendungen, Verzeichnisdienste, Datenbken sowie Dateien bestehen. Die Metadirectory Engine verarbeitet Daten und Ereignisse aus dem edirectory unter Nutzung von XML-Dokumenten. Hierbei verwendet sie entsprechende Policies, ihren Regelprozessor und ihre Datentrsformationsmaschine. Im edirectory, werden die Identitätendaten baumartig orgisiert und mit Hilfe von Objektklassen und -attributen abgespeichert, wobei das proprietäre Kommunikationsprotokoll NDAP (Novell Directory Access Protocol) für den Datenaustausch zwischen IDM3 und edirectory verwendet wird. Gleichzeitig zur Produktauswahl wurde mit der Fa. Computacenter AG & Co. ohg ein externer Dienstleister selegiert, der sowohl Erfahrungen zum o. g. Thema als auch Kenntnisse hinsichtlich des Produktportfolios des Produktherstellers vorweisen kn, das Hamburgische Hochschulumfeld kennt sowie konzernnahe Orgisationsstrukturen beherrscht, wie sie die Universität Hamburg aufweist. Dieser wurde mit der Aufgabe beauftragt, hauptsächlich die das UHH- gestellten Anforderungen technisch und produktspezifisch umzusetzen und ein lauffähiges System dem Rechenzentrumsbetrieb zu übergeben. Mit Arbeitsteilung zwischen externen Dienstleister und RRZ verbleiben dem RRZ die genuinen Aufgabenbereiche wie Projektleitung resp. magement, Prozessdefinition, Implementation in den Gesamtkontext des RRZ sowie Konzeption und Realisierung betrieblicher wie orgisatorischer Maßnahmen. II.2.4 Datenschutz und -sicherheit Ein nicht zu unterschätzender Faktor im Aufbau von Identitätsmagmentsystemen liegt in der Einhaltung datenschutzrechtlicher Kriterien. Da hier personenbezogene Daten verarbeitet werden, wurde der Datenschutzbeauftragte Hamburgs gem. 23 Abs. 4 HmbDSG zu Beginn des Projektes UHH- frühzeitig im Mai 2006 mit einbezogen, indem eine gem. 9 HmbDSG vorgelegte Verfahrensbeschreibung inkl. Systemarchitekturskizze in einem Gespräch erläutert und diskutiert wurde. Bedenken seitens des Datenschutzbeauftragten gab es nicht und es wurde vereinbart, Änderungen im Projekt zeitnah mitzuteilen und eine (erste) Risikoalyse abzuliefern. Std: Seite 11 von 82

12 Ein ähnliches Procedere fd im April 2006 vorweg auch mit den Personalräten statt, jedoch wurden differenziertere Gespräche und Erarbeitung einer entsprechenden Dienstvereinbarung mgels akuten Bedarfs Mitarbeiterdaten werden erst in der zweiten Umsetzungsphase des UHH- betroffen sein auf einen späteren Zeitraum (nach 2006) verschoben. Eine Risikoalyse gem. 8 Abs. 4 HmbDSG wurde parallel zur Spezifikation und Umsetzung von UHH- auf Basis des ITGrundschutzes erstellt. Die hier gewählte Vorgehensweise der Risikoermittlung und bewertung steht im Einklg mit dem Hamburger Datenschutzbeauftragten und nutzt u. a. den Vorteil, nicht individuell mögliche Schwachstellen eruieren und Schadenereignisse zusammenstellen zu müssen, wobei dies einhergehend mit immensen Aufwd aufgrund der Komplexität sowie mit Unsicherheit in der Ermittlung der Schadeneintrittswahrscheinlichkeiten und Bewertung der Restrisiken aufgrund fehlenden fundierten Zahlenmaterials verbunden ist. Der frühe Erstellungszeitpunkt führt dazu, dass gerade bei komplexen Verfahren wesentliche technische und orgisatorische Details nicht festgelegt sein können, so dass unter Nutzung von Erfahrungen aus der Umsetzung über eine iterative Vervollständigung dem Zielkonflikt zwischen der frühzeitigen Erstellung und der Berücksichtigung von technischen und orgisatorischen Einzelheiten begegnet wird. Gleichzeitig liefern die ersten Versionen der Risikoalyse jeweils einen Maßnahmekatalog, wodurch parallel zum Projektverlauf mögliche Risiken und Fehlentwicklungen frühzeitig erknt und vermieden werden können. Das BSI hat für seine IT-Grundschutz-Kataloge Schwachstellen und Bedrohungen resp. Gefährdungen für typische IT-Systeme ermittelt, die eine so hohe Eintrittswahrscheinlichkeit und/oder dezidierte Auswirkungen aufweisen, dass adäquate Maßnahmen ergriffen werden müssen, um IT-Systeme resp. deren Komponenten mit einem normalen resp. geringen bis mittleren Schutzbedarf abzusichern, d.h. mit Umsetzung dieser Maßnahmen das Restrisiko auf ein bestimmtes akzeptables Niveau zu minimieren. Für im IT-Grundschutz nicht behdelte Komponenten oder solche mit einem hohen bis sehr hohen Schutzbedarf muss jedoch eine ergänzende Risikoalyse durchgeführt werden, d.h. es müssen ergänzende Maßnahmen definiert und umgesetzt werden. II.2.5 Umsetzungsstrategie und -pl Allen Realisierungs- und spezifischen Konzeptionsbemühungen vor galt es, ein Rahmenkonzept für hochschulübergreifende IDM-Aspekte als gemeinsame Verständnisbasis zu schaffen, in dem für die hiesige Vorhaben Begriffe soweit und differenziert wie möglich definiert und ihre entsprechenden Assoziationen beschrieben werden. Aufgrund der Komplexität des Zusammenspiels der jeweils betroffenen technischen Systeme, Prozesse und Orgisationseinheiten ist die Gesamtstrategie im hiesigen Projekt und darüber hinaus von einer evolutionär iterativen sowie partizipativen Vorgehensweise geprägt; d.h. ausgehend von Kernsystemen entstehen über mehreren Ausbaustufen in Form von lauffähigen Pilotsystemen, die schlussendlich zu ggf. einem oder mehreren Produktivsystemen konvergieren. Die resultierenden Systeme werden mit jeder Iteration um weitere Funktionalitäten ergänzt und/oder aufgrund gewonnener Erkenntnisse modifiziert, die durch Evaluation der jeweiligen Test- und Pilotsysteme unter orgisatorischen, prozessualen und systemischen begründet sind. II.2.6 Projekt UHH- Im Kontext des Vorhabens KoOP hat das Regionale Rechenzentrum der Universität Hamburg (RRZ) im März 2006 ein internes Projekt aufgesetzt, mit dem Ziel, einen wohldefinierten Übergabepunkt in Form eines IDM-Systems (Arbeitstitel: UHH-) zu schaffen, in dem Std: Seite 12 von 82

13 konsolidierte Identitäten sowohl für die Hochschulen wie auch für die Fakultäten resp. Departments der Universität zur Disposition gestellt werden. Das architektonische Rahmenkonzept hierfür sieht ein 4-Schichtenmodell vor, in denen ebenenspezifisch motiviert IDM mit unterschiedlichen Ausprägungen und Zielsetzungen betrieben wird. Die einzelnen IDM-Systeme in den Schichten sind über Provisionierungsmechismen mit denen ihrer jeweils nächst höheren und nächst niedrigeren sowie ggf. auch innerhalb ihrer Schicht kommunikativ miteinder verbunden und bilden in ihrer Gesamtheit das hochschulübergreifende integrative Identitätsmagement der involvierten Hochschulen. In der untersten Ebene befinden sich die Quell- und Zielsysteme, in denen digitale Identitäten für die IT-Ressourcen-spezifische Nutzerverwaltung, Authentifizierung und Autorisierung ab gelegt sind. Die nächsthöhere Ebene beheimatet orgisationsbezogene IDM-Systeme, deren Kernaufgabe in der Konsolidierung und Schaffung definierter Übergabepunkte liegt hier ist das IDM-System der UHH gesiedelt. Die folgende Ebene loziert das gemeinsame IDM-System der Hochschulen Hamburgs, dessen Ausgestaltung im Rahmen des Projektes ecampus stattfindet diesem System obliegt als Hauptaufgabe die Identifizierung und Registrierung von Identitäten. Die höchste Ebene ermöglicht über föderale Strukturen auf Basis des gemeinsamen IDM- Systems der Hochschulen mithilfe von Protokollen und entsprechenden Verfahren (z. B. Shibboleth, Liberty Allice, PAPI usw.) Vertrauensstellungen zu deren Einrichtungen, die hierüber hinsichtlich Authentifizierung und Autorisierung gegenüber deren Parteien in der Vertwortung stehen. Bei dem Projekt UHH- hdelt es sich hier nicht um die Einführung eines grundsätzlich neuen Verfahrens, sondern um eine Neu- resp. Umgestaltung der am RRZ lozierten zentralen Benutzerverwaltung (kurz ZenBen). Über das neue Verfahren soll zukünftig einen Teil des notwendigen Datenbestdes direkt und automatisiert aus autoritativen Datenquellen bezogen werden und hd bestimmter Policies weitgehend pseudonymisiert und automatisiert dezentrale Benutzer- resp. Accountverwaltungen weiterleiten. Das Konzept des UHH- fußt auf einem LDAP-fähigen Verzeichnisdienst und fokussiert für dessen Attributschemata auf identifizierende Merkmale von Personen mit der Grunderweiterung von Erreichbarkeitseigenschaften (Adresse, Telefon etc.). Außerdem wird auf hochschulübergreifende sowie -assoziierte einrichtungs- und personenkreisbezogene Profile abgestellt, mithilfe derer beim Provisionieren (Verteilen) abgeleitet werden kn, welche (Basis-)Rollen bestimmte Personen in den Zielsystemen, d.h in den Systemen, in denen Zugriffsrechte durchgesetzt werden, einnehmen resp. zu welchen Gruppen sie gehören, um dedizierte Zugriffsrechte auf die jeweiligen IT-Ressourcen ausüben zu können. Während einer längeren Überggszeit, in der sukzessive die von ZenBen abhängigen, d.h. provisionierten Zielsysteme und ggf. die Personendaten liefernden, autoritativen Quellsysteme das UHH- gebunden werden, werden sowohl das neue wie auch das alte Verfahren und damit die jeweils eingesetzte technische IT-Infrastruktur parallel betrieben werden müssen, um durch diese Art der weichen Migration den operativen Betrieb so wenig wie möglich zu stören und eine kontinuierliche und konstte Erbringung von in Qualität und Qutität vereinbarter Dienstleistungen zu gewährleisten. Im Rahmen der zu erbringenden KoOP-Projektleistungen wurden initial dieses System als Quell- und Zielsystem die Verwaltungsplattform STiNE, aus denen hauptsächlich Studierendenidentitäten hervorgehen, sowie die E-Learning-Plattform WebCT wie auch das Content- Repository MyCoRe via GOLEM als sog. Zielsysteme, die mit Identitäten für die entsprechende Nutzerverwaltung versorgt werden, gekoppelt. Über das gemeinsame IDM-System Std: Seite 13 von 82

14 der Hochschulen erhalten alle Nutzer der Hochschulen Hamburg sowie darüber hinaus Zugriff auf die entsprechenden Plattformen. Während des Aufbaus und operativen Betriebes dieses IDM-Kernsystem werden Erkenntnisse gesammelt, die in die geplten Ausbaustufen einfließen werden. In der Plung hierfür stehen das Anbinden weiterer IT-Ressourcen und hierüber Orgisationseinheiten. Da das IDM-Konzept hier nicht nur auf natürliche Personen reflektierende Identitäten abstellt, sondern auch nachgelagert technische Identitäten, die Objekte referenzieren, die im Interaktionskontext der Plattformen E-Governce und E-Learning Relevz besitzen, sollen auch diese Identitäten Berücksichtigung finden. Die Realisierung des UHH--Projektes erfolgt in zwei aufeinder folgenden Schritten. Während der zweite Schritt sich auf die Übernahme von Mitarbeiterdaten in das UHH- abstützt fokussiert der erste auf Studierendendaten der Universität Hamburg, deren autoritative Quelle im Campusmagementsystem STiNE zu finden ist. Dieses System bildet mit seinen innewohnenden applikativen Komponenten gleichzeitig ein Provisionierungsziel für das UHH-. STiNE auf der einen Seite, hat das UHH- auf der deren Seite die zentrale Benutzerverwaltung ZenBen der Universität Hamburg, deren eingeführte Abläufe gerade in Hinblick auf die von ZenBen provsionierten Zielsysteme in der ersten Phase soweit wie möglich genutzt werden sollen. Somit steht UHH- als intermediäres System im ersten Schritt zwischen diesen beiden eben gennten Systemen und liefert aufgrund eines hohen Automatisierungsgrades in der Interoperabilität zwischen diesen einen ersten Mehrwert. Gleichzeitig wird eine Plattform geschaffen, die als Basis für die Aufnahme weitere Abläufe und Konnexionen dient, mit dem Ziel, Aufgaben von ZenBen zu übernehmen, weitere Systeme zubinden und einen Brückenkopf zu hochschulübergreifenden IDM-Verfahren zu schaffen. Im ersten Schritt wurden als Ergebnis zahlreicher Abstimmungsrunden vom externen Dienstleister eine Anforderungsdefinition und eine Spezifikation erstellt, auf deren Basis die Umsetzung erfolgt. Diese Dokumente werden im Laufe des Projektes ergänzt und fortgeschrieben. Ein Testsystem wurde in einer dem späteren Wirkbetrieb adäquaten Umgebung aufgesetzt, das Identitätenrepository eingerichtet, die vorkonfektionierten Konnektoren entsprechend gepasst (Customizing) und grundlegende Funktionstests durchgeführt. II.2.7 Projekt HAW- In einer konzeptionellen, dem Vorhaben KoOP vorgelagerten Phase wurde der HAW ein Grobkonzept in Auftrag gegeben, in dem die Ist-Situation dargestellt wurde und grundlegende Anforderungen für das aufzubauende hochschulweite Identitätsmagement definiert wurden. Innerhalb dieses Projektes sollen Verzeichnisdienstschema sowie Rollen- und Rechtekonzept modellhaft für die übrigen Hochschulpartner in KoOP entwickelt und genutzt werden. Des Weiteren sollen u. a. eine einheitliche Benutzerkennung und Mailadresse für alle Hochschulgehörigen und single sign-on für alle Anwendungen, für die ein Benutzer berechtigt ist, umgesetzt werden. Basierend auf Grob- und Feinspezifikationen wird die Durchführung o. g. Aufgabenstellung der HAW in zwei aufeinder folgende Teilvorhaben aufgeteilt Aufbau eines KoOP-Experimentiersystems (HAW-) auf Basis eines Labormodells als Konzeptgrundlage für die Zusammenführung und Konsolidierung von Studierenden und Mitarbeitern der HAW Aufbau eines zweiten Systems, dem KoOP-Pilotsystem, für die Zusammenführung und Konsolidierung von Studierenden der HAW und UHH sowie die Bereitstellung eines sog. Corporate Directory als hochschulübergreifende, LDAP-fähige Authentifizie- Std: Seite 14 von 82

15 rungsinstz über die sich Nutzer bestimmter E-Learning-Plattformen authentisieren können. Ziel dieser Zweiteilung war es, in der HAW über eine sog. kleine Lösung grundlegende Kenntnisse hinsichtlich Funktionsweisen der eingesetzten Produkte der Fa. Novell im Zusammenspiel mit den konnektierten Quell- und Zielsystemen zu sammeln sowie die mit Einführung des Experimentiersystems einhergehenden Einflüssen prozessualer und orgisatorischer Natur zu erfahren, um dn hochschulübergreifend die gewonnenen Erkenntnisse in eine große Lösung durch Realisierung des KoOP-Pilotsystems in Zusammenarbeit mit der Universität Hamburg, dem Kooperationsgedken im Gesamtvorhaben KoOP Rechnung tragend, einfließen zu lassen. Hierbei war es wichtig, das erste System parallel zum Aufbau des zweiten funktions- und produktionsfähig zu halten, um während des Betriebes weitere längerfristige Resultate erhalten zu können, die wiederum ihren Niederschlag in das zweite System finden sollten. II.2.8 Projekt GOLEM Das im Rahmen der RRZ E-Learning- und IDM-Bestrebungen entwickelte XMLbasierte Mediatorsystem GOLEM (Global Object Learning Enterprise Mediator) unterstützt die verstärkte Einbettung von E-Learning in IT-gestützte Prozesse der Hochschullehre und generell die Integration von universitären IT- und E-Learning Infrastrukturen. Motivation für die Entwicklung waren die in den Arbeitspaketen 2 und 4 spezifizierten Ziele: die Integration der E-Learning- und Kommunikationsplattformen der UHH in den gemeinsamen Ansatz der Hamburger Hochschulen für das Magement von Identitäten und Rollen und die Koppelung das institutionelle Content-Repository der UHH. Einsatzzweck des Systemes ist der Trsfer von Identitäten, Rollen, Nachrichten und Content zwischen den gekoppelten Systemen - derzeit ist die Anbindungsfähigkeit zu STiNE, WebCT und CommSy seitens der UHH, sowie zu Moodle, ILIAS, HIS-SOS und beliebigen LDAP-basierten Quellsystemen seitens der HAW bzw. TUHH (technische Universität der Hsestadt Hamburg) geplt und zu einem überwiegenden Teil bereits implementiert. Die offene und stdardbasierte Architektur des Systemes gewährleistet hierbei - besonders der Bereich der sogennten AAA-Technologien (Authentication, Authorisation und Accounting) - den Aufbau hochschulübergreifender Verfahrenssätze im Projekt E-Campus sowie im Bereich Content-/Document-Magement. Für GOLEM war zum Jahresende 2006 eine erste prototypische Implementierung verfügbar, die in den Folgemonaten zuerst in Verbindung mit der Lernplattform Blackboard und in der Folge mit dem UHH- getestet werden soll. II.2.9 Projekt SimSpector Existierende Identitätenrepositories, insbesondere solche, die zu einer bestimmten, kaum überschaubaren Größe gewachsenen sind, beinhalten aus der Historie heraus oft ungewollt Dubletten digitaler Identitäten 5, d.h. aus unterschiedlichen Gründen Datensätze, die in Wirklichkeit ein und dieselbe natürliche Person referenzieren, jedoch in ihrer Ausprägung nicht identisch sind, aber ggf. zueinder teilw. identische resp. ähnliche Werte, ihrer zugeordneten, sie hinreichend beschreibenden Attributmenge aufweisen. Es existieren somit ggf. 5 Eine digitale (Personen-)Identität sei definiert als ein eindeutiger, digitaler Identifikator, dem je nach situativem Kontext entsprechend personifizierende Attribute mit ihrer jeweiligen Menge Ausprägungen zugeordnet sein können. Dieser Identifikator steht während seiner gesamten Lebensdauer im System in einer 1:1 -Relation zu einer natürlichen Person und ist somit eineindeutig. Std: Seite 15 von 82

16 mehrere digital über jeweils einen eineindeutigen Identifikator 6 referenzierbare Repräsentten, d.h. Dubletten ein und derselben natürlichen Identität, die somit das Abbild der realen Welt verfälschen. Es kn aber auch passieren, dass die Eineindeutigkeit gebrochen wird, was ebenfalls zu einer Diskrepz zur realen Welt führt. Ist aufgrund fehlender eindeutiger oder (ungewollt) falsifizierter Referenzierungen eine Zuordnung zu verarbeitender Informationen auf entsprechende digitale Identitäten nicht gegeben, so ist nicht immer eindeutig erkennbar, ob es sich trotz teilw. identischer oder sehr ähnlicher Attributwerte um eine Erstaufnahme ins Repository oder Zuweisung neuer Attributwerte zu einer bestehenden digitalen Identität im Respository hdelt. Wird fälschlich eine Erstaufnahme konstatiert, so entsteht eine Dublette, mit der Folge, dass eine natürliche Person nun zwei digitale Entsprechungen im Repository besitzt. Hierdurch könnte diese Person ggf. entweder über die eine oder über die dere digitale Identität (Zugriffs-)Rechte ausüben, zu denen sie nicht mehr autorisiert ist, da der Rechteentzug durch Löschung eines bestimmten Datensatzes oder durch Eintrag in einem bestimmten Datensatz stattgefunden hat, die korrelierenden Rechte jedoch im deren weiter bestehen. Bei vermeintlicher Aktualisierung einer digitalen Identität werden ggf. identifizierende Attribute überschrieben, deren Werte real einer deren, natürlichen Person gehören. In diesem Falle geht eigentlich eine bestehende Relation zwischen digitaler Identität und natürliche Person unter und eine neue wird geschaffen, streng genommen jedoch repräsentiert diese digitale Identität zwei natürliche Personen. In diesem Falle ist die neue Person aber nicht der Lage, (Zugriffs-)Rechte auszuüben, vielmehr werden diese von der ehemalig referenzierten weiter genutzt. Hierdurch kn es dn bei unerlaubten Hdlungen zu einer Fehlidentifizierung kommen, wobei die falsche Person zur Vertwortung gezogen würde. Da das Problem ungewollter Dubletten zu den kostenaufwendigsten Datenfehlern gehört, gilt es, wie auch im Falle eines Eineindeutigkeitsbruch, den inkonsistenten Abbildern von vornherein zu begegnen. So sollten die Anomalien frühzeitig, d.h. am besten bei ihrer Entstehung im Datenerhebungsprozess aufgespürt und eliminiert werden. Hierfür müssen schon vor Aufnahme einer digitalen Identität ins Repository Maßnahmen mehr oder minder automatisierte Verfahren ergriffen werden, die eine ausreichende Datenqualität sicherstellen und es über ein Verfahren zur Duplikaterkennung ermöglichen, zu erkennen, ob eine digitale Identität schon einmal erfasst wurde; geschieht dies nicht, muss zu mindest in kurzen Abständen im Nachgg eine Dublettenprüfung durchgeführt werden. Eine dere Problematik ist gegeben, wenn Personen resp. ihre digitale Identität aus bestimmten Gründen nicht in das Identitätenrespository Einzug finden darf und hierfür entsprechend gelistet sind (Blacklist). Da nicht immer alle Datenquellen, d.h. die Personen erfassenden Stellen über diesen Sachverhalt informiert sind, kn es durchaus passieren, dass Datensätze zur Verarbeitung stehen, die solche Personen repräsentieren. Hier muss die entsprechende Blacklist fehlertolert abgeglichen werden können, um vorgegebene Complice-Verstöße mit entsprechenden Sktionen a priori zu vermeiden. Da eine einfache Prüfung auf Identität der einzelnen relevten Attribute eines Datensatzes nicht ausreicht, um dem oben geschilderten Problembereich entsprechend begegnen zu können, wurde ein alytisches Modell und Verfahren entwickelt, das ein Erkennen resp. ein 6 Da die eine in realiter natürliche existente Person beschreibenden Attribute, in ihrer verfügbaren Menge und Ausprägung als Kriterium für die Unterscheidung nicht immer ausreichen und außerdem sich ein Teil dieser Menge in seiner Ausprägung im Laufe der Zeit ändern kn, existiert ein systemimmentes Surrogat als Identifikator, der Personen eineindeutig referenziert und sie prägnt voneinder trennt. Std: Seite 16 von 82

17 Ausschließen von Duplikaten mit hoher Wahrscheinlichkeit ermöglicht. Grundlage hierfür ist die Zerlegung in ihren Schreibweisen normalisierter, relevter, Identitäten beschreibender Attribute in sog. n-gramme mit schließender Trsformation zu (zusammengesetzten) Signaturen in Form von sog. Bloomfiltern. Über den Jaccard-Koeffizienten als Ähnlichkeitsmaß kn dn die Ähnlichkeit zweier digitaler Identitäten bestimmt werden und somit hd definierter Schwellwerte sog. Dubiose extrahieren, bei denen eine Gruppenzuordnung zu neuen oder schon bestehenden digitalen Identitäten nicht möglich scheint. Diese können oder müssen mithilfe derer automatisierter exakter arbeitender Berechnungsverfahren und/oder final durch Einsatz kognitiver Fähigkeiten menschlicher Ressourcen (Experten) weiter behdelt werden. Das o. g., im Rahmen von KoOP entwickelte Modell und Verfahren wurde programmtechnisch mittels der Programmiersprache Perl als SimSpector (Similarity InSpector) prototypisch realisiert und in einer Testphase die grundsätzlich modellhaften Annahmen validiert und untermauert. Im weiteren Verlauf soll während der Pilotphase des Projektes UHH- die Praxistauglichkeit nachgewiesen werden. II.3 Wissenschaftlicher und technischer Std 7 Im Hochschulumfeld laufen kontinuierlich Prozesse ab, in deren Zentrum Personen und Orgisationen sowie Rollen und Berechtigungen stehen. Personen erhalten im Laufe der Zeit aufgrund unterschiedlicher Status und Zugehörigkeit zu einer oder mehreren Orgisationen resp. Orgisationseinheiten (Hochschule, Fakultät, Department, Institut, Vorlesung, Projekt etc.) bestimmte wechselnde Profile. Mit Hilfe dieser Profile lassen sich Rollen definieren, sodass den Personen über diese Rollen im Rahmen von Arbeitsprozessen dedizierte Zugriffrechte auf (IT-)Ressourcen gewährt werden. Gleichzeitig können sich auch die Strukturen von Orgisationen durch Gründung neuer und Auflösung bestehender sowie Zusammenlegung oder Aufteilung mehrer Orgisationseinheiten ändern, wodurch sich die eben gennten Profile sowie die Zuordnung zu den entsprechenden Rollen ändern, die Rollen-Rechte-Relation aber ggf. unverändert bleiben. Um diesen orgisatorischen Änderungsprozessen auf IT-Ebene effizient begegnen zu können, bedarf es einer entsprechenden Verwaltung, dem Identitätsmagement. Grundlegendes Ziel des Identitätsmagement ist es, im hier vorliegenden Aufgabenkontext, digitale Identitäten zu schaffen und zu verteilen sowie mit deren Hilfe IT-Ressourcen abzusichern. Zum jetzigen Zeitpunkt scheint eine konsolidierte holistische Definition, was Identitätsmagement (IDM) synonymisch wird in dem hier betrachteten Zusammenhg auch oft der Begriff Identity und Access Magement (IAM) verwendet ist und was es beinhaltet, sowie eine gefestigte Nomenklatur nicht in Sicht, so dass hier aus der spezifischen Sicht der Aufgabenstellung heraus versucht wird, diesen Begriff und die damit verbundenen Assoziationen phänomenologisch, d.h. hd seiner aktuell existenten Erscheinungsbilder inhaltlich um- und zusammenfassend deskriptiv zu umreißen. 7 Die hier aufgeführten Sachverhalte entsprechen der gemeinsam mit der HAW entwickelten aktuellen Sichtweise Std: Seite 17 von 82

18 Zum jetzigen Std der Technik lässt sich IDM i. Allg. als eine Gesamtheit von Prozessen, Diensten, Mechismen und IT-Infrastrukturen sowie Vereinbarungen und Richtlinien (Policies) verstehen, um vorrgig digitale Identitäten von Personen, aber auch weiterführend solche von Orgisationseinheiten und (IT-)Ressourcen, in ihren jeweiligen definierten Interaktionskontexten dispositiv sowie operativ nutzen zu können, mit dem Ziel, gesicherte Zugriffe auf dedizierte (IT-)Ressourcen zur Erfüllung bestimmter Aufgaben effizient und normengerecht zu ermöglichen. Der Übersichtlichkeit halber und in Stringenz zur Aufgabenstellung liegt hier der Fokus für das Modell eines hochschulübergreifenden integrativen Identitätsmagements auf natürliche Personen reflektierende Identitäten mit entsprechenden Verwaltungsprozessen hinsichtlich Existenz (Generieren, Pflegen, Löschen und Verteilen), Zertifikate (Berechtigungsausweise), Profile, Rollen und Autorisierungsmechismen sowie Zugriffsprozesse inklusive der einhergehenden Authentisierungs- und Autorisierungsproblematik. Mittels Analogie lässt sich Nachfolgendes relativ einfach auch auf dere Objektklassen, wie z. B. Räume, Verstaltungen etc., wenden und somit das IDM erweitern. II.4 Zusammenarbeit mit deren Stellen Da es sich bei dem Projekt KoOP um ein Verbundprojekt hdelt, sind per se alle Projektmitglieder gleichzeitig auch Partner in der Zusammenarbeit. Ergänzt wurde die Kooperation durch eine intensive Mitarbeit von Computacenter AG & Co. ohg, einem IT-Dienstleister aus Industrie und Wirtschaft. Std: Seite 18 von 82

19 III Detaillierte Darstellung III.1 Erzielte Ergebnisse III.1.1 Produkt- und Herrstellerentscheidung 8 Innerhalb des Projektes wurden verschiedene Gesichtspunkte bei der Herstellerauswahl zur Einführung einer Identity-Magement-Lösung der Hochschule für Angewdte Wissenschaften betrachtet. In den nachfolgenden Kapiteln wird beschrieben, welche Faktoren zu der getroffenen Produktempfehlung geführt haben. III Marktalyse und Trends Auf dem Markt der Identity-Magement-Lösungen konnten sich die Anbieter am besten positionieren, die mit einer durchgängigen und zukunftsorientierten Strategie in den Bereichen Provisioning, Directory und Metadirectory aufwarten. Eine treffende Auswahl der Herstellerlösung muss unter den Gesichtspunkten der überlappenden Eigenschaften der Technologielinien stehen. Außerdem müssen die bestehenden Produktlinien bestmöglich von der neuen Lösung berücksichtigt und in diese integriert werden können. Obwohl die Burton Group feststellte, dass eprovisioning-lösungen Teile der Aufgaben von Metadirectories ü- bernehmen können, sind dennoch die Stärken und Schwächen der jeweiligen Lösung bei der Produktauswahl zu berücksichtigen. In der folgenden Abbildung sind die Ergebnisse einer Untersuchung der Analystengruppe Forrester Research aufgeführt, bei der die wichtigsten Anbieter von Identity-Magement- Systemen und deren Funktionen innerhalb der Produktlösungen untersucht und miteinder verglichen wurden: In den letzten Jahren wollten kleine Anbieter wie zum Beispiel Octet String und Waveset im Markt der Identity-Magement-Lösungen Fuß fassen, indem sie die Lücke zwischen dem traditionellen Metadirectory (dem heutigen Usermagement) und dem Provisioning zu 8 Inhalte dieses Kapitels entstammen hauptsächlich einem internen Papier der HAW Std: Seite 19 von 82

20 schließen versuchten. Etablierte Lösungsbieter erknten dieses Vorhaben und haben entweder durch Zukäufe von Produkten und/oder gzen Unternehmen oder durch die Weiterentwicklung ihrer eigenen Lösungen diese beiden Bereiche miteinder verbunden. In der folgenden Abbildung ist eine Einschätzung des Marktes für Verzeichnisdienste der Gartner Group abgebildet. Sie verdeutlicht die starke Positionierung der traditionellen Verzeichnisdiensthersteller. Im Hinblick auf die Vergleichbarkeit der Lösungen der verschiedenen Hersteller ist allerdings zumerken, dass es für Metadirectory-Lösungen keine konkreten Stdards gibt, die nur für Metadirectories gelten. Die Hersteller von Metadirectory-Lösungen verfolgen zwar grundsätzlich die gleiche Grundidee (zum Beispiel bei der Synchronisation von Benutzerkonten), bei der technischen Umsetzung der Funktionen werden jedoch grundverschiedene Wege eingeschlagen. Entsprechend sind die Lösungen der Hersteller sehr unterschiedlich einzuordnen, da sich in der Art der Speicherung, der Abbildung von Workflows, der Nutzung von Stdards Unterschiede für das Projekt ergeben. Eine Hilfestellung ist die Einordnung der Metadirectory-Hersteller durch die Gartner Group in den so gennten Gartner-Quadrten. Zur Verdeutlichung der Entwicklung werden die Quadrten aus den Jahren 2002 und 2003 einder gegenübergestellt. Std: Seite 20 von 82

21 III Hersteller Im Rahmen des Projektes HAWinfonet wurde eine Marktsichtung durchgeführt. Dabei wurden die Hersteller, deren Produkte in die Evaluation aufgenommen wurden, auf Basis des aktuellen Gartner-Quadrten ausgewählt. Die im Folgenden aufgeführten Beurteilungen basieren auf den Informationen, die bis Ende September 2005 aufgenommen wurden. Bei den nachfolgend verwendeten Abbildungen hdelt es sich um Präsentationsmaterialien der jeweiligen Hersteller. Sun (SIM): Quelle: Sun Positionierung und Beurteilung: Funktionen o Provisioning o Automatisierter Datenaustausch (Metadirectory) nur bedingt möglich Virtueller Ansatz o Speicherung von Referenzen für Zielsysteme Beurteilung o Sehr leistungsfähiges Provisioning o Einfache Installation o Stabile Umgebung, relative schnelle Prototypen möglich o Zentrales Passwort-Magement (bedingte Synchronisation) o Wie Snowboard fahren: Der Anfg ist leicht! o Kein ausreichendes Rollenmodell Std: Seite 21 von 82

22 Novell (IDM2): Quelle: Novell Positionierung und Beurteilung: Funktionen o Provisioning o Automatisierter Datenaustausch (Metadirectory) Zentraler Ansatz o Speicherung aller Daten im edirectory Beurteilung o Sehr stabil und skalierbar o Sehr ausgereift, sehr viele Systeme durch Konnektoren erreichbar o Grafischer Policy Builder best of breed o Grafischer Workflow Editor best of breed o Programmierung: XSLT Stylesheets, grafische Oberfläche o Passwort-Magement-Modul enthalten (inkl. Selfservice UND Verteilung) o Leistungsfähiges Auditing-Modul enthalten o Kein ausreichendes Rollenmodell Std: Seite 22 von 82

23 IBM (Suite): Quelle: IBM Positionierung und Beurteilung: Funktionen o Provisioning o Automatisierter Datenaustausch (Metadirectory) Dezentraler und zentraler Ansatz o Synchronisation der Daten ohne Zwischenspeicherung (IDI) o Speicherung aller Daten im IDS (für TIM) Beurteilung o Sehr leistungsfähig o Sehr viele Konnektoren o Grafisches Werkzeug für die Workflow-Definition o Extrem komplexe Architektur mit vielen Komponenten o Unterstützung des Herstellers schwierig o Der Zukauf von IDI (Metamerge) und Access360 (TIM) erfordert einen hohen Integrationsaufwd seitens des Herstellers o Kein ausreichendes Rollenmodell o Audit-Modul Std: Seite 23 von 82

24 Siemens (Meta-...): Quelle: Siemens Positionierung und Beurteilung: Funktionen o Provisioning o Automatisierter Datenaustausch (Metadirectory) Zentraler Ansatz o Speicherung aller Daten im DirX/Sun Directory/Microsoft Active Directory Beurteilung o Sehr stabil und skalierbar o Sehr ausgereift, sehr viele Systeme durch Konnektoren erreichbar o Grafische Rollen-Administration o Programmierung: TCL o Passwort-Magement-Modul enthalten o Leistungsfähiges Auditing-Modul enthalten Std: Seite 24 von 82

25 III Produktempfehlung Eine Produktempfehlung wurde Anfg 2006 hd der nachfolgenden Kriterien zugunsten des Identity Magers des Herstellers Novell ausgesprochen: Innerhalb der Hochschulldschaft in Deutschld befinden sich verschiedene Projekte, die mit dem hiesigen Projekt vergleichbar sind, in der Realisierungsphase oder wurden bereits realisiert. Dabei wurde zum überwiegenden Teil auf den Novell Identity Mager zurückgegriffen. Die Erfahrung hat gezeigt, dass die Unterstützung des Herstellers eines der Kriterien ist, die Projekte zu einem erfolgreichen Abschluss zu führen. Hier hat der Hersteller Novell durch seine weltweit ausgebaute Supportstruktur (unter derem bietet Novell einen 7x24-Stunden-Support mit gartierten Reaktionszeiten) mehrfach bewiesen, dass er Kunden in dieser Größenordnung technisch sehr gut unterstützen kn. Das der HAW Hamburg vorhdene, gut ausgebaute Know-how zu den Produkten Novell edirectory und zu Teilen des Identity Magers konnte und kn weiterhin in das Projekt HAWinfonet einfließen. Der insgesamt benötigte Schulungsaufwd verringert sich entsprechend. Ähnliches gilt auch für die Hochschulldschaft in Hamburg. Beim Aufbau des Testsystems konnten umfgreiche Erfahrungen mit den Komponenten des Identity Magers gesammelt und das vorhdene Know-how ausgebaut werden. Die uneingeschränkt positiven Erfahrungen (bezogen auf die Funktionalität und Stabilität des Systems) gaben einen weiteren Ausschlag in die Richtung des Novell Identity Magers bei der Produktempfehlung. Im Hinblick auf weitere, zu diesem Zeitpunkt noch nicht alysierte Anforderungen, bietet die Produktpalette des Herstellers Novell verschiedene weitere Lösungen, um den Lebenszyklus eines Benutzers aus IT-Sicht optimal abbilden zu können. Hierzu zählt unter derem das Ressourcenmagement ZENworks, weitere Produkte aus dem Umfeld Secure und Identity Magement wie ichain, File System Factory, der Security Mager und die SSO-Lösung SecureLogin. Innerhalb der letzten Jahre hat Novell unter derem bei der Produktlinie Secure d Identity Magement großen Wert auf Plattformunabhängigkeit gelegt. Alle Einzelkomponenten können (soweit dies überhaupt technisch möglich ist) auf den Plattformen Linux, Unix, Solaris, Windows und NetWare in Betrieb genommen werden. Kein derer Hersteller bietet diese Flexibilität. Bei deren Lösungen muss m sich für eine strategische Plattform entscheiden Novell überlässt diese Entscheidung seinen Kunden. In der folgenden Tabelle wurden die oben Konnektoren hd ihrer technischen Leistungsfähigkeit bewertet. Das Punktesystem reicht hierbei von 0 (nicht vorhden) bis 5 (sehr gut). Std: Seite 25 von 82

26 III.1.2 Digitale Identität Versuch einer Definition Eine digitale Identität und hier im Speziellen eine digitale Personenidentität sei definiert als ein eindeutiger, digitaler Identifikator, dem je nach situativem Kontext entsprechend personifizierende Attribute mit ihrer jeweiligen Menge Ausprägungen zugeordnet sein können. Dieser Identifikator steht während seiner gesamten Lebensdauer im System in einer 1:1 - Relation zu einer natürlichen Person und ist somit eineindeutig. Die Kontexte können sich überlappen oder Teil eines sie umfassenden Kontextes sein, so dass für die Attributgesamtmenge Schnittmengen und/oder Teilmengen entstehen. III Anwendungsfall Erika Mustermn, wohnhaft in Flensburg, unter der Woche aber bei ihrer Tte in Hamburg zu erreichen, doziert als ausgebildete Musikerin der Hochschule für Musik und Theater und ist als wissenschaftliche Mitarbeiterin der Hochschule für bildende Künste beschäftigt. Sie war in ihrer Verggenheit aufgrund ihrer Interessenslage für elektronische Musik Studentin am Fachbereich Elektrotechnik der Fachhochschule Hamburg, in dessen Förderverein sie Mitglied ist, und hat nach Ende dieses Studiums ein Diplom-Aufbaustudiengg für "Kultur- und Medienmagement am Institut für Kultur- und Medienmagement der Hochschule für Musik und Theater erfolgreich abgeschlossen, um nun der Hochschule für bildenden Künste zum Thema "Der Einfluss der Globalisierung auf die Medienkultur und deren Vermarktung" zu promovieren. Im Umfeld dieses Vorhabens besucht sie als Gasthörerin u. a. juristische und wirtschaftswissenschaftliche Vorlesungen der Uni Hamburg. Für die jeweiligen Aufgabenstellungen in den unterschiedlichen Kontexten der Hochschulldschaft benötigt Erika Mustermn ihrer jeweiligen Stellung entsprechend Zugänge zu IT- Ressourcen. Aus dem durch die Dimensionen Hochschule und Stellung gebildeten Kreuzprodukt entstehen modellhaft Profile die einer Person zugeordnet werden. Anhd dieser Profile lassen sich dn für die IT-Ressourcen über Rollen-/Gruppenbildung Zugriffrechte ableiten. III Kontexte Werden Schnitt- und/oder Teilmengen extrahiert und als logische übergeordnete Kontexte definiert, so können die gesamten Kontexte baumartig geordnet werden, und es bildet sich hinsichtlich der Attribute eine Vererbungshierarchie. Gleichzeitig können einige vererbte Attribute aufgrund kontextsensitiv unterschiedlicher Ausprägung ergänzt und/oder überschrieben werden. Die digitale Identität liefert in der Gesamtheit ihrer Attribute wie auch in wohl definierten Teilen davon eine kommunikativ zugängliche Repräsentz einer natürlichen Person. Der Identifikator dient der eindeutigen Wiedererkennbarkeit und damit der Identifizierung in den kommunikativen Beziehungen über Kontexte hinweg. Somit reflektiert z. B. die Attributmenge eines situativen Kontextes nach Instzerzeugung ein digitales Abbild einer natürlichen Person mit ihrer hdlungsspezifischen Rolle in einer bestimmten Orgisationseinheit. Std: Seite 26 von 82

27 Kontext 2 Kontext 1 Kontext 3 Kontext 1/2 Kontext 1/2/3 Kontext 1/2/3 Kontext 1/2 Kontext 3 Kontext 2 Kontext 1 III Identifikator Da Merkmale, die eine in realiter natürliche existente Person beschreiben, in ihrer verfügbaren Menge und Ausprägung als Kriterium für die Unterscheidung nicht immer ausreichen und außerdem sich ein Teil dieser Menge in seiner Ausprägung im Laufe der Zeit ändern kn, wodurch Kollisionen entstehen könnten, die aufgrund der eindeutigen Identifizierung mit erheblichen Aufwd aufzulösen wären, und weiterhin der Pflegeaufwd für die Konsistenzerhaltung über Kontexte hinweg erheblich stiege, wird als Äquivalent ein Surrogat, d.h. ein künstlich erzeugtes, systemimmentes Merkmal als Identifikator verwendet, das Personen prägnt voneinder trennt. Diesem Identifikator werden je nach Kontext ggf. teilweise unterschiedliche Attributrahmen zu gewiesen. Identifikator XYZ123 $%& UserID User Password Common Name Surname Title Given Name Date of Birth Place of Birth Gender Status Home Postal Address Business Postal Address Private Phone Number Business Phone Number Mobile Phone Number Affiliation Primary Affiliation Staff Category Orgizations Distinguished Name (DN) Orgizational Unit.s Distinguished Name (DN) Department Study Course Primary Study Course Attributrahmen (z. B. hheduperson) Std: Seite 27 von 82

28 Die Menge der vorhdenen Identifikatoren bilden in ihrer Gesamtheit ein sog. kontrolliertes Vokabular, das aufgrund der 1:1 -Relation zu einer natürlichen Person weder Homonyme noch Synonyme aufweist. Dieses Vokabular lässt in seiner Semtik keinen Rückschluss auf die repräsentierten natürlichen Personen zu, wodurch es im Rahmen einer Anonymisierung innerhalb bestimmter Kontexte seinen Beitrag leisten kn. III.1.3 Grundzüge eines Identitätsmagementsystem Eine Person, die sich Zugg zu einer IT-Plattform mit unterschiedlichen disponierten Diensten resp. Applikationen oder allgemein Ressourcen verschaffen will, muss hd bestimmter Merkmale über ein mögliches Identitätsfeststellungsverfahren innerhalb eines bestimmten Kontextes eindeutig identifizierbar sein. D.h., die in einem technischen System abgelegten personenbezogenen Daten repräsentieren bei Übereinstimmung mit einer natürlichen Person dessen digitale Identität hd derer die Zuggs- und Verarbeitungsberechtigungen festgemacht werden und der Zugg entsprechend freigeschaltet wird. Um die abgelegten digitalen Identitäten und Zugriffsberechtigungen auf (IT-)Ressourcen verwalten zu können, existieren Identitätsmagementsysteme (), die singulär oder kooperativ im Verbund agieren und über ihre Schnittstellen für die Identitätenverwaltung und Zugriffssteuerung bestimmte Dienste auf unterschiedlichen Ebenen für den dispositiven resp. operativen Zugg zur Verfügung stellen. Der Zugriff auf jedes Identitätsmagementsystem unterliegt denselben Anforderungen wie der auf eine beliebige (IT)-Ressource; d.h. dass es für ein selbst eines internen Identitätsmagementsystems mit den grundlegenden Funktionalitäten nicht nur zum intern ITadministrativen Verwalten von Identitäten, sondern auch unter Einbezug von Diensten mit Self-Service- resp. Self-Care-Charakter bedarf, um die Steuerung der Zugriffe zu regeln, nur mit dem Unterschied, dass deren Identitäten nicht in Hinblick auf dere Systeme provisioniert werden. Single-Sign-On Passwortmagement Personalisierung Selfservice Föderation Mehrwertdienste Identitätenverwaltung Lifecyclemagement Provisionierung Archivierung Rollen/Rechte Billing Authentifizierung Autorisierung Auditing Accounting LDAP DAP ODBC JDBC etc. Basis-, Meta-, virtuelle Verzeichnisse Dateien Datenbken Smartcards Zugriffssteuerung Verwaltungsdienste Datenhaltungsdienste Sicherheitsdienste Digitale Identitäten dispositive operative Schnittstelle Std: Seite 28 von 82

29 III Datenhaltungsdienste Viele Fachwendungen verfügen über interne Datenhaltungsdienste mit eigener Datenhaltung in Form von gängigen Datenbksystemen mit entsprechendem, ggf. auch (L)DAP fähigem Zugriffsprotokoll, in der Identitäten (Benutzerdaten) und Zugriffsrechte applikationsorientiert abgelegt und gepflegt werden, oder sie können hierfür einen konjunktiven Verzeichnisdienst mit einem Basisverzeichnis ihre eigen nennen. Solche Repositories bilden oft Quellsysteme, aus denen z. B. Meta-Verzeichnisse befüllt werden, aber auch Zielsysteme, die mit entsprechenden Daten befüllt werden. Um einen spezifischen Teil der Identitätendaten über Kontexte hinweg konsistent halten zu können, werden Meta-Verzeichnisse in Verbindung mit dem LDAP-Protokoll verwendet, die dem Ressourcen zugewdten sowohl als Ziel- wie auch als Quellsystem dienen, d.h. ihre Aufgabe besteht darin, aus verschiedenen Quellen stammende Daten zusammenzuführen, zu synchronisieren und Widersprüche in Informationen, z. B. bei gleichen Namen, aufzulösen. Für diese Teildaten werden die dezentralen Quellsysteme als führend definiert, d.h. sie enthalten immer die für allgemeingültig befundenen Daten. Der Meta-Verzeichnisdienst selbst ist ein automatisierter Kopierprozess, der die einzelnen Daten nach bestimmten Regeln aus den jeweils führenden Systemen (Quellsysteme) entnimmt, redundt im internen Verzeichnis speichert und alle deren Systeme (Zielsysteme) je nach Anforderung verteilt. Für kooperative Zwecke können virtuelle Verzeichnisse zum Einsatz kommen. Sie integrieren Informationen aus verschiedenen Verzeichnissen dynamisch zur Laufzeit und stellen sie als ein Verzeichnis dar, d.h. die Informationen werden aus mehreren Verzeichnissen zusammengefasst und in der gewünschten Struktur präsentiert. Das virtuelle Verzeichnis selbst beinhaltet nur Mapping-Informationen für die Konnexion, d.h. auf eine Anfrage liefert der Verzeichnisdienst dem Anfragenden eine Referenz, wo er die entsprechenden Informationen abholen kn, oder dem Anfragenden werden die entsprechenden Informationen mit Hilfe der abgelegten Referenz aus dem deren Verzeichnis ausgeliefert. III Sicherheitsdienste Der Prozess des Authentifizierens dient hier der Verifikation einer registrierten, d.h. in einer Datenbasis (Datenbk, Verzeichnis, Smartcard) abgelegten Identität hd bestimmter Merkmale, um festzustellen, dass eine mit dieser Identität assoziierten Person, die ist, die sie vorgibt zu sein, d.h. die Person tritt den Beweis über diese Behauptung, indem sie durch Angabe bestimmter Merkmale, wie z. B. ein von autorisierter Stelle ausgegebenes Passwort, eine Signatur oder biometrische Merkmale etc., versucht, sich zu authentisieren. Mit Hilfe dieser Merkmale wird versucht, diese Person über ein Abgleichverfahren mit den gespeicherten digitalen Identitäten zu finden und zu identifizieren Authentifizierung ist hier aufgrund des eindeutigen Identitätsnachweises mit dem Vorgg der Identifizierung äquivalent. Nach Überprüfung kn ein Token, der sog. Authentifikator generiert werden, hd dessen dere nachvollziehen können, dass eine erfolgreiche Überprüfung stattgefunden hat. Nach erfolgreicher Authentifizierung erfolgt ggf. die Autorisierung, die die Zugriffskontrolle regel- und/oder rollenbasiert regelt; d.h., dass z. B. hd der einer Identität zugeordneten Rolle dieser Rolle zugewiesenen Zugriffsrechte gemäß der Zugriff auf die relevten Ressourcen gewährt wird. Std: Seite 29 von 82

30 Während das Accounting die Inspruchnahme von Diensten zum Zwecke der Statistik, Abrechnung, Revision, Entdeckung von Sicherheitsverstößen und Beweisführung protokolliert, dient das Auditing der Untersuchung und Auswertung dieser Aufzeichnungen, um festzustellen, ob tatsächlich Sicherheitsverstöße aufgetreten sind, wer sie ausgelöst hat und welche Ressourcen davon betroffen waren. III Verwaltungsdienste Neben dem reinen Lifecyclemagement (Erzeugen, Pflegen, Löschen) unterstützen den Verwaltungsprozess für digitale Identitäten drei weitere Dienste: Provisionieren Archivieren Deprovisionieren Das Provisionieren 9 resp. Deprovisionieren umfasst den mittels Push- oder Pulltechnik ausgelegten Trsferprozess, der nach Erzeugen, Pflegen oder vor dem Löschen einer Identität für die Automatisierung aller Schritte sorgt, die für die Synchronisation und Bereitstellung digitaler Identitäten sowie deren Rechteentzug in Richtung mehr oder weniger heterogener Zielsysteme (z. B. Anwendungssysteme aber auch weitere IDM-Systeme) ggf. regelbasiert, trsformierend und/oder kollisionsauflösend (Dublettenbehdlung) notwendig sind. Digitale Identitäten durchlaufen während ihrer Lebenszeit Metamorphosen, die aufgezeichnet werden, um attestieren zu können, wer in bestimmten Zeitfenster welche Zugriffberechtigungen gehabt hatte, unabhängig davon ob auf Ressourcen zugegriffen wurde oder nicht. Die Archivierung dieser Identitätenhistorie schließt auch den Vorgg des sog. logischen Löschens mit ein. Nach einer bestimmten Zeit können die archivierten identitätsbezogenen Daten endgültig gelöscht werden. Erzeugen Provisionieren Pflegen Deprovisionieren Archivieren Löschen Neben den identitätsbezogen Verwaltungsdiensten existiert ein weiterer Dienst, der den Aufbau und Verwaltung von Rollen und den ihnen verknüpften Verwendung- und Zugriffsrechte auf bestimmte Ressourcen sowie das Einordnen der Rollen hinsichtlich der Orgisationsstruktur ermöglicht, um in einem Anwendungsprozess eine Berechtigungsprüfung (Autorisierung) durchführen zu können. Rechte werden also indirekt über Rollen den Identitäten zugeordnet, wobei grundlegend gilt, dass eine Identität resp. der sie verkörperte Nutzer nicht mehr Rechte haben darf, als er für die Erledigung einer bestimmten Aufgabe benötigt. 9 Provisionieren ist hier nicht mit Replizieren gleichzusetzen, das im Falle durchzuführender Datenvolumen- und/oder Lastverteilung zum Einsatz kommt, um entsprechend die Verfügbarkeit skalieren zu können. Std: Seite 30 von 82

31 Der Billing-Dienst gestaltet u. a. den gesamten Prozess der Abrechnung und umfasst die Subprozesse: Tariffierung Sammlung der Dienstnutzungsdaten pro Nutzer Zuordnung der Nutzungsdaten auf die jeweiligen Tarife Rechnungslegung und versd Controlling und Inkasso III Mehrwertdienste Mit Self-Service-Diensten soll der Eigentümer der Identität, also die durch die digitale Identität repräsentierte natürliche Person, in die Lage versetzt werden, spezifische Attribute seiner digitalen Identität einsehen, ggf. ändern wie auch löschen zu können. Das Passwortmagement ermöglicht es Systemnutzern, die Kennungen und Passwörter der verschiedenen Anwendungssysteme resp. Kontexte zu synchronisieren, alle Kennungen und Passwörter gleichzeitig zurückzusetzen bzw. zu ändern. Außerdem werden die lokalen Kennungs- und Passwort-Richtlinien der verschiedenen Anwendungssysteme und Kontexte berücksichtigt. Gleichzeitig muss gewährleistet sein, dass eine Kombination aus Kennung und Passwort als Äquivalent zum Identifikator bei jeder Erzeugung der Bedingung der 1:1 - Relation für den jeweiligen Kontext resp. Anwendungssystem genügt. Single-Sign-On-Dienste erlauben, dass nach einmaligem Login die Identität des Anwendungsnutzers für einen bestimmten Zeitraum gesichert einem System zur Verfügung steht und er auf alle Ressourcen dieses Systems seiner Berechtigung (Autorisation) gemäß zugreifen kn, ohne sich erneut einloggen zu müssen. Dieser Eintritt in das System wird über ein entsprechendes Authentisierungsverfahren qualifiziert, das mittels Verifikationsmethoden die Urheberschaft (Authentizität) des Logins überprüft und damit die reale Identität des Nutzers konstatiert und ihn somit identifiziert. Neben den Single-Sign-On-Diensten ermöglicht die Föderation ebenfalls die einmalige Anmeldung, nur mit dem Unterschied, dass über eine Vertrauensinfrastruktur, Protokollen und entsprechenden Verfahren (z. B. Shibboleth, Liberty Allice, PAPI usw.) Vertwortlichkeiten hinsichtlich der Authentifizierung und Autorisierung dere Parteien, die dieser Föderation über Vertrauensstellungen partizipieren, delegiert werden. Zweck dieser Föderation ist das Zusammenführen dezentraler Web-Dienste, um sie deren Orgisationseinheiten, die nicht im hier vorliegenden Hochschulverbund vertreten sind, über einen einheitlichen und zuverlässigen Autorisierungsvorgg bieten zu können. III.1.4 Hochschulübergreifendes Identitätsmagement Die Ablauforgisation einer jeden Hochschule besteht alog zu Unternehmen aus Geschäftsprozessen, die Personen und Orgisationseinheiten mit Dienste bereitstellenden Anwendungen, IT-Infrastrukturkomponenten und weiteren Ressourcen (Räume, ) miteinder verbinden, um Dienstleistungen und/oder Produkte für interne und externe Kunden resp. Dienstnutzern für das Kerngeschäft Forschung und Lehre zu erstellen. Formal betrachtet besteht hier ein Geschäftsprozess aus einer Kette betrieblicher Wert schöpfender Aktivitäten mit einem bestimmten Anfgs- und Endpunkt. Der Aktivitätenfluss wird auf oberster Ebene von Personen, den Akteuren, gesteuert, die entsprechend ihrer orgisatorischen Einbindung und/oder Kompetenzen eine Rolle einnehmen und unter Verwendung von Ressourcen (z. B. IT-Systeme) dem Kunden einen bestimmten Dienst liefern. Std: Seite 31 von 82

32 Aus den Prozessen heraus werden zur Erfüllung bestimmter Aufgaben IT-Dienste resp. Applikationen verwendet, die jeweils einzeln und/oder ggf. über Workflows gekoppelt für diese Prozesse relevte Resultate liefern. Hierfür sind den Akteuren benötigte Zugriffe auf relevte IT-Systeme resp. deren Komponenten (Dienste, Applikationen, Netze usw.) zu gewähren. Um dies zu ermöglichen, werden in der Regel Nutzerkonten (Accounts) in z. B. den jeweiligen E-Learning-Anwendungen und der darunter liegenden Betriebssoftware (z. B. DBMS, CMS, Betriebssystem etc.) eingerichtet und entsprechende Nutzungsrechte festgelegt. Diese Sicht auf die Prozesse liefert zumindest den ersten Anhaltspunkt hinsichtlich der Frage, welche Identitäten aus den Personenkreisen von Dienstnutzern und Akteuren überhaupt verwaltet werden müssen. Auch stellt dieser Zusammenhg klar, das hier nicht die Frage lauten kn, welches das führende technische System für das IDM ist, von dem aus ggf. weitere mit entsprechenden Daten versorgt werden, sondern sie muss darauf abstellen, in welchen Prozessen digitale Personenidentitäten erzeugt, geändert und/oder gelöscht sowie genutzt werden. Sind diese eruiert, ergeben sich dn die Quell- und Zielsysteme sowie die Wege zwischen den einzelnen technischen Systemen. Viele Datenquellen und senken für digitale Identitätsinformationen zusammenzufassen oder wenigstens synchron zu halten, ist eine der Kardinalaufgaben des Identitätsmagements. Als determinierenden Faktor den Integrationsgrad der eingesetzten Repositories 10 zugrunde gelegt, reicht der Spnungsbogen von der Verwendung eines gemeinsamen Verzeichnisdienstes für mehrere Anwendungen resp. IT-Ressourcen bis hin zu föderativen Ansätzen. III Zentrales vs. verteiltes Verzeichnis Ein gemeinsames zentrales Basisverzeichnis für alle in den Hochschulen existenten Anwendungen hat den Vorteil, dass die Identitätsinformationen nur einer Stelle abgelegt sind und zentral administriert resp. gepflegt werden können, wodurch sich der Pflegeaufwd reduziert und die Anwendungen zu jeder Zeit auf einen konsistenten Datenbestd zugreifen können. Dieser Ansatz birgt jedoch aus technischer Sicht den gravierenden Nachteil, dass das Volumen und die Komplexität des Attributrahmens mit jeder integrierten Ressource, die ihre eigenen applikationsrelevten Informationen (z. B. Rollen und Rechte) in diesen Rahmen ablegt, steigen und ab einer bestimmten Anzahl von Anwendungen die Reduktion des Pflegeaufwdes konterkariert wird. Weiterhin ist zu konstatieren, dass jede Anwendungen nicht alle Verzeichnisarten unterstützen und/oder eine proprietäre Datenhaltung für Identitäten besitzen, sie stellen aber eine stdardisierte LDAP-fähige Schnittstelle zur Verfügung, über die auf Identitäten zugegriffen werden kn. Unter datenschutzrechtlichen Aspekten sind hier hinsichtlich der Erforderlichkeit, Datenvermeidung und sparsamkeit sowie der Zweckbindung ebenfalls Bedenken zumelden, da hier eine enge Kopplung personenbezogener Informationen vorliegt. Diese enge Kopplung ist auch aus systemischen Gründen nicht ratsam, gerade in Hinblick auf IT-Sicherheit, denn hier gilt es, sensitive Daten und Geschäftsvorgänge zu schützen sowie eine Beeinträchtigung der Geschäftstätigkeiten durch Pnen in der IT, die auch existenzbedrohend sein können, nach Möglichkeit auszuschließen. 10 Da als Repository meist ein Verzeichnis verwendet wird, wird nachfolgend auf Verzeichnisse abgestellt, auch wenn eine dedizierte Datenbk u. ä. gleichwohl identische Funktionalität liefern könnte. Std: Seite 32 von 82

33 Dies alles führt zu einer neuen Strategie, die von einem einzigen zentralen Verzeichnis als verbindendes Element der Hochschulen Hamburgs abrückt und auf Hochschul- sowie hochübergreifender Ebene zu einem Wald aus mehreren Verzeichnisbäumen unterschiedlicher Ausprägung tendiert. Basisverzeichnis Metaverzeichnis Provisionierung virtuelles Verzeichnis Föderation enge Kopplung lose Kopplung Die allumfassende Architektur bestünde dn aus zentral ausgerichteten Kernverzeichnissen, um die sich dezentral sog. Trabtenverzeichnisse gruppierten. Die kommunikative Verbindung zwischen den so komplementär gegenüberstehenden Verzeichnistypen würde durch Provisionierungsmechismen hergestellt. Gleichzeitig lieferte dieser Art der Anordnung den Vorteil der systemimmenten latenten Verfügbarkeit i. w. S. von Lastverteilungs-, Fallback- und Backup- resp. Replikationsfunktionalität. Trabtverzeichnis Trabtverzeichnis Trabtverzeichnis Trabtverzeichnis Trabt-/ Kernverzeichnis Trabtverzeichnis Trabt-/ Kernverzeichnis Trabtverzeichnis Kernverzeichnis Trabt-/ Kernverzeichnis Trabtverzeichnis Trabtverzeichnis Trabt-/ Kernverzeichnis Trabtverzeichnis Trabtverzeichnis Trabtverzeichnis Trabtverzeichnis III Schichtenarchitektur Das Konzept der hochschulübergreifenden IDM-Pyramidenarchitektur der Hochschulen Hamburgs und ihrer assoziierten Einrichtungen besteht aus 4 Ebenen in denen ebenenspezifisch motiviert IDM mit unterschiedlichen Ausprägungen und Zielsetzungen betrieben wird. Std: Seite 33 von 82

34 Die Ebenen werden modellhaft über ihre gedachte Flächenausbreitung attributiert, wodurch sich eine partielle, lokale, regionale und überregionale Ebene ergibt, die hierarchisch geordnet eine logische Schichtenarchitektur ergeben. Die einzelnen IDM-Systeme in den Schichten sind über Provisionierungsmechismen mit denen ihrer jeweils nächst höheren und nächst niedrigeren sowie ggf. auch innerhalb ihrer Schicht kommunikativ miteinder verbunden und bilden in ihrer Gesamtheit das hochschulübergreifende integrative Identitätsmagement der involvierten Hochschulen, in dem die so gekoppelten eine Kaskade bilden. Einem übergeordneten stehen hierbei grundsätzlich jeweils ein oder mehrere logisch oder physisch voneinder getrennte Quell- und Zielsysteme einer unteren Ebene gegenüber, in denen Identitäten produziert resp. konsumiert werden dies gilt auch innerhalb einer Ebene, wenn dort ähnlich aufgebaute Strukturen existieren. Überregionale Ebene Quell- Provsionierung Föderation Hochschulverbund: HAW, HCU, HfBK, HfMT, SUB, TUHH, UHH Orgisationen / Orgisationseinheiten: Hochschulen, Bibliotheken, Verwaltungen, Institute etc. Regionale Ebene Ziel- Provsionierung Lokale Ebene IT-Ressourcen: (Fach-)Applikationen, Dienste, Basisdienste ( usw.), Betriebssoftware, IT-Infrastruktur etc. Partielle Ebene Prinzipiell nimmt mit Übergg zu höhere Schichten die Informationsdichte personenbezogener Informationen in den digitalen Identitäten ab, so dass auf regionaler Ebene der Attributrahmen einer digitalen Identität nur die (Schnitt-)Menge Merkmalen aufweist, die notwendig sind, die zu repräsentierende Person im übergeordneten Kontext des Hochschulverbundes zu beschreiben. Gleichzeitig steigt die Anzahl dieser digitalen Identitäten, da auf dieser Ebene die digitalen Identitäten aller involvierten Hochschulen und assoziierten Einrichtungen aufzunehmen sind. III Partielle Ebene Auf partieller Ebene sind sog. IDM-(End)Quellsystemen, in denen die Rohdaten möglicher Identitäten für das IDM erzeugt werden, und IDM-(End)Zielsystemen mit der Hauptaufgabe Std: Seite 34 von 82

35 der IT-Ressourcen bezogenen (Nutzer-/)Accountverwaltung, Authentifizierung, Autorisierung und ggf. Abrechnung (Accouting) loziert; diese Systeme werden häufig unter dem Begriff Triple-A-Systeme 11 subsumiert. IDM wird hier hauptsächlich nutzungszentriert mit entsprechend mehr oder weniger fein grulierten Rollen und Berechtigungen eingesetzt, um mit Hilfe der Authentifizierung einen sicheren autorisierten Zugriff auf IT-Ressourcen zu gewährleisten. Den relevten IT- Ressourcen, die in diesem Falle die sog. (End-)Zielsysteme repräsentieren, ist hierfür ein für die Nutzerverwaltung zugeordnet, wobei der Grad der Zuordnung unterschiedlich ausgeprägt sein kn. Die erste Ausprägung steht für IT-Ressourcen, die eine interne proprietäre Nutzerverwaltung besitzen, die von Außen nicht ohne weiteres sichtbar ist; d.h. sie ist entweder implizit in einer Anwendungssoftware verdrahtet oder deren Daten sind in einer integrierten Datenbasis abgelegt. Liegt keine LDAP-Fähigkeit vor, bedarf der Entwicklung adäquater Adapter, um diese zu integrieren. 1. Ausprägung IT-Ressource mit internem IDM 2. Ausprägung IT-Ressource mit externem IDM 3. Ausprägung IT-Ressourcen mit gemeinsamem IDM Die zweite Ausprägung präsentiert IT-Ressourcen, die über ein ggf. LDAP-fähiges Respository resp. Verzeichnis die Nutzer verwaltet. In der dritten Ausprägung bildet ein zentrales Account/Nutzerverzeichnis resp. -repository das 12, dessen Authentisierungsdienst von mehreren IT-Ressourcen genutzt werden 11 Triple-A-Systeme (oder AAA-Systeme, kurz AAA) werden in großem Umfg bei kabelgebundenen und mobilen Netzwerk-Betreibern sowie Internetdienstbietern eingesetzt. Die drei A stehen dabei für Authentifizierung (engl. authentication), Autorisierung (engl. authorization) und Abrechnung (engl. accounting) des Netzwerkzuggs von Kunden (Endkunden). Oft werden Triple-A-Systeme gekoppelt mit Kundenverwaltungssystemen (Identity Magement Systeme liefern unter Umständen Teile dieser Kundendaten bzw. verwalten die kommerziellen Aspekte und Daten der Endkunden) und beliefern wieder dere System (z.b. Billing, Rechnungswesen). (s. System) Std: Seite 35 von 82

36 z. B. Hyperapplikationen, in der mehrere Applikationen gemeinsam ihren Anteil für die Erbringung eines bestimmten Services leisten. III Lokale Ebene Auf lokaler Ebene sind die Hochschulen selber mit ihren Fakultäten, Departments, gegliederten Instituten (z. B. RRZ) und Verwaltungseinrichtungen sowie auf Hochschulebene assoziierte Einrichtungen (z. B. die Staats- und Universitätsbibliothek SUB) gesiedelt, aber auch virtuelle Orgisationseinheiten in Form von z. B. hochschulübergreifender, gemeinsam von mehreren Hochschulen gebotener Dienste. Die Hauptaufgabe dieser Ebene hinsichtlich IDM besteht in der Konsolidierung der verteilt abgelegten IDM-Informationen auf einen Attributrahmen, der die zu repräsentierende Person hinreichend beschreibt, sowie die Schaffung definierter Übergabepunkte. 1. Ausprägung: Orgisation ohne konsolidiertes IDM 2. Ausprägung: Orgisation mit konsolidiertem IDM 3. Ausprägung: Mehrere Orgisationen/Orgisationseinheiten mit einem konsolidierten IDM Hier kommen hauptsächlich Systeme (2. und 3. Ausprägung) für die IDM-Aufgabe zum Einsatz, in denen (ggf. vorläufige) digitale Identitäten abgelegt sind, um orgisationsbezogene Informationen über die zu repräsentierende Person zu erhalten. Hier hdelt es sich also um eine Art von Metaverzeichnissen, die aus unterschiedlichen externen Datenbeständen (Quel- 12 Diese Systeme werden in diesem Zusammenhg auch Corporate oder Enterprise Directoy gennt; müssten jedoch allein schon aufgrund ihrer Bezeichnung auf der nächsthöheren Ebene beheimatet sein. Auch scheint ihre Aufgabenstellung ambivalent, denn zum einen dienen sie dem Verteilen von Identitäteninformationen via Provisionierungs- und/oder einfachen Verteilungs- sowie Replizierungsmechismen (Referrals, Chaining, Shadowing), zum deren wird ihr Einsatz auf den Authentitfizierungsprozess reduziert. Ihren Ursprung haben diese Directiories jedoch, historisch gesehen, in der sog. kollaborativen Aufgabenerfüllung im Zuge der Einführung von Unternehmens- resp. Intretportalen und sind in erster Linie Verzeichnisse i. S. v. Adressbüchern wie White oder Yellow Pages, die hier hauptsächlich der Konsolidierung und zentralen Verwaltung personenbezogener Daten größeren Orgisationseinheiten dienen. Aber auch dere Objekte wie z. B. Orgisationseinheiten und/oder IT-Komponenten, die im Rahmen von Systemmagement konsolidiert vorgehalten werden müssen und/oder entsprechend auf weitere Verzeichnisse verteilen zu können, können ebenfalls in solche Verzeichnisse Einzug halten. Std: Seite 36 von 82

37 len) die Daten für IDM-Aspirten konsolidieren und ggf. wieder diese Datenbestände und/oder dere verteilen (provisionieren). Sind einige orgisatorische, prozessuale und datentechnische Voraussetzungen in Hinblick auf das gegeben, wie z. B. relativ kleine Orgisationseinheit mit geringem Datenaufkommen sowie direkte Provisionierung aus einem konsolidiertem höherer oder gleicher, d.h lokaler Ebene, so kn hier die Aufgabe der Konsolidierung über ein explizites entfallen (1. Ausprägung) und sich in Richtung Authentifizierung verschieben, um Personen ihrer Orgisationszugehörigkeit gemäß Zugriffsberechtigungen zu gewähren. Eine strikte Trennung von partieller und lokaler Ebene ist nicht mehr gegeben, sodass diese hier verschmelzen. Stehen die dieser Ebene in direktem Bezug zur regionalen Ebene, so findet die Konsolidierung und Provisionierung hd eines wohl definierten, für alle partizipierenden möglichst identischen Attributrahmens statt. Für die Datenkonsolidierung wird es zwei Möglichkeiten geben: Alle Identitäten werden komplett aus den unterschiedlichen externen Datenbeständen erstellt und bilden die volle Vereinigungsmenge aller Identitäten einer Orgisation resp. Orgisationseinheit Eine Teilmenge der Identitäten wird aus den verschiedenen externen Datenbeständen gewonnen Für den o. g. Attributrahmen werden aus den externen Datenbeständen die Attribute komplett oder in Teilmengen übernommen und/oder um weitere Attribute ergänzt. Mit Hilfe dieser Struktur werden wohl definierte Übergabepunkte zwischen den Orgisationen resp. Orgisationseinheiten geschaffen und partikuläre Vertwortungen und Datenhoheit verbleiben in den jeweiligen Identitätsdaten bereitstellenden Hochschuleinrichtungen, wodurch eine gewisse Autonomie gewährleistet ist. III Regionale Ebene Auf regionaler Ebene wird IDM hochschulübergreifend betrieben. Hierfür sind im alle relevten Identitäten der involvierten Hochschulen hinterlegt. Hauptaufgabe dieser Ebene ist die Identifizierung und die Registrierung. Der Prozess der Identifizierung umfasst die Verifizierung von Identitäten hd bestimmter Attributkombinationen und/oder Identifikatoren, um mit Sicherheit grenzender Wahrscheinlichkeit feststellen zu können, ob eine bestimmte Person zum ersten Mal in Erscheinung tritt oder ob sie schon einmal erfasst wurde. Im letzteren Falle wird der vorhdenen Identität der neue Attributrahmen mit den neuen oder modifizierten Informationen zugewiesen und wieder bereitgestellt. Konnte die Existenz einer Identität nicht verifiziert werden, so wird die Person registriert, indem dem Attributrahmen ein nach bestimmten Regeln generierter Identifikator zugewiesen wird, der mit dieser Person während seiner gesamten Lebensdauer in einer eineindeutigen Relation verhaftet bleibt. Bei Existenz in den jeweiligen Namensräumen aller untergeordneten ist der Identifikator immer identisch. Std: Seite 37 von 82

38 Um einen ggf. weltweit eindeutigen Identifikator in dieser hier vorhdenen dezentralen Welt zu generieren, bietet sich die Verwendung von sog. Object Identifiers (OIDs), die über eine Baumstruktur weltweit eindeutige Kennungen für Objekte repräsentieren und in ISO/IEC normiert sind. III Überregionale Ebene Für diese Ebene sie beispielhaft ein Vorhaben skizziert, dem der DFN-Verein 14 derzeit arbeitet. Es geht hier um den Aufbau einer Infrastruktur für Authentifizierung und Autorisierung (kurz: DFN-AAI), mit der die bisherigen Verfahren für den kontrollierten Zugg zu Informationen nicht nur vereinfacht, sondern auch vereinheitlicht werden sollen. Um diese Infrastruktur, deren technische Realisierung auf der Middleware Shibboleth basiert, mit einer definierten Dienstgüte zur Verfügung stellen zu können, werden mit den Partnern als Föderationsmitgliedern, d.h. mit den Anwendern, die ihren Nutzern dezentral bereitgestellte Web-Dienste zugänglich machen wollen, und Anbietern, die diese Dienste auf ihrer Web-Site zur Verfügung stellen, vertragsrechtliche Vereinbarungen getroffen. Shibboleth ist ein Verfahren für verteilte Authentifizierung und Autorisierung, um Web- Dienste unter Verwendung von SAML 15 gesichert zur Disposition stellen zu können. Hierbei muss ein Nutzer sich nur einmal bei seiner Heimateinrichtung authentisieren (Single-Sign- On), um orts-unabhängig auf die bereitgestellten Web-Dienste der Anbieter zugreifen zu können. 13 ITU-T Recommendation X.660 (1992), ISO/IEC : 1993, Information Technology Open Systems Interconnection Systems Magement Overview Procedures for the Operation of OSI Registration Authorities: General Procedures 14 vgl Security Assertion Markup Lguage (SAML): XML-basierten Scriptsprache, mit der vertrauliche und sicherheitsrelevte Informationen zwischen Instzen ausgetauscht werden für SSO- und Autorisierngsdienste sowie verteilte Trsaktionen. SAML besteht aus SAML-Assertions, aus dem SAML- Protokoll, aus SAML-Bindings und Profilen. (vgl. ) Std: Seite 38 von 82

39 Aus der Menge der drei Dienstleistungsbereiche von Shibboleth übernimmt der DFN-Verein den Betrieb des Lokalisierungsdienstes (WAYF: Where are you from? also: Woher kommst du? ), während die Implementierung und Betrieb der deren den Partnern obliegt. Der Anwender übernimmt mit seinem Identity Provider die Bereitstellung eines Identifizierungs- (Wer bist du?) und Autorisierungsdienstes (Was darfst du?) sowie die Identitätenverwaltung, während der Anbieter mit seinem Service Provider die Magementdienste für die gesicherte Bereitstellung der Web-Dienste liefert. Im Rahmen des Projektes ecampus II führen 6 Hamburger Hochschulen sowie die Staatsund Universitätsbibliothek im Verbund ein hochschulübergreifendes Identitätsmagementsystem (kurz: ecampus-idms) ein, in dem ein konsolidierter Bestd Nutzern gehalten wird, denen regional, d.h. hamburgweit mit Hilfe lokaler, hochschulspezifischer Systeme autorisierte Zugriffe auf bestimmte IT-Ressourcen hochschulunabhängig ermöglicht werden soll. Als Erweiterung strebt der Hochschulverbund eine Partizipation als Anwender der im DFN-Verein entstehenden föderativen Orgisationsstruktur, um seinen Nutzern weitere ggf. überregionale Dienste relativ einfach und Datenschutz konform zur Disposition stellen zu können. Hierzu bedarf es neben den vertraglichen Regelungen der Implementation einer eigenen oder der Einbindung in die vom DFN bereitgestellten PKI 16 und eines Web-Servers als Identity-Provider (kurz: ecampus-idp) sowie dessen Anbindung das ecampus-idms 16 Mit Public-Key-Infrastruktur (PKI, engl. public key infrastructure) bezeichnet m in der Kryptologie ein System, welches es ermöglicht, digitale Zertifikate auszustellen, zu verteilen und zu prüfen. Die innerhalb einer PKI ausgestellten Zertifikate werden zur Absicherung computergestützter Kommunikation verwendet. ( ) Std: Seite 39 von 82

40 III Identifizierung und Registrierung digitaler Identitäten Die Identifizierung einer digitalen Identität umfasst innerhalb ihres Erzeugungsprozesses und nach Erfassen relevter Attribute eines Datensatzes in einem Quellsystem die Verifizierung, um mit Sicherheit grenzender Wahrscheinlichkeit feststellen zu können, ob eine bestimmte Person zum ersten Mal im System in Erscheinung tritt oder ob sie schon einmal erfasst wurde. Im letzteren Falle werden der vorhdenen Identität die neuen oder modifizierten Informationen zugewiesen und je nach Regelwerk den deren IDM-Systemen weitergeleitet. Konnte die Existenz einer Identität nicht verifiziert werden, so wird die Person registriert, d.h. eine digitale Identität neu gelegt, und entsprechende Informationen die deren Systeme übergeben. (Die nachfolgende Grafik beschreibt einen möglichen Ablauf) Tritt eine sog. Kollision auf, d.h. lässt sich nicht relativ sicher feststellen, ob eine digitale I- dentität neu erzeugt werden soll, so muss diese Kollision durch Einsatz kognitiver Fähigkeiten menschlicher Ressourcen, d.h. mithilfe eines Experten aufgelöst werden. Std: Seite 40 von 82

41 III Datenbereinigung Zu den wichtigsten Aktivitäten, um in der gesamten IDM-Architektur die jeweiligen Identitätenrepositories konsolidiert zu halten, ist die Datenbereinigung (engl. data cleing oder data scrubbing). Zu ihr gehören verschiedene Verfahren zum Entfernen und Korrigieren von Datenfehlern in Informationssystemen. Die Fehler können beispielsweise aus inkorrekten (ursprünglich falschen oder veralteten), redundten, inkonsistenten oder falsch formatierten Daten bestehen. Die Datenbereinigung ist ein Beitrag zur Verbesserung der Informationsqualität. Allerdings betrifft Informationsqualität auch viele weitere Eigenschaften von Datenquellen (Glaubwürdigkeit, Relevz, Verfügbarkeit, Kosten etc.), die sich mittels Datenbereinigung nicht verbessern lassen. Wesentliche Schritte zur Datenbereinigung sind die Duplikaterkennung (Erkennen und Zusammenlegen von gleichen Datensätzen) und Datenfusion (Zusammenführen und Vervollständigen lückenhafter Daten). Aufgrund unterschiedlicher Datenqualität entstehen beim Erkennen von Dubletten und Datenfusion von Identitäten resp. deren Datensätze aus unterschiedlichen Quellen Datenkonflikte auf unterschiedlichen Ebenen der Semiotik, die durch syntaktische (Datenformat), semtische (Einzelwortbedeutung) und/oder pragmatische (kontextbezogene Bedeutung, Domänenwissen) Unzulänglichkeiten hervorgerufen werden können. So werden z. B. Dubletten häufig ungewollt durch Tippfehler, Hörfehler, Buchstaben- und Wortdreher, Abkürzungen, unterschiedliche Schreibweisen usw. produziert. Viele Datenfehler lassen sich von vornherein durch domänenspezifische Normalisierung und/oder Trsformation sowie durch Stdardisierung der Daten beheben. III.1.5 Datenschutzrechtliche Aspekte Im Zuge der Nutzung eines werden personenbezogene Daten (z. B. Name, Adresse, Rollen und Berechtigungen, Relationen zu Orgisationseinheiten etc.) verarbeitet. Hierbei können die Daten einem Ort erhoben, einem deren gespeichert und/oder einem dritten verwendet werden. Die Rechtsgrundlage dieser Datenverarbeitung gründet sich auf 111 Hamburgisches Hochschulgesetz (HmbHG) i. V. m. der Aufgabenerfüllung der Hochschulen nach 2 Hochschulrahmengesetz (HRG). Im Rahmen dieser Vorgänge sind bestimmte datenschutzrechtliche Bedingungen zu beachten, welche die Art und Weise der Datenverarbeitung im IDM mehr oder weniger stark beeinflussen. Geregelt werden die entsprechenden Anforderungen u. a. im Bundesdatenschutzgesetz (BDSG) resp. Hamburger Datenschutzgesetz (HmbDSG), Mediendienstestaatsvertrag (MDStV), Teledienstedatenschutzgesetz (TDSV) und Telekommunikationsgesetz (TKG) In Ergänzung hierzu sind auch entsprechende Betriebs- resp. Dienstvereinbarungen zu berücksichtigen, in denen die Verarbeitung personenbezogener Daten sowie die Ausübung des informationellen Selbstbestimmungsrechtes näher spezifiziert und mifestiert sind. III Datenarten Die unterschiedlichen Datenarten, die während der Verarbeitungsprozesse fallen lassen sich wie folgt unterscheiden: Bestdsdaten werden dem Betroffenen auf Dauer zugeordnet (Stammdaten). Sie sind notwendig, um gebotene Applikationen und Dienste nutzen zu können. In der Std: Seite 41 von 82

42 Regel sind das Angaben wie Name, Anschrift, -Adresse, Telefon- oder Telefaxnummer, Geburtsdatum etc. Nutzungsdaten sind solche Informationen, die erforderlich sind, um die Inspruchnahme der Applikationen resp. Dienste zu ermöglichen und abzurechnen. Hauptsächlich versteht m darunter insbesondere Merkmale zur Identifikation des Nutzers, Angaben über Beginn und Ende sowie über den Umfg der jeweiligen Nutzung sowie Angaben über die vom Nutzer in Anspruch genommenen Dienste. Sind diese Nutzungsdaten wiederum für die Verrechnung von Kosten notwendig, werden sie Abrechnungsdaten gennt, für die besondere Verpflichtungen gelten. Verbindungsdaten, wie z. B. IP-Adressen, entstehen, wenn auf gebotene Dienste zugegriffen wird. Sie werden gespeichert, um z. B. Sicherheitsverstöße aufdecken zu können. III Zulässigkeit Da die Erhebung, Verarbeitung und Nutzung personenbezogener Daten das Grundrecht auf informationelle Selbstbestimmung tgiert, muss vor Implementation eines IDM-Systems geprüft werden, inwieweit die Speicherung der zweckgebundenen Daten hinsichtlich entsprechender Rechtsvorschriften und (tarif-)vertraglicher Regelungen zulässig ist und/oder die bewusste Einwilligung des Betroffenen vorliegt. III Erforderlichkeit, Datenvermeidung und -sparsamkeit Eine Erhebung, Verarbeitung und Nutzung personenbezogener Daten ist nur erforderlich, wenn die jeweilige Aufgabe ohne das konkrete Datum nicht, unter unverhältnismäßig großen Schwierigkeiten, mit prohibitivem Aufwd, verspätet oder nicht vollständig erfüllt werden kn. A priori ist eine Datenerhebung auf Vorrat ist unzulässig und die gespeicherten Daten sollten zum frühestmöglichen Zeitpunkt gelöscht oder zumindest der Personenbezug durch Anonymisierung aufgehoben oder durch Pseudonymisierung gelockert werden können. Grundsätzlich ist bei der Gestaltung des IDM-Systems darauf zu achten, dass bei der Verarbeitung und Speicherung die Mengen personenbezogener resp. -beziehbarer Daten auf ein Minimum beschränkt oder gar vermieden werden können. III Zweckbindung Das Gebot der Zweckbindung soll sicherstellen, dass Daten der digitalen Identitäten nur für den Zweck verarbeitet werden, für den sie erhoben worden sind. Der Zweck der Datenverarbeitung folgt aus der jeweiligen Fachaufgabe, zu deren Erfüllung die Daten erhoben wurden. Eine Datenverarbeitung zu einem deren als dem ursprünglich festgelegten Zweck ist als Zweckänderung oder Zweckdurchbrechung nur auf gesetzlicher Grundlage oder dn zulässig, wenn der Betroffene eingewilligt hat. Dies gilt auch dn, wenn die Daten innerhalb einer Hochschule eine dere Stelle mit einer deren, über bloße Hilfsfunktionen hinausgehenden Aufgabenstellung weitergegeben werden sollen. III Trsparenz und Korrekturrechte Das informationelle Selbstbestimmungsrecht für Betroffene, deren digitale Identitäten gespeichert sind, setzt Kenntnis über die Struktur der Datenverarbeitung, über die Datenverarbeitungsprozesse, über die eingesetzte Technik und über die Datenströme voraus. Jede Fachwendung der Hochschulen muss die Betroffenen über die Verarbeitung ihrer personenbezogenen Daten und über die Daten verarbeitenden Stellen informieren. Std: Seite 42 von 82

43 Betroffene, deren digitale Identitäten gespeichert sind, haben Anspruch auf Korrektur, Löschung und Sperrung der zu ihrer Person gespeicherten Daten. Daten sind außerdem zu sperren, wenn ihre Richtigkeit nicht eindeutig ist. III.1.6 IT-Servicemagement Identitätsmagement ist aus der Sicht eines Nutzers eine Dienstleistung resp. Dienst, dessen Funktionalitäten als Unterstützung der Geschäftsprozesse aus Forschung und Lehre sowie der Unterstützungsprozesse aus der Studienverwaltung zur Disposition gestellt werden. Diejenige Orgisationseinheit, die einen solchen Dienst den Hochschulen oder innerhalb einer Hochschule ihren Einrichtungen wie Fakultäten, Departments etc. bereitstellt, ist Liefert und damit Dienstleister und steht mit seinen Dienstnutzern in einer kontraktähnlichen Beziehung, die in Form eines Regelwerkes aus Service- (SLA) resp. Operation-Level- Agreements (OLA) definiert sein sollte, um die zu liefernde resp. gelieferte Dienstgüte hd von Bedingungen und Kriterien hinreichend genug und nachmessbar hd bestimmter Kennzahlen festschreiben resp. feststellen und ggf. einfordern zu können. Hierfür muss Identitätsmagement intern effektiv kontrolliert und verwalten werden und extern den Kunden effizient und nutzbringend geliefert werden, was der Implementation eines definierten IDM-Service-Magements bedarf. III Prozessorientierung Gerade der Einsatz hochschulübergreifender Systeme mit ausgeprägter Serviceausrichtung der Hamburger Hochschulen führt zu einem gzheitlichen serviceorientierten Ansatz aus prozessualer, applikativer, infrastrukturieller sowie orgisatorischer Sicht. Dieser Ansatz geht mit der Forderung für mehr Trsparenz der Geschäftsprozesse, mehr Kundenorientierung und weniger Abschottungsdenken einher, um mehr Synergien und damit mehr Nutzen, Sicherheit und Nachhaltigkeit im ökonomischen, ökologischen und sozialen Sinne zu generieren. definieren interagieren Prozesse Applikationen IT-Infrastruktur Orgisation unterstützen Im Zentrum des hier vorliegenden Überlegungsmusters steht der Prozess, der sich der Sicht und dem Verständnis des Kunden resp. Dienstnutzers zu orientieren hat. In diesem Std: Seite 43 von 82

44 Zusammenhg ist es nicht mehr wichtig, welche Orgisationseinheit als Diensterbringer den Prozess erledigt, sondern welche Prozessschritte von wem, entlg einer definierten Prozesskette, am effizientesten erledigt werden können. Auch bestimmen nicht mehr die eingesetzten Applikations- und IT-Infrastruktursysteme den prozessualen Verlauf, sondern ihr Einsatz und Selektion wird hd des Prozesses definiert, den sie entsprechend zu unterstützen haben. Zwischen Prozessen und den eingesetzten Applikationen sowie der darunter liegenden IT- Infrastruktur besteht in Richtung Orgisation eine Wechselwirkung und das Gesamtsystem ist damit nicht rückkopplungsfrei. Auf der einen Seite werden Prozesse operativ, taktisch und strategisch durch entsprechende Orgisationseinheiten mit Leben gefüllt und die eingesetzten technischen IT-Komponenten betrieben und unterhalten, auf der deren Seite aber bestimmen die Prozesse sowie die eingesetzten IT-Komponenten die Ausprägung der gesamten Orgisation. III Umsetzungskontext ITIL Um die Prozesse im Service-Magement-Umfeld zu definieren, könnte als Grundlage das Prozessmodell der IT-Infrastructure-Library (ITIL) verwendet werden, denn ITIL gilt heute mehr denn je als der "de-facto Stdard" für den Aufbau von IT-Service-Orgisationen. Solche Orgisationen sind als sozioinformatorische Systeme, bestehend aus Hardware, (Anwendungs-)Software, Personal, Prozesse etc., zu verstehen, die der Unterstützung von Geschäftsprozessen dienen. Gleichzeitig ist ITIL kompatibel zur Norm DIN ISO 9001:2000, die in Deutschld als Basis wichtiger Zertifizierungen dient, und weiteren Normen und Stdards 17, die ggf. Aspekte ergänzen und/oder dere Schwerpunkte setzen; hier sind u. a. IT-Grundschutz-Stdards des BSI zu nennen. ITIL ist eine Prozessbibliothek, in der Verfahren und Richtlinien (Policies) für den IT-Betrieb und -Produktion in Form von sog. Schablonen (Templates) für ein prozessorientiertes IT- Magement festgelegt. Im hier fokussierten Kontext stammen diese Schablonen hauptsächlich aus den Sets Service Delivery und Service Support. Die einzelnen Module des Service Delivery Set setzen sich mit den Kundenerwartungen über die in Anspruch genommenen Dienstleistungen auseinder: Availability Magement: Gewährleistung einer adäquaten Verfügbarkeit des - Services Capacity Magement: Disposition entsprechender Ressourcen mit ausreichender Performce IT-Service Continuity Magement: Vorsorgemaßnahmen für den Katastrophenfall Service Level Magement: vertragliche Regelung der Dienstleistungen in SLAs oder OLAs Die Module des Service Support Set behdeln die zentralen operativen Unterstützungsfunktionen: Configuration Magement: zusammenhängende und stets aktuelle Dokumentation aller Komponenten und ihrer Relationen zueinder als zentrale Basis für den Service(Help)-Desk und dem Problem- sowie Chge-Magement 17 vgl. KBSt: ITIL und Stdards für IT-Prozesse Prozess-Stdards für die Entwicklung der IT- Service-Orgisation gemäß ITIL Best Practices, Version 1.0.1, KBSt-Brief 1/2006, Oktober 2006, Herausgeber: Bundesministerium des Innern Std: Seite 44 von 82

45 Service Desk: zentrale Schnittstelle zum Anwender resp. Kunden Incident Magement: Behdlung von Störfällen, Anfragen und Beschwerden Problem Magement: nachhaltige Behebung der Störungsursachen Chge Magement: sichere und umfassende Durchführung von Änderungen der IT-Infrastruktur Release Magement: kontrollierte Verteilung neuer oder geänderter Komponenten Quelle: HiSolutions AG Zu ergänzen, da nicht Teil von ITIL 18, ist das Gze noch um das Thema IT-Asset- Magement, also um den Aspekt des Lebenszyklus von Hard- und Software sowie deren Lizenz- und Wartungsverträge. Andere Sets, die hier ggf. noch in Betracht kämen, wären: Business Perspective Set: Richtlinien zum Business Reengineering, d.h. Umstrukturierung mit klarer Definition der originären Kernkompetenzen resp. -geschäfte mit der Konzentration der Kräfte auf die kritischen Erfolgsfaktoren Magers Set: lgfristige Plung und Treffen strategischer Entscheidungen in Hinblick auf Mitarbeiter sowie Lieferten- und Kundenbeziehungen unter Berücksichtigung des Qualitätsmagements Computer Operations Set: Plung, Anschaffung und Betrieb großer Rechnerinstallationen Networks Set: Aspekte verteilter Infrastrukturen, insbesondere von Client/Server- Architekturen 18 Die hier beschriebenen Module basierend auf ITIL V2, in ITIL V3 ist dieser Aspekt berücksichtigt Std: Seite 45 von 82

46 Für die Prozessimplementierung wird das Process Maturity Modell (PMM), ähnlich dem Capability Maturity Modell in der Softwaretechnik, verwendet, das eine Ordinalskala mit 6 Reifegraden bereitstellt, in der die aktuelle und zukünftig für das Unternehmen relevte Ausprägung der einzelnen Prozesse dargestellt werden kn. Sollen die Fähigkeiten von Prozessen eines Unternehmens verbessert werden, müssen im Allgemeinen folgende Phasen während der Prozessimplementierung durchlaufen werden: Ermittlung des IST-Zustdes Erarbeitung des SOLL-Zustdes Entwicklung und Definition der Maßnahmen zur Erreichung des SOLL-Zustds Erstellung eines Pls zur Durchführung dieser Maßnahmen Implementation der Prozesse Den Kern dieses Modells bilden einerseits die Prozessfähigkeit, die das Ausmaß der erwarteten Ergebnisse beschreibt, welche durch die Prozessausführung erreicht werden kn und dererseits die Prozessreife, die beschreibt, inwiefern ein Prozess explizit definiert, geführt, gemessen, gesteuert, kontrolliert und verbessert wird. III.1.7 Identitätsmagementsystem im RRZ der Universität Hamburg (UHH-) Das UHH- ist das zentrale Identitätsmagementsystem der UHH, das das als operativer Pilot in der ersten Phase am regionalen Rechenzentrum der Universität Hamburg (RRZ) eingeführt resp. implementiert wird. Dieses Kernsystem wird nach Vollendung der ersten Phase dn sukzessive weiter ausgebaut werden. Der erste Schritt in der Realisierung des UHH- fokussiert auf Studierendendaten der Universität Hamburg, deren autoritative Quelle im Campusmagementsystem STiNE zu finden ist. Dieses System bildet mit seinen innewohnenden applikativen Komponenten gleichzeitig ein Provisionierungsziel für das UHH-. STiNE auf der einen Seite, hat das UHH- auf der deren Seite die zentrale Benutzerverwaltung (ZenBen) der Universität Hamburg, deren eingeführte Abläufe gerade in Hinblick auf die von ZenBen provsionierten Zielsysteme in der ersten Phase soweit wie möglich genutzt werden sollen. Somit steht das UHH-, das gem. IDM-Schichtenmodell auf der lokalen Ebene gesiedelt ist, als intermediäres System zwischen diesen beiden eben gennten Systemen und liefert aufgrund eines hohen Automatisierungsgrades in der Interoperabilität zwischen diesen einen ersten Mehrwert. Gleichzeitig wird eine Plattform geschaffen, die als Basis für die Aufnahme weitere Abläufe und Konnexionen dient, mit dem Ziel, Aufgaben von ZenBen zu ü- bernehmen, weitere Systeme zubinden und einen Brückenkopf zum hochschulübergreifenden IDM-Verfahren (ecampus II) zu schaffen, das auf der nächsthöheren und damit regionalen Ebene der IDM-Architektur loziert ist. III Systemarchitektur III Rechnersysteme und -netze Bei der Entwicklung der Systemarchitektur wurden aufgrund der beknten unterschiedlichen Schutzbedarfe involvierter Anwendungssysteme (z. B. Campusmagementsystem STiNE) und Netzsegmente Empfehlungen und Maßnahmen aus den vom BSI (Bundesamt für Sicherheit in der Informationstechnik) bereitgestellten IT-Grundschutzkatalogen mit einbezogen. Std: Seite 46 von 82

47 Für den Aufbau des IDM-System UHH- im Rechenzentrum der UHH wurden folgende Hardware-Komponenten beschafft: Produktionsserver (UHH--Production) Replikationsserver (UHH--Replica) Abgesetzte Speichereinheit (UHH--Storage) Proxyserver (STiNE-Proxy) Die Rechner für den Produktions- und Replikationsserver sind beide technisch identisch ausgelegt. Sie besitzen redundte Netzteile und jeweils 2 Festplatten, die als RAID1-System konfiguriert sind. Hierdurch wird die gesamte Systemsoftware (Betriebssystem, edirectory, Identity Mager Vers. 3) gespiegelt und die beiden Platten repräsentieren zusammen in jedem Rechner eine logische Systemplatte. Die Produktionsdaten, hauptsächlich die mit Identitätendaten gefüllten Verzeichnisbäume des edirectory, werden in einer abgesetzten Speichereinheit abgelegt, auf die sowohl der Produktions- wie auch der Replikationsserver disjunkt via SCSI-Verbindungen zugreifen können. Z.Z stehen für jeden Rechner jeweils 2 Festplatten zur Disposition, die als RAID1- System konfiguriert sind. Das System ist skalierbar konzipiert, so dass auch ein Umstieg in jetziger Systemkonfiguration auf Raid 5 im Falle einer explosionsartigen Anstieges des Datenvolumens möglich ist. Der Produktions- und der Replikationsserver sind hinsichtlich Systemsoftware identisch konfiguriert und der Datenbestd des Replikationsservers wird laufend durch den Produktionsserver aktualisiert. Über diese Quasi-Synchronität fungiert der Replikationsserver als sog. Hot-Std-by- und Hot-Backup-System. D.h. er steht solge in Warteposition, bis bei Ausfall oder definiertem Abschalten (z. B. für Wartungsarbeiten) des Produktionsservers der Failover resp. Switchover eingeleitet wird, wobei die sich auf dem Replikationsserver befindli- Std: Seite 47 von 82

48 chen Konnektoren vom Administrator aktiviert werden, so dass er die Aufgaben des Produktionsservers übernehmen kn. Nach Inbetriebnahme des Produktionsservers und Durchführen des eben beschriebenen Vorgges mit vertauschten Rollen von Produktions- und Replikationsserver geht die Aufgabe der Identitätenverwaltung wieder den Produktionsserver. Die beschafften Komponenten stehen aus datenschutzrechtlichen Sicherheitsgründen in einer über Firewalls geschützten sog. entmilitarisierten Zone (UHH-IDM-DMZ), die die Übergänge zwischen dem Netz des Campusmagement (STiNE) mit hohen Schutzbedarf und dem Wissenschaftsnetz mit niedrigem Schutzbedarf regelt. Des Weiteren wurde ein Rechner beschafft, der in Richtung STiNE-Netz Microsoft-Welt eine sog. Proxy-Funktionalität übernimmt. Dieser Proxy ist der Domäne STiNE zuzuordnen, wo er als sog. Windows-Member-Server, der z. B. als Datei-, Applikations-, Datenbk-, Remote-Access-Server, Firewall usw. eingerichtet sein kn. Über diese Isolationsmechismen werden Zonen mit unterschiedlichen Sicherheitsbedarfen logisch entkoppelt, da ein direkter Durchgriff vermieden wird, gleichzeitig jedoch wird ein Übergg zwischen den beiden Netzen geschaffen, die zueinder ein unterschiedliches Niveau in Hinblick auf Vertrauenswürdigkeit resp. Schutzbedarf aufweisen. III Applikation Die IT-Anwendung Identitätenverwaltung setzt sich aus dem Verzeichnisdienst e- Directory als Identitätenrepository und dem darauf aufgesetzten Identity Mager 3 (kurz: IDM3), der für die Provisionierungsprozesse zuständig ist, zusammen. Beide Produkte entstammen dem Hause Novell und befinden sich auf dem IDM-Serversystem. Der IDM3 ist zuständig für die Synchronisation der Daten und Durchsetzen der für diesen Synchronisationsprozess formulierten und aktivierten Policies zwischen dem e-directory (Identity Vault) und den geschlossenen Systemen. Die über Konnektoren (Identity Mager Driver) gebundenen Systeme können u. a. aus Anwendungen, Verzeichnisdienste, Datenbken sowie Dateien bestehen. So bilden hier z. Z. in (Subscriber) resp. aus (Publisher) Richtung STiNE Dateien sowie ein Verzeichnisdienst und in resp. aus Richtung ZenBen Dateien gebundene Systeme. Quelle: Novell Identity Mager 3.0 Administration Guide Std: Seite 48 von 82

49 Die Metadirectory Engine verarbeitet Daten und Ereignisse aus dem edirectory unter Nutzung von XML-Dokumenten. Hierbei verwendet sie entsprechende Policies, ihren Regelprozessor und ihre Datentrsformationsmaschine. Im edirectory, dem Identitätenrepository, werden die Identitätendaten baumartig orgisiert und mit Hilfe von Objektklassen und attributen abgespeichert, wobei das proprietäre Kommunikationsprotokoll NDAP (Novell Directory Access Protocol) für den Datenaustausch zwischen IDM3 und edirectory verwendet wird. Laufen die o. g. Anwendungssysteme jeweils auf dem Produktions- und Replikationsserver, so ist eine weitere wichtige Komponente, der sog. Remoteloader auf dem STiNE-Proxy beheimatet. Der Remoteloader unterstützt als Bindeglied die bidirektionale Passwortsynchronisation zwischen STiNE und IDM3 des UHH- bei der Annahme und Verteilung geänderter Passwörter. Die Besonderheit liegt hier in der Passwortnahme, deren Implementation notwendig ist, da im Verwaltungs- und Wissenschaftskontext aktuell unterschiedliche Passwortrichtlinien mit zu einder differierenden Änderungsintervallen definiert sind, sonsten soll zentraler Stelle über eine entsprechenden Web-Applikation die Möglichkeit der Passwortpflege bestehen, über die der IDM3 entsprechende Passwörter entgegennimmt und die gekoppelten Systeme verteilt. Quelle: Novell Identity Mager Driver for Active Directory 3.5 Implementation Guide III Konzeptuelles Datenmodell und Attribute Das hier vorgestellte konzeptuelle Datenmodell ist als Grundgerüst für das UHH- zu verstehen und verfolgt in den ersten Umsetzungszyklen einen minimalistischen Ansatz. Die resultierenden Attribute, d.h. die erfassten personenbezogenen resp. beziehbaren Bestdsdaten lassen sich für den Verarbeitungsprozess wie folgt gruppieren: Identifizierungsmerkmale Erreichbarkeitsmerkmale Pseudonyme Zuggsorientierte Merkmale Die Identifizierungsmerkmale werden hauptsächlich im Identifizierungsprozess verwendet, der für eine konsolidierte Identitätenbasis sorgen soll. Er umfasst hierbei die Verifizierung von Identitäten, um mit Sicherheit grenzender Wahrscheinlichkeit (ggf. über Ähnlichkeitsmaße) feststellen zu können, ob eine bestimmte Person zum ersten Mal im System in Erscheinung tritt oder ob sie schon einmal erfasst wurde. Im letzteren Falle werden der vorhdenen Identität die neuen oder modifizierten Informationen zugewiesen und je nach Regelwerk deren Systemen weitergeleitet resp. provisioniert. Konnte die Existenz einer Identität nicht verifiziert werden, so wird die Person resp. deren digitale Identität registriert, d.h. Std: Seite 49 von 82

50 der systemimmente Identifikator wird generiert und entsprechende Datensätze werden gelegt sowie wohldefiniert Informationen die Zielsysteme übergeben. Diese Merkmale dienen aber auch späteren Identifizierungen im Rahmen von Ermittlungen aufgrund unerlaubter Hdlungen. Die Erreichbarkeitsdaten dienen der gezielten Kontaktaufnahme mit einem Nutzer resp. der sich dahinter verbergenden natürlichen Person, um diesem umgehend (Telefon, ) oder in gemessener Zeit (postalisch via ladungsfähiger Anschrift) aus administrativer Sicht Mitteilungen zukommen lassen oder Informationen abverlgen zu können. Die vom Nutzer nicht selbst vergebenen Pseudonyme dienen der Referenzierung, wenn für registrierte Identitäten Erweiterungs- und/oder Modifikationsinformationen zwischen UHH- und Ziel- resp. Quellsystemen ausgetauscht werden. Gleichfalls kn über die vergebenen Pseudonyme (hauptsächlich über den systemimmenten Identifikator) die Identität in bestimmten provisionierten Systemen (z. B. reine Accountverwaltung) verschleiert (pseudonymisiert) werden, indem neben dem personenbeziehbaren Pseudonym keine weiteren personenbezogenen Daten übermittelt werden. Trotz dieser Verschleierung lässt sich im Nachgg mit Hilfe des sog. Auditing in bestimmten rechtsrelevten Fällen eine hdelnde resp. vertwortliche Person über das Instrument des Pseudonyms als die auf sie verweisende Referenz ermitteln. Aus den zuggsorientierten Daten werden die jeweiligen IT-Ressourcen, auf die eine Person Zugriff erhalten soll, sowie die damit verbundenen Zugriffsberechtigungen hergeleitet, d.h. Berechtigungen werden gem. ursachenneutralem Gültigkeitsstatus z. B. erteilt, temporär ausgesetzt oder gelöscht. Kennung/ Passwort PKI- Zertifikat Credential Alumni Smartcard- Token 1,n Gast Identifikator Person 1,1 1,n Profil Studierende 1,1 0,n Lehrende Dienst/ Geschäft Semester 1,n Adresse 1,n 1,1 0,n Orgisation 0,n Forschende Bedienstete Privat 1,1 0,1 0,n 0,n 0,n Anschrift Telefon Web Fax Mobilfunk Festnetz Eine natürliche Person erhält im UHH- während der Registrierung über den erzeugten Identifikator eine eindeutige digitale Identität. Dieser Identifikator ist ein systemimmentes Std: Seite 50 von 82

51 Pseudonym und kn in Kommunikations- resp. Datenaustauschbeziehungen mit deren Systemen als identifizierende Referenz genutzt werden. 19 Der Entitätstyp Person beinhaltet personifizierende Attribute. Zu diesen Identifizierungsmerkmalen zählen u. a.: Nachname(n) Vorname(n) Titel, Anrede (Herr, Frau) Geburtsdatum Geburtsort/-ld Geburtsname (wenn vorhden) Jede Person werden ein oder ggf. mehrere Profile unterschiedlicher Ausprägung zugeordnet, mittels derer eine natürliche Person sich durch die Systemldschaft der Hochschulen bewegt. Ein Profil ist für eine vorbestimmte Zeit mit der Möglichkeit der Verlängerung gültig, kn aber auch temporär außer Kraft gesetzt werden und ist durch seine Ausprägung, der sog. Basisrolle, wie z. B. und Orgisationszugehörigkeit, wie Alumni, Gast, Studierende, Lehrende, Forschende, Bedienstete Hochschule, Fakultät, Department, Institut, Projekt (Teil-)Studiengg Abteilung Referat usw., differenzierbar. Des Weiteren werden, insbesondere in Hinblick auf die Studierenden, Informationen wie (Teil-)Studiengänge mit in die Profile aufagenommen. Aus den Profilen lassen sich ggf. in den IT-Ressourcen zugewdten Systemen spezifische Rollen und Rechte für dedizierte Systemzugänge wie auch Provisionierungsziele ableiten. Neben den Profilen bilden die sog. Credentials, also Berechtigungsnachweise eine wichtige Komponente zuggsorientierter Merkmale, die einer IT-Ressource die Identität des zugreifenden Nutzers bestätigen sollen. Sie werden hauptsächlich auf der partiellen Ebene des IDM-Schichtenmodells für die Zuggkontrolle genutzt. Die Gültigkeitsdauer dieser Berechtigungen kn beschränkt werden und der aktuelle Status liefert mittels ursachenneutraler Werte, wie z. B. erteilt, ausgesetzt oder erloschen, den jeweiligen Zuggskontrollsystemen Informationen, um die IT-Ressourcenzugänge entsprechend steuern zu können. 19 In der ersten Ausbaustufe wird zwischen STiNE und UHH- als Referenz das Pseudonym Matrikelnummer genutzt. Std: Seite 51 von 82

52 Die klassische Ausprägung eines Credential 20 ist die Kombination aus Kennung 21 und Passwort 22. Mit Hilfe dieser eindeutigen Kennungen - hier i. S. v. (Be)Nutzername, (Be)Nutzerkennung, User Name usw. verwendet - erhält eine Person resp. ein Nutzer i. V. m. einem Passwort über einen sog. (User) Account resp. (Be)Nutzerkonto Zugg zu einer bestimmten IT-Ressource. Eine einmal vergebene Kennung wird nicht zurückgenommen und soll dem Nutzer möglichst ein Leben lg zugeteilt bleiben; hat sie keine Bedeutung mehr, wird sie nicht erneut vergeben. Weiterhin ist eine Person über mehrere Wege, wie (ladungsfähige) Anschrift 23 mit Adresszusatz, Straße, Hausnummer, Postleitzahl, Ort, Ld sowie über Telefon, usw. adressierbar und somit erreichbar. Die jeweiligen Adressierungswege gehören zu unterschiedlichen Adressarten. Wie im Datenmodell zu ersehen, ist eine Person direkt durch explizite Zuordnung einer Adresse erreichbar, aber auch ggf. indirekt über die Orgisationszugehörigkeit. III IT-Prozess In STiNE werden Studierende erfasst, die spezifische Zugänge zu resp. Zugriffe auf IT- Ressourcen (z. B. STiNE-Anwendungen, E-Learning-Anwendungen wie z. B. WebCT, Mailbox für s, Storage usw.) erhalten sollen und müssen. Um diese Zugriffe resp. Zugriffsberechtigungen zu gewähren, zu steuern und zu kontrollieren, werden Personen identifizierende, zuggsorientierte sowie Erreichbarkeitsdaten, in einem universitätszentralen Repository des Identitätenverwaltungssystem UHH- gespeichert und verwaltet; d.h. im UHH- werden die hauptsächlich aus STiNE erhaltenen Studierendendaten einer im UHH- erzeugten Identität gehängt, gepflegt und ZenBen und GOLEM wohldefiniert weitergegeben sowie aus ZenBen erzeugte und im UHH- hinterlegte Informationen STiNE provisioniert. III Identifizieren und Registrieren Hauptaufgabe von UHH- während des Erzeugens und der Pflege von Studierendenidentitäten ist die Durchführung der Identifizierung und der Registrierung. 20 Des Weiteren können auch Credential-Arten resp. Authentifizierungsmerkmale wie PKI-Zertifikate nach X.509 und Smartcard-Token usw. hinzukommen, es sind aber auch biometrische Formen wie z. B. Daktylogramme, Spracherkennungs-, Iris-, Retina- oder fazialgeometrische Muster etc. denkbar. 21 Die Hochschule Hamburgs haben sich auf ein Kennungsformat mit maximal 8 Stellen geeinigt (Regulärer Ausdruck: [a-z]{3} [0-9]{3} [a-z0-9]{0,2}). Mit Hilfe des ersten Buchstabens existieren für die Hochschulen Hamburgs vorerst disjunkte Kennungsräume; so hat z. B. die UHH als ersten Buchstaben das b, insgesamt 7 Stellen für die sog. Hauptkennung und über die 8. Stelle die Möglichkeit, sog. Unterkennungen zu vergeben. 22 Unter dem Aspekt der Verwendung von nur einer Kennung und einem Passwort von spezifischen Funktionskennungen einmal abgesehen sowie des sog. Single Sign On erlgt die high-grade - verschlüsselte Speicherung und Übertragung des Passwortes eine besondere Bedeutung, um eine Passwortsynchronisation (z. B. bei Passwortänderungen durch den Nutzer gem. Sicherheitsrichtlinien) mit den Accountverwaltungen der geschlossenen und provisionierten Zielsysteme zu erreichen. 23 Für Bedienstete wird grundsätzlich Dienstschrift und für Studierende die Privatschrift verwendet. Std: Seite 52 von 82

53 Die Identifizierung und Registrierung im UHH- soll für eine konsolidierte Identitätenbasis sorgen. Hierbei umfasst der Dienst der Identifizierung die Verifizierung von Identitäten, um mit Sicherheit grenzender Wahrscheinlichkeit feststellen zu können, ob ein Studierender zum ersten Mal im UHH- in Erscheinung tritt oder ob er schon einmal erfasst wurde. Um dies zu erreichen, werden die von STiNE in einer sog. CSV 24 -Datei abgelegten Datei mit Hilfe des SimSpectors überprüft. Alle Datensätze, die als Dubiose eingestuft wurden, werden aussortiert und müssen muell weiterverarbeitet werden. Konnte hd wohldefinierter Kriterien festgestellt werden, das ein Studierender resp. dessen digitale Identität schon vorhden ist, werden der vorhdenen Identität die neuen oder modifizierten Informationen zugewiesen und je nach Regelwerk weitergeleitet resp. provisioniert. Konnte die Existenz einer Identität nicht verifiziert werden, so wird der Studierende resp. dessen digitale Identität registriert, d.h. ein systemimmente Identifikator, der während seiner gesamten Lebensdauer in einer eineindeutigen Relation zum Studierenden steht, wird generiert und entsprechende Datensätze werden gelegt sowie wohldefiniert Informationen ZenBen und STiNE übergeben. III (De-)Provisionieren und Archivieren Neben dem reinen Lifecyclemagement (Erzeugen, Pflegen, Löschen) unterstützen den Prozess drei weitere Dienste: Provisionieren Deprovisionieren Archivieren Das Provisionieren und Deprovisionieren umfassen jeweils die mittels Push- und/oder Pulltechnik, mehr oder weniger automatisiert, ausgelegten Trsferprozesse. Diese Prozesse sorgen nach dem Erzeugen, Modifizieren (Pflegen) oder vor dem Löschen einer Identität für die Synchronisation, Bereitstellung digitaler Identitäten resp. deren Inhalte im Attributrahmen (in UHH- gespeicherte Anwendungsdaten), sie führen aber auch zum Entzug einmal vergebener Zuggsberechtigung in Hinblick auf mehr oder weniger heterogene Zielsysteme. Dies geschieht mit Hilfe hinterlegter Policies regelbasiert, trsformierend und/oder kollisionsauflösend (s. auch Dublettenbehdlung) über sog. Konnektoren. Digitale Identitäten durchlaufen während ihrer Lebenszeit Metamorphosen, die aufgezeichnet werden, um den Verlauf der Veränderungen einer Identität gegenüber den geschlossenen Zielsystemen trsparent und damit nachprüfbar - zu machen sowie ggf. attestieren zu können, wer in bestimmten Zeitfenstern welche Zugriffberechtigungen gehabt hatte, unabhängig davon ob auf Ressourcen zugegriffen wurde oder nicht. Die Archivierung der Identitätenhistorie könnte z. B. bei rechtsrelevten Verstößen in (direkt) geschlossenen Zielsysteme, in denen nicht der volle Personendatensatz, sondern durch geforderter Pseudonymisierung, ggf. durch datenschutzrechtlicher Relevz hervorgerufen, nur ein eineindeutiger Identifikator als Referenz plus Account (Kennung und Passwort) hinterlegt ist, die Möglichkeit geben, durch Aufdeckung die entsprechende Identität ermitteln zu können, wobei der Identifikator die Referenz liefert. 24 CSV = Comma/Character Separated Value Std: Seite 53 von 82

54 Der Vorgg des sog. logischen Löschens tgiert ebenfalls die Archivierung, will heißen, dass die archivierten identitätsbezogenen Daten, d.h. die Identitätenhistorie noch für einen bestimmten Zeitraum gespeichert verbleiben, um dn endgültig gelöscht werden. III Zuggsberechtigungen Das Entziehen und Erteilen von ggf. abgestufter Zuggsberechtigungen Studierender ist geprägt vom aktuellen Zustd im Verwaltungsprozess, den ein Studierender während seines Lebens der UHH einnimmt. Die nachfolgende Grafik beschreibt im groben Überblick den sog. Lebenszyklus eines Studierenden der UHH. Std: Seite 54 von 82

55 III.1.8 Identitätsmagementsystem der Hochschule für gewdte Wissenschaften Hamburg (HAW-) Schon früh konnte die Erkenntnis gewonnen werden, dass die Einführung einer IDM-Lösung mit nicht zu unterschätzenden orgisatorischen Unwägbarkeiten einhergeht. Beispielsweise ist in diesem Zusammenhg die Umsetzung des Hamburger Hochschulgesetzes bezogen auf die Bildung von Fakultäten zu nennen. Aus orgisatorischer Sicht befindet sich der Prozess seit einiger Zeit in der Umsetzung, aus Sicht der IT-Infrastruktur gab es in diesem Zeitraum jedoch keine Veränderungen, obwohl diese von verschiedenen Seiten befürwortet wurden. Zudem würden diese Veränderungen eine große Chce zur Vereinheitlichung der Systeme bieten, wodurch die Ausgaben für IT-Systeme reduziert werden könnten. Die Orgisationsstrukturen der Hochschule für Angewdte Wissenschaften weisen Lücken im Hinblick auf die Entscheidungskompetenzen bei Veränderungen der IT-Ldschaft auf. Weder das Präsidium noch das Intret Service Center (ISC) sind mit genügend Kompetenzen ausgestattet, um Veränderungen den Strukturen zur Verbesserung der Wirtschaftlichkeit und zur Positionierung der Hochschule im Wettbewerb mit deren Hochschulen nachhaltig herbeiführen zu können. Es wurden bereits vielfältige Anläufe zur Verbesserung der IT-Infrastruktur unternommen, die in verschiedenen Arbeitsgruppen erarbeitet und von allen Beteiligten für gut bis sehr gut befunden wurden. Sie wurden jedoch aufgrund fehlender Entscheidungskompetenzen noch nicht umgesetzt. Als ein Beispiel hierfür ist die Vereinheitlichung der Datei- und Druckservices in der Fakultät Technik und Informatik (TI) zu nennen. Hier wurden in verschiedenen Sitzungen die Anforderungen ein zukünftiges zentrales (orgisatorisch unterhalb der Fakultät TI gesiedeltes) Dateisystem in verschiedenen Workshops diskutiert und mit einem Anforderungskatalog verabschiedet. Aufgrund fehlender Entscheidungskompetenzen ist allerdings auch hier in naher Zukunft nicht mit einer Umsetzung des Projekts zu rechnen. An dem gennten Beispiel ist unter derem zu erkennen, dass nur ein eingeschränktes, individuelles Hdeln von entscheidungsbereiten und treibenden Personen der Hochschule für Angewdte Wissenschaften möglich ist. Ein weiteres wesentliches Hindernis bei der Einführung ist die nicht bis zu den Mitarbeitern der Departments kommunizierte gesamtheitliche IT-Strategie der HAW für die kommenden 3-5 Jahre. Hieraus resultieren vielfach unterschiedliche Denkweisen der Mitarbeiter. Aufgrund der fehlenden Entscheidungskompetenz in Kombination mit der nicht kommunizierten IT-Strategie verändert sich die IT-Ldschaft der HAW nur sehr lgsam. Sie müsste sich aber schneller verändern, damit die Hochschule für Angewdte Wissenschaften wettbewerbsfähig bleibt. III IDM-Architektur Prinzipiell teilen sich IDM-Lösungen in vier funktionale Bereiche auf: Usermagement (Zusammenfassung der Quelle mit Personendaten zu einer hochschulweit eindeutigen Person) Accessmagement (Erweiterung der Person mit Rechten, durch Zuhilfenahme von Regeln und Rollen) Provisioning (intelligente Verteilung der Personendaten die Zielsysteme) Datenhaltung (sichere, ortsübergreifende Speicherung der gewonnenen Daten) In der nachfolgenden Grafik wird zum einen dargestellt, wie sich die Komponenten Usermagement, Accessmagement und Provisioning gegenüber der Datenhaltung verhalten, Std: Seite 55 von 82

56 und zum deren ist das Verhältnis zwischen der zentralen und der dezentralen Administration im Accessmagement dargestellt. III Usermagement Der linke Bereich im strukturellen Überblick dient der Konsolidierung von Personendaten. Hierbei werden aus den Quellsystemen HIS, STiNE, PAISY und der Externenverwaltung die Personendaten zu einer Person zusammengefasst. Zur Verdeutlichung wird nachfolgend ein Beispiel gegeben: Ein Mensch (Hs Mustermn) ist als Person im HIS geführt. Das Semester endet in zwei Monaten, dn erfolgt die Exmatrikulation. Herr Mustermn nimmt einen Job in der Verwaltung und wird im Personalsystem PAISY als Person gelegt. Hiermit existieren zwei Personendatensätze zu einer Person. Das Usermagement fasst diese beiden Datensätze zu einer Person zusammen. In einem Datensatz zu einer Person werden in erster Linie Daten zur Erreichbarkeit (Adresse, Telefonnummer und -Adresse) hinterlegt. Die Schwierigkeit dieses Teilbereichs des Identity-Magements liegt in der Art der Konsolidierung. Die Zusammenführung der Personendatensätze erfolgt ausschließlich auf Basis der Std: Seite 56 von 82

57 Daten, die in den Quellsystemen vorhden sind. Dies gartiert einen automatischen und reibungslosen Ablauf der Konsolidierung. III Accessmagement Zwischen der Zusammenfassung zu einer Person (Usermagement) und der Verteilung der Benutzerdaten in die einzelnen Systeme (Provisioning) muss die Person mit entsprechenden Rechten ausgestattet werden. Diese Rechte werden nicht eine Person sondern eine Rolle gebunden. Mit diesem Ansatz werden die Unabhängigkeit von Personen und eine hohe Flexibilität hinsichtlich der Gestaltung von Zugriffsmechismen gestrebt. Das Ziel des Accessmagements ist es, einer Person Rechte auf automatische oder muelle Weise geben und nehmen zu können. Wird ein/e Studierende/r zu einem Mitarbeiter, werden ihr/ihm automatisch die Rechte, die sie/er aus der Zuordnung der Rolle Studierende/r erhalten hat, entzogen und gleichzeitig die Rechte, die sie/er über die Rolle Mitarbeiter/in erhält, zugewiesen. In bestimmten Fällen ist es nicht möglich, automatisch Rollen zuzuweisen, da aus keinem der Quellsysteme Informationen gewonnen werden können, die Rückschlüsse hierauf zulassen. In diesem Fall ist es Aufgabe des Accessmagements, eine vertwortliche Person zu informieren, die diese Entscheidung(en) trifft und entsprechend eine Rollenzuordnung vor nehmen kn. Diese Person kn sich einer zentralen (z. B. zentrale Administration) oder dezentralen Stelle (z. B. Vertwortlicher eines Departments oder eines Labors) befinden. In der Architekturabbildung ist das Zusammenspiel zwischen dem zentralen und dem dezentralen Accessmagement dargestellt. In letzter Zeit haben sich bei der Erstellung von Rollenkonzepten grundsätzlich zwei Ansätze bewährt. Mit dem einen werden die in den Zielsystemen vergebenen Berechtigungsstrukturen alysiert und wenn möglich zusammengefasst (Bottom-Up-Methode). Der zweite Ansatz (Top-Down-Methode) orientiert sich mehr Orgisationsstrukturen (siehe nachfolgendes Beispiel) und/oder vorhdenen Geschäftsprozessen. In den meisten Fällen sind die vorhdenen Berechtigungsstrukturen in den Zielsystemen sehr komplex und bedürfen eines hohen Zeitaufwdes für die Analyse. Aus diesem Grund wird häufig versucht, einen Mittelweg aus beiden Ansätzen zu wählen, wobei häufig der Top-Down-Ansatz überwiegt. Das grundlegende Prinzip des rollenbasierten Rechtemodells ist die Anforderung, dass ein Benutzer nicht mehr Rechte haben darf, als seine Aufgabe es erfordert. Um die Aufgabe zu definieren, kn m entweder die strukturelle Zuordnung der Person in der Orgisation oder die fachlichen und technischen Funktionen dieser Person betrachten. Die definierte Aufgabe wird nunmehr als fachliche Rolle betrachtet. Eine technische Rolle wird oft über die Abbildung zielsystemspezifischer Berechtigungen definiert und stellt die Verbindung zwischen dem Accessmagement und den Provisioning Services dar. In der folgenden Abbildung ist dargestellt, wie ein/e Studierende/r, die/der ein Studium in einer Fakultät resp. Department absolviert, verwaltet werden könnte. Eine genauere Analyse der zu definierenden Rollen wird im Feinkonzept (in Zusammenarbeit mit den Administratoren der Zielsysteme) erarbeitet. Std: Seite 57 von 82

58 Mailsystem Gruppe 100 MB Mailspace Ebene 1 Person techn. Rolle 1 Gruppe 50 MB Mailspace Ebene 2 Mitarbeiter Student techn. Rolle 2 Filesystem Ebene 3 Student in Fakultät x techn. Rolle 3 Gruppe Homedirectory Ebene 4 Student im Department y techn. Rolle 4 Gruppe Fakultätsshare x Gruppe Departmentshare y In der ersten Ebene erhält das Objekt (Person) die fachliche Rolle (Eigenschaft) Person. Alle weiteren fachlichen Rollen (Studierende/r, Studierende/r in Fakultät x und Studierende/r im Department y) sind in weiteren Ebenen unterhalb der Rolle Person geordnet. D. h., die Zuordnung der fachlichen Rolle Studierende/r im Department y beinhaltet die fachlichen Rollen Studierende/r in der Fakultät x, Studierende/r und Person. Die technischen Rollen, die den fachlichen Rollen zugeordnet sind, werden meist durch Gruppen in den Zielsystemen abgebildet. Wenn einer Person, z. B. die fachliche Rolle Mitarbeiter zugewiesen wurde, wird ihr automatisch auch die entsprechende technische Rolle zugeteilt, die bewirkt, dass er im Zielsystem einem Mailaccount mit 100 MB Mailspace erhält. Kn aufgrund der aus den Quellsystemen gewonnenen Informationen keine automatische Zuordnung der Rollen zu einer Person vorgenommen werden (z.b. Teilnehmer/in einem Laborversuch xy), muss eine muelle Zuordnung stattfinden (dezentral im Department). III Provisioning Nach der Vergabe von Berechtigungen über Rollen und Regeln müssen die hieraus resultierenden Accounts in den Zielsystemen gelegt werden. Dies übernimmt das Provisioning. Die Anbindung der Systeme erfolgt über einen Konnektor, der vom jeweiligen Hersteller zur Verfügung gestellt wird. Alle zurzeit auf dem Markt verfügbaren Systeme sind noch nicht in der Lage, Berechtigungen direkt in den Zielsystemen zu vergeben. Deshalb werden zurzeit Gruppenberechtigungen innerhalb der Zielsysteme vergeben. Ein einfaches Beispiel hierfür ist die Vergabe von Berechtigungen im Filesystem: Soll einem Benutzer das Recht erteilt werden, auf ein Verzeichnis im Dateisystem zugreifen zu können, kn die Erlaubnis nur (im Zielsystem) für eine Gruppe oder dem Benutzer direkt erteilt werden. Das Provisioning ist jedoch in der Lage, nach dem Anlegen des Accounts diesen zu einer Gruppe hinzuzufügen. Der Benutzer übernimmt nach der Authentisierung am Fileserver die Berechtigung der Gruppe und kn auf das entsprechende Verzeichnis zugreifen. Std: Seite 58 von 82

59 III Experiementiersystem HAW- III Ausggslage In der Vorlaufphase zur Einführung eines Hamburgweiten, hochschulübergreifenden IDM- Systems wurde der HAW Hamburg im Rahmen des KoOP-Projektes eine experimentelle Umgebung auf Basis der Produkte Novell Nsure IDM (Evaluation Version) und Novell edirectory 8.7 geschaffen. Die Anbindung der Quellsysteme HISSOS (Informationen über Identitätsdaten der Studierenden) und PAISY (Informationen über Hochschul-Mitarbeiter /innen) war Ende 2005 zu Testzwecken durch die Implementation zweier so gennter Textkonnektoren erfolgt. Die nachfolgende Optimierung und die Ergebnisse zahlreicher Testläufe zur Überprüfung der Funktionalität der implementierten Konnektoren erforderte zyklische Anpassungen von Attributen und eine Fortschreibung des von den Hamburger Hochschulen gemeinsam verabschiedeten Schemas hheduperson. Generell werden beim Entwurf eines Verzeichnisbaums höhere und untergeordnete Ebenen vorgesehen, deren Hierarchie unterschiedlichen Anforderungen der späteren Nutzung gerecht werden muss. Häufig spiegeln die oberen Ebenen eine Orgisationsstruktur mit ihren Einheiten wider, oft auch regionale Untergliederungen oder spezifische Systemfunktionen. Partitionierungen setzen meistens ebenfalls auf den oberen Ebenen. Die untergeordneten Ebenen eines Verzeichnisbaums gliedern einzelne Orgisationsteile und deren spezifische Funktionen. Im Falle des IDM-Systems wird kein Zugriff von außen auf das in der oben beschriebenen Weise strukturierte Verzeichnis erlaubt, welches den Kern des IDM-Systems bildet. Das bedeutet, dass die in der Abbildung aufgezeigte Struktur für keinen Benutzer des Verzeichnisses sichtbar wird. Abfragen zu Informationszwecken werden ausschließlich über das so gennte Corporate Directory realisiert, dessen speziell gepasste Struktur in einem automatisierten Verfahren mit Informationen aus dem IDM-Kern befüllt wird. In früheren Versionen von Verzeichnisdienst-Servern existierten verschiedene Beschränkungen - z. B. wie viele Objekte sich in einem Container befinden dürfen. Diese Beschränkungen bestehen in aktuellen Versionen jedoch nicht mehr und werden daher nicht weiter betrachtet. Std: Seite 59 von 82

60 Zur Erfassung einer studentischen Identität werden die (im KoOP-Zwischenbericht 2005 beschriebenen) Tabellen der HIS-Datenbk ausgewertet und automatisiert die zentrale IDM-Instz weitergeleitet. Bei der Auswahl eines Primärschlüssels (Primary Key) ist deutlich geworden, dass die Matrikelnummer dieser Funktion nicht gerecht werden kn, weil die Hamburger Hochschulen bislg nicht über einen gemeinsamen Mechismus zur Generierung einer Matrikelnummer verfügen. Der Ansatz, eine von der Hochschule zugewiesene Matrikelnummer als Primärschlüssel zu verwenden, wurde daher verworfen. Die Rolle des Primärschlüssels für Studierende übernimmt zurzeit eine vom HIS-System vergebene, individuelle Kennung. Die erste Befüllung des IDM-Systems mit den Identitätsdaten der Mitarbeiterinnen und Mitarbeiter der Hamburger Hochschulen erfolgt durch die Auswertung der Tabellen der PAISY- Datenbk. Das IDM-System empfängt zu diesem Zweck einen Auszug aus dem PAISY- System der Stadt Hamburg. Da Aktualität und Umfg der verfügbaren Mitarbeiterdaten für eine Verwendung im IDM zurzeit nicht zufriedenstellend ausfallen - eine Aktualisierung der Daten, die der Hochschulverwaltung zur Verfügung gestellt werden, erfolgt alle 4 Wochen - wurde im Projektrahmen eine zusätzliche Eingabemaske zur Pflege der Mitarbeiterdaten entwickelt. Technisch kommt der User Application -Treiber, eine Neuentwicklung der Novell-IDM 3 Software, für die Bereitstellung des erforderlichen Webinterfaces zum Einsatz. Auf diese Weise wird eine zeitnahe Pflege (Ändern und Anlegen/Löschen von Mitarbeiterdaten und Externe wie Gastprofessoren, Berater) ermöglicht. III Migration auf Novell IDM 3 Gleichzeitig mit der Beschaffung der Lizenzen für die Novell IDM 3 Software wurde aus HAW-eigenen Mitteln die zugehörige Hardware-Plattform vollständig erneuert. Der mit der Version 3 neu hinzugekommene User Application-Treiber bietet die Möglichkeit einer Webportallösung und eines optimierten Self-Service. Damit wird jedem Benutzer und jeder Benutzerin über einen Web-Zugg (entsprechend den eigenen Berechtigungen) die Ergänzung des eigenen Datensatzes sowie das Ändern des eigenen Passwortes ermöglicht. Der Import der bereits konfigurierten Konnektoren (Schnittstellen-Programme) aus der vorhdenen Test-Umgebung der Version 2 ist ohne große Probleme verlaufen. Lediglich einige zusätzliche Änderungen der flachen Baumstruktur des DIT (Directory Information Tree) wurden vorgenommen, indem die Container mit den Bezeichnungen Mitarbeiter und Externe eingefügt wurden (Abb. 2). Dieses Vorgehen stellt eine Sicherheitsmaßnahme zur Abschottung des Bereichs konsistenter Daten gegenüber dem Arbeitsbereich dar. Als Arbeitsbereich bezeichnen wir den Teil des Datenbaumes in dem über eine Webschnittstelle muell Datensätze gelegt, gelöscht, oder geändert werden. Std: Seite 60 von 82

61 III Projektsachstd Nach der erfolgreichen Migration auf die endgültige Plattform für den Produktivbetrieb des Identity Magement Systems, wurden die Entwicklungsressourcen zunächst auf die Benutzerfreundlichkeit und Bedienbarkeit des Systems konzentriert. Verschiedene Testläufe zur Überprüfung der Funktionalität der Konnektoren wurden mehrfach mit positivem Ergebnis durchgeführt. Die Erkenntnis der mgelhaften Aktualität der Informationen aus dem PAISY-System der Stadt Hamburg erforderte eine Anpassung des entwickelten Algorithmus zum Konsolidieren von Identitäten, welche sowohl in der Kategorie Student als auch in der Kategorie Mitarbeiter existieren. So soll lediglich eine einmalige Befüllung (initial load) zwecks Erfassung der Mitarbeiter aus dem PAISY-System erfolgen. Jedes weitere Einstellungs- oder Entlassungsverfahren führt über einen Direktzugriff autorisierter Mitarbeiter/innen der Abteilung Personalservice auf den Datenbestd des zentralen IDM-Systems. Die Implementation des User Application -Treibers ermöglicht eine rollenbasierte und benutzerfreundliche Abbildung definierter Arbeitsprozesse (Workflows) über eine frei gestaltbare Webschnittstelle, deren Layout bei Bedarf das Corporate Design des Betreibers gepasst werden kn. Das übersichtlich gestaltete Rollenmodell (Student, Mitarbeiter, Externe) bildet die logische Grundlage für die Konfiguration aller Schnittstellen. Std: Seite 61 von 82

62 Mittels der Eingabemaske für Mitarbeiter wird indirekt auf den konsolidierten Datenbestd zugegriffen, indem zunächst der geänderte Datensatz in einem gesonderten Ast des Baumes abgelegt wird. Von dort wird die Information automatisiert über sogennte Loopback- Treiber formatiert und in den konsistenten Datenpool übertragen. Der User-Self-Service ist ebenfalls Bestdteil der User Application und ermöglicht dem jeweiligen Benutzer die Pflege seiner eigenen Daten. Besitzt der User Eigentümerrechte einem Attribut, so darf er dessen Wert (wie z.b. die private Telefonnummer oder das eigene Foto) verändern. Änderungen des Nachnamens oder der Adresse müssen durch die Studierenden- oder Personalverwaltung vorgenommen werden. Std: Seite 62 von 82

63 Die Möglichkeit von Passwortänderungen durch die Benutzer erspart dem Help-Desk häufige Anfragen nach Passwort-Modifikationen. Die Anwender werden beim ersten Wechsel des Passwortes aufgefordert, aus einer Auswahl von Fragen (Beispiel: Name des Lieblingstiers) eine Frage ihrer Wahl zu betworten. Tritt der Fall ein, dass ein Benutzer sein Passwort vergessen hat, kn er nach der Betwortung dieser Frage, über einen selbst hinterlegten Kennworthinweis, sein Passwort zurückzusetzen. III KoOP-Pilotsystem Das im Aufgabenspektrum der HAW (in farblicher Präsentation blau unterlegt) entstdene KoOP-Pilotsystem besteht, wie die nachfolgende Grafik zeigt, aus zwei Komponenten: IM-System KoOP Hochschulübergreifendes Corporate Directory Std: Seite 63 von 82

64 Generell stellen die involvierten Systeme 25 eine umfgreichere Funktionalität und weitere Schnittstellen für im Gesamtkontext partizipierender technischer sowie orgisatorischer Systeme resp. Prozesse zur Disposition, jedoch kapriziert sich der hier auf- und ausgeführte spezielle Ausschnitt auf den jeweiligen Aufgabenkomplex im Rahmen des KoOP-Projektes; d.h. alle Systeme und Prozesse außerhalb dieses Blickwinkels werden hier nicht weiter betrachtet. Des Weiteren wurde in dieser Ausbaustufe des Pilotsystems hauptsächlich auf den Personenkreis der Studierenden abgestellt, um die Komplexität in dieser Phase des Gesamtvorhabens so gering wie möglich zu halten und um sich somit intensiver auf die grundlegenden Abläufe und Aufgaben, wie z. B. Konsolidierung digitaler Identitäten, konzentrieren zu können. III IM-System KoOP Das IM-System KoOP nutzt für die Erfüllung seiner Aufgaben 2 Verzeichnisse, in denen im nicht konsolidierten Verzeichnis alle digitalen Identitäten, inklusive aller Duplikate, von Studierenden und im konsolidierten Verzeichnis nur jeweils eine eineindeutige digitale Identität 25 Die Verwendung von Piktogrammen in Form von Rechnersymbolen, die Systeme resp. Komponenten derer repräsentieren, impliziert nicht, dass hier in realiter jeweils ein Rechner zum Einsatz kommt; vielmehr sollen diese Symbole abstrakte systemorientierte Einheiten verschaulichen, deren Funktionen, d.h. Abläufe und SW-Komponenten bei der konkreten Umsetzung auf einen, mehreren oder mehrere auf einem Rechner loziert sein können. Std: Seite 64 von 82

65 von Studierenden enthalten sind. D.h. wurde z. B. ein Studierender sowohl HAW wie auch der UHH in den jeweiligen Verwaltungssystemen (STiNE/HIS) erfasst, existieren nach Übernahme in das IM-System KoOP zumindest zwei digitale Identitäten resp. Datensätze im nicht konsolidiertem jedoch nur einer im konsolidierten Verzeichnis; der jeweilige Informationsgehalt aus beiden Datensätzen wurde in einem zusammengefasst. Aus den jeweiligen Verwaltungssystemen für Studierende nimmt das IM-System KoOP Aufträge entgegen, um Datensätze im nicht konsolidierten Verzeichnis zulegen, zu modifizieren und zu löschen. Interne Prozesse sorgen dn für die entsprechenden Aktionen i. S. d. Eindeutigkeit im konsolidierten Verzeichnis und stellen die konsolidierten Datensätze dem hochschulübergreifenden Corporate Directory zur Disposition. III Hochschulübergreifendes Corporate Directory Das hochschulübergreifende Corporate Directory ist mit dem IM-System KoOP über einen sog. Konnektor verbunden und dient hier ausschließlich als Authentifizierungsinstz, die entsprechende Anfragen von Internetservices und elearning-plattformen über LDAP (Lightweight Directory Access Protocol) gestellt werden. So erhält z. B. ein Studierender einer beliebigen Hochschule Hamburgs, der den WLAN-Service nutzen möchte, die Zugriffsfreigabe nicht direkt vom RADIUS 26 -Server, sondern er authentisiert sich mit Hilfe eines Berechtigungsnachweis in Form von Kennung und Passwort mittelbar am Corporate Directory, da die 26 Das Remote Authentication Dial-In User Service (RADIUS) ist ein Client-Server-Protokoll, das zur Authentifizierung, Autorisierung und zum Accounting (Triple-A-System) von Benutzern bei Einwahlverbindungen in ein Computernetzwerk dient. RADIUS ist der de-facto-stdard bei der zentralen Authentifizierung von Einwahlverbindungen über Modem, ISDN, VPN, WLAN (IEEE 802.1x) und DSL.(s. ) Std: Seite 65 von 82

66 Authentifizierung hier eben nicht vom RADIUS durchgeführt, sondern der Berechtigungsnachweis ohne Prüfung das Corporate Directory zur Identitätsprüfung weitergeleitet wird. Die Anzahl der hinterlegten Objekte ist identisch mit der des IM-System KoOP, sie unterschieden sich aber in der Größe ihrer Attributrahmen, der hier geringer ausfällt. Auch sind die Attributnamen und ggf. ihr Wertebereich nicht immer identisch, sodass sie in diesen Fällen bei Übernahme von Werten aus dem IM-System KoOP diese Werte in dere Attribute mittels semtisches Mapping im Konnektor sinngemäß projiziert werden. Der Umfg der im Corporate Directory gespeicherten Attribute reicht aus, um Adressebücher von z. B. Outlook und Thunderbird mit entsprechenden Daten zu befüllen. III.1.9 Ähnlichkeitsprüfung digitaler Personenidentitäten (SimSpector) Eine einfache Prüfung einzelner identifizierender Attribute auf Identität reicht bei weitem nicht aus, um ungewollte Dubletten aufdecken zu können. Denn z. B. unterschiedliche Schreibweisen, wie auch Schreibfehler usw. führen dazu, dass eine Identität der Attribute nicht gegeben ist und somit Dubletten nicht erknt werden können. Eine zunehmende Internationalisierung führt dazu, dass sprachabhängige Verfahren, wie z. B. das Soundex-Verfahren 27, hier mehr oder weniger versagen werden, auch der Rückgriff auf sog. Domainwissen wird seine Grenzen finden. Ein weiteres Problem liegt in der Performz, riesige Datenmengen zeitnah miteinder vergleichen und ggf. zusätzliche Informationen über diese Datenmengen speichern zu müssen, sodass z. B. die Verwendung eines Levenshtein-Distce- Algorithmus 28 nicht immer als adäquateste Wahl erscheint. Mit Verwendung des sog. Jaccard-Index 29 als Ähnlichkeitsmaß, der die Schnittmenge zweier Mengen in Verhältnis zu ihrer Vereinigungsmenge setzt, ergab sich in Verbindung mit Bloomfiltern 30 die nachzuweisende Forderung, dass je wahrscheinlicher die Gleichheit zweier Bloomfilter, desto ähnlicher die beiden Wertemengen W i, W j relevter Identitätenattribute sind, über die die jeweiligen Filter als binäres Abbild derer berechnet wurden. prob M 11 [ sig ( W ) = sig ( W )] = sim ( W, W ) Bloom i Bloom j M 01 + M 10 + M 11 Jaccard i j = W W i W W i j j Die jeweiligen Mengen M repräsentieren eine bestimmte Anzahl gesetzter Bits in den involvierten Bloomfiltern und sind wie folgt zu interpretieren: M 11 : Gesamtzahl in beiden Filtern identischen Positionen gesetzter Bits 27 Soundex ist ein phonetischer Algorithmus zur Indizierung von Wörtern und Phrasen nach ihrem Klg in der englischen Sprache. Gleichklingende Wörter sollen dabei zu einer identischen Zeichenfolge kodiert werden. (vgl. ) 28 Stringvergleichender Algorithmus, der die Differenz zweier Zeichenketten über eine Kostenfunktion ermittelt (vgl. oder 29 Der Jaccard-Index, auch beknt als Jaccard-Ähnlichkeitskoeffizient, ist eine mengentheoretische, auf Stichproben basierende Statistik, die für Ähnlichkeits- und (biologische) Diversivitätsvergleiche genutzt werden kn (vgl. ) 30 Std: Seite 66 von 82

67 M 10 : Gesamtzahl gesetzter Bits Positionen im ersten Filter, denen im zweiten keine gesetzt sind M 01 : Gesamtzahl gesetzter Bits Positionen im zweiten Filter, denen im ersten keine gesetzt sind M 00 : Gesamtzahl in beiden Filtern identischen Positionen ungesetzter Bits (hier irrelevt) Dieser hier im Projekt alytisch evaluierte und in konstruierten Testszenarien mit Hilfe des hierfür entwickelten Programms SimSpector untermauerte Lösungssatz scheint neben vielen deren ein ggbarer Weg zu sein, die verwendeten Identitätenrepositories zu konsolidieren resp. konsolidiert zu halten. III Merkmalseigenschaften und -kdidaten Nicht immer reichen einzelne Identifizierungsmerkmale, die eine Person resp. Identität beschreiben, in Qutität und Qualität aus, um in einem Identitätenrepository diese mit einer hohen Wahrscheinlichkeit (wieder)erkennen oder mit einer bestimmten Wahrscheinlichkeit ausschließen zu können, dass eine vermeintlich erknte Identität, nicht die ist, für die sie gehalten wurde. Dies gilt insbesondere, wenn einer Identität noch kein eineindeutiger Identifikator als Surrogat zugewiesen wurde. D.h. dass bei Fehlen eines solchen Identifikators ein deres Merkmal oder eine geschickte hd von Domänenwissen konstruierte, ggf. auf Aussagenlogik basierte Kombination aus mehreren, eine Identität beschreibenden Merkmalen die Stelle eben dieses Identifikators treten muss. Um beim Durchsuchen des Identitätenrepository die endgültige Trefferquote, d.h. die Ergebnismenge ähnlicher und/oder identischer Datensätze gering zu halten, ist es notwendig, sich auf mehrere Merkmale einer Person abstützen zu können. Hierdurch lässt sich die Wahrscheinlichkeit, dass viele Datensätze der Abfragebedingung genügen, enorm reduzieren. So lässt sich schon hd des sog. Geburtstagsparadoxon festmachen, dass allein der Geburtstag für eine effektive Identifizierung nicht ausreicht, da schon bei einer Repositorygröße von 50 erfassten Personen die Wahrscheinlichkeit über 97% beträgt, dass zwei dieser Personen am selben Tag Geburtstag haben (Anm.: der Jahrgg wurde hier nicht berücksichtig). Die Eigenschaften der identifizierenden Merkmale müssen bestimmten Kriterien gehorchen, damit sie eine hinreichende Aussagekraft allein oder in Kombination mir deren über die zu identifizierende Person besitzen. So eignen sich Merkmale, die zu einer hohen Änderungsrate neigen, eher weniger, als solche deren Ausprägung (Attributwert) dem Individuum ein Leben lg haften bleiben 31. Gleichzeitig muss eine ausreichende Menge 32 prägnten Merkmalen vorhden sein, um durch Kombination eine Quasi-Eindeutigkeit erreichen und damit die für eine extensivere Prüfung disponierte Ergebnismenge einer Abfrage sehr klein halten zu können. Des Weiteren sind Merkmale, die aufgrund einer kleinen Wertemenge einen geringen Differenzierungsgrad aufweisen, wie z. B. die zweiwertige Gender-Ausprägung, wenig hilfreich, 31 Das Alter einer Person z. B. ändert sich jedes Jahr, dass Geburtsdatum aber nicht. 32 Es ist nicht immer sinnvoll, Eigenschaften eines Individuums, die m ihm beobachten, benennen und beschreiben kn, wie z. B. Augenfarbe, Größe etc. vollständig in einem Identitätenrepository abzuspeichern. Auch wird es aus datenschutzrechtlichen oder deren normativen Gründen nicht immer möglich sein, geeignete Merkmale, wie z. B. Nationalität, ins Repository aufnehmen zu können. Std: Seite 67 von 82

68 da sie die Gesamtmenge Identitäten in wenige, qutitativ große, aber qualitativ wenig prägnt beschreibende Untermengen teilen. Ein solches Merkmal könnte höchstenfalls, nach Ausschöpfung aller deren Modalitäten, als ergänzendes Kriterium für die Identifizierung resp. Ähnlichkeitsmessung hergezogen werden. Für die Ermittlung, welche Merkmale, die eine Person hinreichend beschreiben, um sie für den hier vorliegenden Zweck der Identifizierung in einem Repository zu verwalten, hergezogen werden können, diene hier, in Analogie zur Feststellung einer Person, der Personalausweis, in dem u. a. folgende Grundinformationen aufgeführt sind: Vor- und Nachname Geburtstag und ort Adresse Bei näherer Betrachtung ist zu konstatieren, dass die Attribute Vorname, Geburtstag und Geburtsort bessere Identifizierungseigenschaften aufweisen, da sie der natürlichen Person lebenslänglich haften 33. Das Attribut Nachname, dessen Inhalt z. B. durch Heirat sich ändern kn, käme eher in Kombination mit den eben gennten Attributen als Zusatzinformation in Frage; ähnliches gilt für das Attribut Adresse. Genügen z. B. die Attribute Vorname, Geburtstag und Geburtsort aufgrund fehlender Datenqualität und bestimmten, rigorosen Prüfbedingungen allein nicht, um in die Ergebnismenge ähnlicher Datensätze aufgenommen zu werden, obwohl sie eigentlich Kdidaten hierfür gewesen wären, so lässt sich mit Hilfe des Attributes Nachname 34 dafür Sorge tragen, diese Kdidaten trotzdem der Ergebnismenge zuzuschlagen. Gleichfalls lässt sich aber hd von Zusatzinformationen die Trefferquote reduzieren, um die Ergebnismenge für die weitere Behdlung entsprechend einschränken zu können. III Schreibweisennormalisierung und Alphabet Um dem Problem unterschiedlicher Schreibeweisen von Namen (Personen-, Orts- und Straßennamen sowie Orgisations-, Funktionsbezeichnungen usw.) in Attributen, gerade in Bezug auf die Verwendung von Akzenten 35, vorzubeugen und des Weiteren das Alphabet in seiner Mächtigkeit (Kardinalität) überschaubar zu gestalten, werden alle diakritischen Zeichen eliminiert und die verbleibenden Grundkörper der Buchstaben entweder durchgehend in Majuskel- oder in der hier präferierten Minuskelform verwendet. Bei Umlauten und Zusammentreffen von Umlauten und Tremata, da syntaktisch nicht unterscheidbar, wird bei ihrer Existenz in Namen resp. Zeichenketten hinter dem entsprechenden, um das Diakritikum bereinigten Buchstaben jeweils ein e eingefügt; ein ß z. B. wird durch die Zeichenfolge ss ersetzt 36. Attribute mit Zahlengaben, insbesondere Datum, Uhrzeit, Telefonnummer usw., sollten jeweils in ein vorab definiertes einheitliches Format gebracht werden; d.h. sie bestehen nur noch aus Zahlen, wobei die Semtik zwar teilw. verloren gehen, jedoch aufgrund der Kenntnis der spezifischen wohlkonstruierten Formatsyntax ggf. über (Teil-)Längen und An- 33 Die Änderungsmöglichkeit von Vornamen gem. Namenänderungsrecht möge hier aufgrund der Anwendungshäufigkeit keine Rolle spielen. 34 Voraussetzung ist natürlich, dass der Nachname sich in der Zwischenzeit nicht geändert hat. 35 z. B. Betonungszeichen wie Akut (Áá), Gravis (Àà), Trema (Ää), Cedille (Çç), nordischer Akzent (Åå), Tilde (Ññ, Õõ), Zirkumflex (Ââ) usw. 36 Weitere mögliche Trsliterationen z. B. aus dem Zeichensatz ISO sind vorstellbar: Æ A, æ A, ª a, Ð Dh, ð dh, º o, Þ Th, þ th etc. aber auch ggf. Mª Maria Std: Seite 68 von 82

69 fgspositionen reproduziert werden könnte 37. Diese Formatunifizierung unterstützt so i. V. m. der Kenntnis über den Attributtyp und dessen Wertemenge die Plausibilitätsprüfung 38 auf eine einfache Art und Weise. Die Behdlung verkürzender Schreibweisen, wie z. B. im Deutschen str. für straße oder im Spischen c/ oder C/ für Calle, setzt bestimmtes Domainwissen voraus, um sie z. B. durch Vervollständigung in eine normalisierte Form bringen zu wollen. Alle Zeichen, die i. e. S. keine Buchstaben und/oder Ziffern sind 39, werden nicht berücksichtigt und für die spätere Weiterverarbeitung aus der Zeichenkette gelöscht oder ggf. durch ein Füllzeichen ersetzt. Die hier betrachteten Zeichenketten setzen sich nun aus einem konstruierten Alphabet zusammen, das hierfür einen Zeichenvorrat von 36 Symbolen umfasst. Das Alphabet wird noch um ein Hilfszeichen hier sei es der Unterstrich _ für die Zerlegung der Zeichenketten in n-gramme ergänzt. III n-gramm-zerlegung Die Zerlegung von Datensätzen resp. deren Attribute in sog. n-gramme 40 ermöglicht, diese Attribute, interpretiert als Menge von Zeichenketten über ein bestimmtes Alphabet, durch Vektoren definieren und mathematische Verfahren auf diese wenden zu können. Die intuitive Idee dieser Zerlegungsart liegt zugrunde, dass je mehr sich zwei Zeichenketten ähneln, desto größer die Anzahl ihrer gemeinsamen n-gramme ist. Ausgedrückt werden, kn dieses Verhalten z. B. über ein Ähnlichkeitsmaß, das die Schnittmenge zweier n- Grammengen, die durch die Zerlegung zweier Zeichenketten entstden sind, ins Verhältnis zur ihrer Vereinigungsmenge gesetzt wird. Nach Zerlegung entstehen Textfragmente (n-gramme), wobei n (n > 1) der Länge der sich um n-1 Zeichen überlappenden Teilzeichenketten entspricht. Um eine Benachteiligung aufgrund der Unterrepräsentz des ersten und letzten Symbols einer Zeichenkette in der Gesamtheit der aus ihr generierten n-grammmenge ausschließen und Zeichenketten aus einem Zeichen nach gleichem Schema zerlegen zu können, wurde vorher das Alphabet um ein Hilfszeichen ergänzt. Bildlich gesehen wird ein Fenster mit n Facetten sukzessive beginnend mit dem ersten Zeichen unter dem rechten Fensterrd (n-te Facette) Zeichen für Zeichen über die aktuelle Zeichenkette geschoben und die jeweils erscheinenden n Symbole ergebenen die korrelierenden n-gramme; in Facetten, in denen kein Zeichen der Zeichenkette erscheint, erscheint das Zeichen _. Aus einer Zeichenkette mit m Zeichen werden so (m+n-1) n-gramme generiert, wobei die ersten und letzten n-gramme am Anfg resp. Ende jeweils eine bestimmte Anzahl des Hilfszeichens aufweisen Mai 1964 als ein mögliches Geburtsdatum ergäbe mit dem vorgegebenen Format JJJJMMTT die Ziffernfolge oder eine Telefonnummer 040/ würde mit stdardisiert. 38 Es ließe sich relative einfach erkennen, dass der Position der Tagesgabe innerhalb eine Datums z. B. ein Wert von 32 nicht sein kn und es sich hier womöglich um einen sog. Zahlendreher hdele. 39 z. B. Leerzeichen, Bindestrich, Schrägstrich, Apostroph, Interpunktionen usw. 40 n=1: Unigramm (nicht sinnvoll); n=2: Bi- oder Digramm; n=3: Trigramm; n=4: Tetra- oder Quad(ri)gramm usw. Std: Seite 69 von 82

70 Ein n-gramm beschreibt also eine bestimmte Wahrscheinlichkeit, mit der ein Zeichen in einer Zeichenkette auf n-1 vorhergehenden folgt, gleichzeitig entsteht durch die Überlappung eine Abhängigkeit der aus einer Zeichenkette entstdenen n-gramme zueinder. Die Vorteile dieser Art von Zerlegung sind: Robustheit: gewisse Tolerz gegenüber Schreibfehlern (z. B. Buchstabendrehern) und deren morphologischen Variationen, da sich der Fehler nur lokal, d.h. auf eine kleine Anzahl von Textfragmenten auswirkt, während der Rest davon unberührt bleibt Abgeschlossenheit: Vokabular besteht aus einer geordneten Menge von n-grammen mit einer wohldefinierten, einfach bestimmbaren Größe 41 (Kardinalität) Domänenunabhängigkeit: Sprach- und Themenneutralität Wirtschaftlichkeit: nur ein Verarbeitungsdurchgg Einfachheit: keine linguistischen Kenntnisse erforderlich (z.. B. Stammformreduktion, Silbenzerlegung); alle Wörter habe identische Länge Diese Art der Zerlegung in sinnneutrale Einheiten und der Vergleich dieser Einheiten, ist besonders gut geeignet, Ähnlichkeiten von Eigennamen zu überprüfen. Ein Nachteil ist vielleicht, dass in Bezug auf das menschliche Wahrnehmungsvermögen sich eine Ähnlichkeit nicht immer intuitiv sofort erschließt. Für die hier betrachtete Anwendungspraxis scheint die Wahl von n-grammen mit n = 2 (Digramme) und n = 3 (Trigramme) gemessen. Für kleine Zeichenketten kommen eher Digramme infrage, da sie noch ausreichende syntaktische Informationen liefern und im Gegensatz zu Trigrammen die semtische Aussagekraft erhalten bleibt. Für große Zeichenketten jedoch führen Digramme ggf. zu einer überproportionalen Ähnlichkeit, da ihre Auftrittswahrscheinlichkeit steigt; eine Verwendung von Trigrammen scheint aufgrund der größeren Überdeckungen somit sinnvoller. n-gramme n > 3 führen zu einer exponentiell wachsenden Anzahl von n-grammen bei gleichzeitig sinkender Auftrittswahrscheinlichkeit und sind hier wohl eher theoretischer Natur. Beispiel: e r i k a 5 Zeichen e 1. Trigramm _ e r 2. Trigramm e r i 3. Trigramm r i k 4. Trigramm i k a 5. Trigramm k a _ 6. Trigramm a 7. Trigramm 41 Für Bigramme ergäbe sich hier ein Vokabular von (37 2 ), für Trigramme eines von (37 3 ) und für Tetragramme eines von (37 4 ) möglicher Alphabetkombinationen. Std: Seite 70 von 82

71 Um n-gramme für die weitere rechnergestützte Verarbeitung effizienter gestalten zu können, reicht für die hiesigen Zwecke eine äquivalente bijektive Zahlendarstellung aus, sodass für alle möglichen paarweise verschiedenen n-gramme jeweils genau eine Zahl, dem Index, aus dem vom Alphabet aufgespnte Intervall existiert. III Bloomfilter Bloomfilter, auch in ihrer kombinierten Form, sind spezielle Signaturausprägungen 42, die in vielen Bereichen der Informations- und Kommunikationstechnik (Netzwerke, Datenbken usw.) für effiziente Vergleiche hergezogen werden können. Ein (Stdard-)Bloomfilter ist eine einfache Platz sparende Datenstruktur (Bit-Array), mithilfe derer die Mitgliedschaft in einer bestimmten Menge, d.h. das Vorhdensein einer Identität im Identitätenrepository getestet werden kn. Die effiziente Verwendung von Speicherplatz jedoch geht zu Lasten, nicht exakt die Mitgliedschaft feststellen zu können; d.h. dass mit einer bestimmten, jedoch gestaltbar kleinen Wahrscheinlichkeit sog. False-Positives (eine Form der sog. False-Drops) auftauchen, also fälschlicherweise eine Mitgliedschaft nachgewiesen wird. Auf jeden Fall treten bei der hier verwendeten Bloomfilterart sog. False- Negatives, eine wirkliche Mitgliedschaft wird nicht erknt, nicht auf. Ein eine bestimmte Anzahl von n-grammen resp. deren jeweiliger Index repräsentierender Bloomfilter wird durch eine initial auf Null gesetzte Anzahl von Bits, die der Länge des Filters entspricht, beschrieben, in der für jedes dem Filter hinzugefügter Index bestimmte Bits, mittels einer bestimmten Anzahl universeller und unabhängiger Hash-Funktionen berechnet, auf Eins gesetzt werden. Trigramm idx hash 1 hash 2 B[0] B[1] B[2] B[3] B[4] B[5] B[6] e _er eri rik ka_ ika a Bloomfilter abc mno Gegeben sei als Beispiel 43 ein Bloomfilter der Länge 7 und eine Anzahl von 2 Hash- Funktionen mit 42 Diese Art Signatur sei hier grundsätzlich als ein weiteres Identifizierungsmerkmal einer Identität verstden, die über eine bestimmte Attributmenge gebildet, eben diese Menge für bestimmte Zwecke hinreichend beschreibt. Std: Seite 71 von 82

72 hash = Index mod 7 hash 1 2 = Index mod Das Wort resp. Trigramm abc würde fälschlicherweise als Element des gebildeten Bloomfilters in o. a. Tabelle gewertet werden, das Wort mno jedoch korrekterweise nicht. Die False-Positive-Rate ε, d.h. die einem Bloomfilter aufgrund der Bitkollisionen immente Wahrscheinlichkeit, dass ein beliebiges Wort fälschlich als Element einer Wortmenge gesehen wird, wird über die Parameter für die Anzahl der verwendeten Hash-Funktionen k und dem Verhältnis aus Bloomfilterlänge m und Anzahl der aufzunehmenden Wörter n bestimmt: m m k n k 0,6931 = 2 = 0, 6185 n und So ergibt sich z. B. für eine Verhältnis von Bloomfilterlänge und aufzunehmender Wörter von 10 und einer Anzahl von 7 Hash-Funktionen, eine False-Positive-Rate von ca. 0,8 %, die in praxi dn nicht mehr ins Gewicht fällt. III Ähnlichkeitsbestimmung Eine digitale Identität wird im Identitätenrepository über eine bestimmte Attributmenge (Attributrahmen) repräsentiert, die diese Identität hinreichend beschreiben und mehr oder weniger zum Identifizierungsprozess und damit zur Ähnlichkeitsbestimmung beitragen können. Diejenigen mit einer bestimmten Relevz versehenen Attribute, d.h. die resultierende Menge entsprechender in Bloomfilter umgewdelten Zeichenketten, die für die Ähnlichkeitsbestimmung hergezogen werden, bilden hier das Identitätsprofil einer digitalen Identität. Die Ähnlichkeitsbestimmung zweier Bloomfilter erfolgt durch das ins Verhältnis setzen von der Gesamtzahl in beiden Filtern identischen Positionen gesetzter Bits zu der Gesamtzahl gesetzter Bits Positionen im ersten Filter, denen im zweiten keine gesetzt sind, und der Gesamtzahl gesetzter Bits Positionen im zweiten Filter, denen im ersten keine gesetzt sind. Der resultierende Wert entspricht der Ähnlichkeit zweier Filter. Je nach Relevz der Attribute besitzen die jeweiligen Bloomfilter für die Ähnlichkeitsbestimmung innerhalb der Profile untereinder unterschiedliche Wichtigkeiten. Haben verschiedene Attributtypen in ihrer Aussagekraft mehr oder weniger identische Wichtigkeit zur Gesamtmenge, so lassen sich die resultierenden Bloomfilter durch sog. Superimposed Coding überlagern und somit verschmelzen. Dies führt zu einer Reduktion der zu vergleichenden Filtern mit dem Nachteil, dass die False-Positive-Rate mit jedem Filter rein rechnerisch wächst 44. Voraussetzung für diese Art der Zusammenführung ist jedoch, dass die entsprechenden Filter in ihrer Konstruktion gleichlg sind und dieselbe Anzahl maximal aufnehmbarer Wörter sowie dieselbe False-Positve-Rate aufweisen. Die Summe der einzelnen gewichteten Ähnlichkeiten korrespondierender Bloomfilter und damit die Ähnlichkeit zweier Profile ergibt im Endergebnis die semtische Ähnlichkeit zweier digitaler Identitäten über ihre relevten Attributmengen als Repräsentten. ε 43 Dieses Beispiel ist unrealistisch und dient ausschließlich der Verschaulichung. fpr ε o o... o 1 ε 2 ε k = 0, k n ( ) m Std: Seite 72 von 82

73 III Digitale Identitäten inspizieren Das Programm SimSpector, das dem Erkennen und Extrahieren sog. Dubiosen gemeint sind digitale Identitäten, bei denen eine Gruppenzuordnung zu neuen oder schon bestehenden Identitäten im Repository nicht möglich scheint dient, ist so konzipiert, das der Ablauf über eine Konfigurationsdatei mit Hilfe von Jobs, in denen Aufgaben (Tasks) mit ihren spezifischen Ausprägungen zusammengefasst werden, variable gestaltet und gesteuert werden kn. Ein Job setzt sich aus den folgenden drei beliebig kombinierbaren Tasks zusammen, wobei bestimmte Task mehrfach, ggf. mit unterschiedlicher Ausprägung, vorkommen oder gänzlich weggelassen werden können: Trsformation Inspektion Extraktion Die Task Trsformation selegiert die für die Signaturbildung (Bloomfilter) geforderten Attribute aus einer im wohldefinierten Format bereitgestellten, mit digitalen Identitäten gefüllten Datei 45, führt die Schreibweisennormalisierung und n-gramm-zerlegung durch, um dn die aus den Attributen resultierenden Zeichenketten in ggf. kombinierte Bloomfilter mit vorgegebener, vom Anwender definierter Parameter, wie False-Positive-Rate, Filterlänge, Anzahl der Hashfunktionen und maximal aufnehmbarer n-gramme, zu überführen und in eine entsprechende Profil-Datei abzulegen. Während der Inspektion wird eine Profil-Datei gegen eine dere zweite abgeglichen. D.h. dass jedes Profil der ersten gegen jedes Profil der zweiten Datei mit Hilfe der jeweiligen Filter und vordefinierten Wichtungen sowie Schwellwerten dahingehend geprüft wird, ob die zwei Profile einen solchen Ähnlichkeitsgrad aufweisen, der es nicht ermöglicht, mit einer Sicherheit grenzender Wahrscheinlichkeit vorliegende semtische Identität resp. Non-Identität feststellen zu können; tritt dieser Sachverhalt bei einem Profil der ersten Datei mindestens einmal auf, so wird dieses als dubios eingestuft. Als Resultat liegt nach einem Inspektionsvorgg eine disjunkte Aufteilung der geprüften Profile der ersten Datei in sog. Dubiose und sog. Eindeutige auf zwei verschiedenen Dateien vor. Die beiden über den Vorgg der Inspektion generierten Dateien werden beim Extrahieren genutzt, um aus der korrelierenden, für die Trsformation bereitgestellten Datei digitaler Identitäten eindeutige von dubiosen Identitäten für eine weitere, hier nicht betrachtete Bearbeitung zu trennen und in entsprechenden Dateien abzulegen. Die nachfolgende Grafik zeigt einen typischen Ablauf, in dem zwei Jobs miteinder verknüpft sind. Während der eine Job, bestehend einer einzigen Trsformation, für den Aufbau eine Identitätsprofil-Datenbk zuständig ist, in der alle schon erfassten und konsolidierten digitalen Identitäten als Profile hinterlegt sind, befasst sich der dere, bestehend aus der Taskfolge Trsformation-Inspektion-Inspektion-Extraktion, mit der eigentlichen Ähnlichkeitsbestimmung digitaler Identitäten resp. digitalen Aspirten, die entweder im Identitätenrepository registriert werden oder dort für bei bestehenden Identitäten für Modifikationen sorgen sollen. 45 Es hdelt sich hier um eine sog. CSV-Datei (CSV = Comma/Character Separated Values). Std: Seite 73 von 82

74 Nach dem die gewünschten Attribute der digitalen Aspiraten in Identitätsprofile trsformiert wurden, werden diese gegen sich selbst inspiziert, d.h. die Datei der Identitätenprofile erfährt eine Doppelnutzung, indem jedes Profil mit allen Profilen dieser Datei verglichen wird. Diese erste Inspektion erfolgt, um hier im Vorwege schon mögliche Dubiose für die weitere Verarbeitung zu auszusondern. In einer weiteren Inspektion werden die aus der ersten resultierenden, eindeutigen Profile gegen die der Identitätsdatenbk abgeglichen und als Ergebnis sowohl eindeutige wie auch dubiose Profile erzeugt, die wiederum nach dem Extraktionsvorgg für dubiose resp. eindeutige digitale Aspirten sorgen. III.1.10 Intermediäres System zur Kopplung von E-Learning-Plattformen (GOLEM) III Systemumgebung Der GOLEM-Server besteht aus externer Sicht aus einer aktiven Komponente und einer Repository-Komponente, welche zur Konsolidierung der vermittelten Daten dient. Die aktive Komponente nimmt über HTTP /HTTPS Datenströme nach dem IMS-Stdard entgegen, verarbeitet die enthaltenen Informationen und leitet sie nach Maßgabe der im Paket-Header enthaltenen Routinginformationen die Zielsysteme weiter. Im Repository werden hierbei bestimmte Daten persistent gespeichert (Personendaten, Gruppen- und Membership- Informationen). Über generische IMS-Backendkonnektor lassen sich mehrere GOLEM-Server koppeln dies kn notwendig sein, um Richtlinien des Datenschutzes zu befolgen oder bestimmte Datensätze lokal vorverarbeiten zu können. Prinzipiell bilden die Backendkonnektoren die (generische) Logik des GOLEM-Servers auf die spezifische Logik der Anwendungssysteme ab. Std: Seite 74 von 82

75 Die Kommunikation erfolgt über IMS Pakete und IMS basierte Nachrichten. Der aktuell referenzierte Stdard kn hierbei vom GOLEM-Server selbst abgefragt werden (in Form einer XML DTD), Paketmuster (Templates) und Variablen-Zugriffspfade werden ebenfalls vom GOLEM-Server bezogen (vgl. Anhg). Der GOLEM arbeitet inhärent datengesteuert, d.h. auf der Grundlage weitgehend generischer Algorithmen werden individuelle Datenpakete und Variablen über ihren Kontext verarbeitet. Die Steuerung des Kontextes erfolgt XML-musterbasiert. Das primäre Datenmodell zur Übermittlung von Personen-, Gruppen und Membershipinformationen folgt dem IMS Enterprise Schema 46. IMS ist ein das IMS Global Learning Consortium, III Server Die Architektur des GOLEM-Servers folgt dem klassischen 3-Schichten Modell in Abwdlung des Model-View-Controller-Paradigmas (MVC). Die nachfolgende Abbildung stellt die Schichten des GOLEM-Servers dar: eine Kommunikationsschicht übernimmt den Datenaustausch mit den Clients. Dies kn die Übermittlung von IMS Paketen beinhalten (nach Durchlaufen einer Prüfung auf 46 Std: Seite 75 von 82

76 Authentifizierung per Paßwort und auf Authorisierung nach Zuordnung zu einer Institution), aber auch die Abgabe von Modellinformationen (Institutionen, Paketmuster, etc.). Da der GOLEM-Server auf Basis eines Web-Servletcontainers implementiert wurde, werden HTTP/HTTPS-Verbindungsfragen entgegen genommen, die dem gängigen URL-Schema entsprechen. Die Kommunikationsschicht steht in Verbindung mit der Logikschicht, welche die Verarbeitung der Eingabe übernimmt. Die Logikschicht besitzt eine Statische Einheit, welche Modellinformationen nach außen weitergibt, die entweder im Repository oder in der Verarbeitungslogik selbst statisch gespeichert sind. Die Daten des Repository sind zwar nicht im strengen Sinne statisch, sie werden jedoch in der Regel äußerst selten verändert und werden derzeit zum Zeitpunkt des Serverstarts eingelesen und sind dach zur Laufzeit zwar modifizierbar, die Änderungen werden aber erst nach Neustart des Servers sichtbar. Analyseeinheit, die zur Verarbeitung von IMS Paketen dient. Diese Einheit prüft die eingehenden Daten auf Konsistenz und darauf, ob sie bereits im Repository enthalten sind. Nach Durchlauf dieser Prüfungen wird das IMS Paket die Konnektoren der im Paket- Header definierten Empfängersysteme weitergeleitet. Std: Seite 76 von 82

77 Eine Backend-Schicht leitet die Daten dn die eigentlichen Zielsysteme weiter. Hierzu sind die Kommunikationsbedürfnisse der Zielsysteme im jeweiligen Konnektor implementiert, außerdem gibt es eine Reihe vergleichsweise generischer Konnektoren. speichert Daten, die zur Außeninformation (z.b. Liste verfügbarer Gruppen oder Institutionen) oder zur Konsistenzprüfung notwendig sind (z.b. Personendaten). III Client Adapter Derzeit wurden 2 Frontend-Adapter entwickelt, die dazu dienen, Daten aus einer Datenquelle einzulesen, in IMS Pakete umzuformen und zu einem GOLEM-Server zu schicken. Prinzipiell werden Daten aus einer externen Datenquelle (in der Abbildung: eine SQL- Datenbk, es sind aber ebenso LDAP-Verzeichnisse, sowie CSV- und LDIF Dateien als Datenquellen sprechbar) ausgelesen und in eine zeitliche oder kausale sequentielle Struktur gebracht. Die aus der Datenquelle erhaltenen Einträge werden dn unter Verwendung der vom GO- LEMServer bezogenen Strukturinformation (Paketmuster und Variablen/Pfadzuordnung, werden beim Adapterstart initial über das Netz vom GOLEM-Server geladen) in IMS konforme Records trsformiert. Die einzelnen Records werden in ein Paket zusammengefaßt und zum konfigurierten GOLEM-Server verschickt. Dieser Vorgg wiederholt sich periodisch in einem zu konfigurierenden Intervall. Std: Seite 77 von 82