T A G U N G S B A N D. Paul Molitor et al. (Hrsg.)

Transkript

1 Paul Molitor et al. (Hrsg.) Abschlussworkshop zu den EFRE-Projekten der Maßnahme 11.03/41.03 Förderung des Einsatzes neuer Technologien im Wissenschaftsbereich und zur Schaffung von Informations- und Wissensmanagementsystemen T A G U N G S B A N D Januar 2012

2 II Paul Molitor et al. (Hrsg.) Tagungsband des Abschlussworkshops zu den EFRE-Projekten der Maßnahme 11.03/41.03 Förderung des Einsatzes neuer Technologien im Wissenschaftsbereich und zur Schaffung von Informations- und Wissensmanagementsystemen Im Auftrag des Ministeriums für Wissenschaft und Wirtschaft des Landes Sachsen-Anhalt herausgegeben durch die Mitglieder der Landes-Hochschul-DV- Kommission (LDVK) des Landes Nike Bätzner, Burg Giebichenstein Kunsthochschule Halle Johannes Bernarding, Otto-von-Guericke-Universität Magdeburg Peter Burghardt, Sprecher der Gruppe der Hochschulrechenzentrumsleiter Johannes Haerting, Martin-Luther-Universität Halle-Wittenberg Uwe Heuert, Hochschule Merseburg Einar Kretzler, Hochschule Anhalt Bernd Michaelis, Otto-von-Guericke-Universität Magdeburg Paul Molitor (Vorsitzender), Martin-Luther-Universität Halle-Wittenberg Matthias Morfeld, Hochschule Magdeburg-Stendal Hermann Strack, Hochschule Harz Reinhardt Worch, Universitäts- und Landesbibliothek Sachsen-Anhalt

3 III Vorwort Ziel der EFRE Maßnahme 11.03/41.03 des Landes Sachsen-Anhalt war laut dem entsprechenden Erlass vom eine höhere Wirksamkeit neuer Technologien für die Prozesse an den Hochschulen des Landes. Insbesondere waren Entwicklungen des Informations- und Wissensmanagement anzustreben im Hinblick auf a) die Aussagefähigkeit und Nutzerfreundlichkeit von Informationsmanagementsystemen sowie den Aufwand für die Bereitstellung von Informationen; b) die Verlässlichkeit der Systeme, Vertraulichkeit und Integrität der Daten; c) die Personalisierung von Informationen und Verfahren für einen plattformunabhängigen Zugriff. Von 18 eingereichten Projektskizzen wurden im Rahmen eines unter der Federführung der Landes-Hochschul-DV-Kommission (LDVK) des Landes Sachsen-Anhalt unter Einbeziehung externer Gutachter deren acht zur Förderung empfohlen, von denen entsprechend der Verfügbarkeit von Fördermittel sieben gefördert werden konnten. Die durch die Projekte erzielten Ergebnisse wurden im Rahmen eines Workshops am 31. Oktober 2010 an der Hochschule Harz, an dem die Projektleiterinnen und Projektleiter über den jeweiligen Projektstand berichteten, und eines Abschlussworkshops am 2. Dezember 2011 an der Hochschule Anhalt vorgestellt. Der vorliegende Tagungsband enthält die Abschlussberichte von vier der geförderten Projekte, deren Förderungen Ende 2011 bzw. Anfang 2012 auslaufen. Die übrigen drei Projekte, deren Förderungen noch weiterlaufen, berichten über den jeweiligen Stand zum September/Oktober In der Restlaufzeit dieser Projekte erfolgen im Wesentlichen nur noch Realisierungen von bereits entwickelten Konzepten bzw. Prozessen, sodass die in diesem Tagungsband enthaltenen Berichte zu diesen Projekten bereits einen fast vollständigen Überblick über die Projektergebnisse geben. Wenngleich einige Projekte erst auch im Laufe des Jahres 2012 bzw. sogar erst 2013 enden, kann bereits jetzt durch die LDVK festgestellt werden, dass die EFRE- Maßnahme 11.03/41.03 als Ganzes erfolgreich war. Die Projekte haben ihre im Antrag formulierten Ziele größtenteils erreicht bzw. werden sie erreichen. Die Ergebnisse der Projekte scheinen nachhaltig, auch über die Institutionsgrenzen hinaus, genutzt werden zu können. Halle an der Saale, im Januar 2012 Prof. Dr. Paul Molitor Vorsitzender der LDVK

4 IV Inhaltsverzeichnis Projekt Einführung einer Smartcard basierten Single Sign-On Lösung Martin-Luther-Universität Halle-Wittenberg Projekt ecampus-services & -Infrastrukturen für eine gesicherte und verbindliche elektronische Hochschulverwaltung Hochschule Harz, Hochschule Anhalt Projekt Campusmanagement Einführung und Nutzung von webbasierten Onlineplattformen für die effektive Unterstützung der Prozesse in Forschung, Lehre und Verwaltung an verschiedenen Hochschultypen Martin-Luther-Universität Halle-Wittenberg Projekt Homogene Verzeichnisdienste Otto-von-Guericke-Universität Magdeburg, Hochschule Harz Projekt Integrierte Forschungsplattform für den Forschungsschwerpunkt Decision Design Gestaltung ökonomischer Prozesse und Institutionen Otto-von-Guericke-Universität Magdeburg Projekt Aufbau eines Online-Supportnetzwerkes für Technologietransfer und öffentliche Verwaltung Otto-von-Guericke-Universität Magdeburg Projekt Online-Serviceportal campus2go Hochschule Magdeburg-Stendal

5 1 Einführung einer Smartcard basierten Single Sign-On Lösung Ausführende Einrichtung(en): Martin-Luther-Universität Halle-Wittenberg Projektleiter: Prof. Dr. Paul Molitor, Institut für Informatik, Martin-Luther-Universität Halle-Wittenberg, D Halle (Saale). Dr. Sandro Wefel, Institut für Informatik, Martin-Luther-Universität Halle-Wittenberg, D Halle (Saale). Förderung: Dieses Vorhaben wird mit Mitteln der Europäischen Kommission aus dem Europäischen Fonds für regionale Entwicklung (EFRE) im Rahmen der Maßnahme 11.03/41.03 gefördert (FKZ: ). Zusammenfassung Ziel des Projekts ist die Entwicklung und der Test eines umfangreichen Gesamtsystems für die Verwendung von Smartcards zur Verbesserung der IT-Sicherheit in breiten Bereichen des universitären Umfelds. Da erhöhte Sicherheit zumeist auch mit einem höheren Aufwand verbunden ist, steht insbesondere die Frage der Akzeptanz eines solchen Systems durch die Nutzer im Mittelpunkt der Entwicklung und der Untersuchung. Ein wichtiger Punkt ist die Vereinfachung inneruniversitärer organisatorischer Abläufe auf Basis Smartcard-gestützter elektronischer Verfahren und dem Einsatz der digitalen Signatur. Die erarbeitete Lösung kommt für eine breit gefächerte Palette von Anwendungen zur Beförderung der Sicherheit elektronischer Dienste und Systeme der Universität zum Einsatz. Insbesondere die Möglichkeiten zum plattform- und applikationsübergreifenden Single Sign-On waren hierbei zu untersuchen. Darüber hinaus wurden technische Lösungen und organisatorische Abläufe für weitere Dienste auf Basis des eingesetzten Smartcard- Systems geschaffen. Angedacht ist die Nutzung für Dokument- und verschlüsselung, für die elektronische Signatur und für Zutrittskontrollsysteme. Projekt , Martin-Luther-Universität Halle-Wittenberg

6 2 1 Einleitung 1.1 Ausgangssituation und Problembeschreibung Die verlässliche Authentifizierung von Nutzern in elektronischen Systemen ist ein wesentlicher Eckpfeiler für die Sicherheit einer IT-Struktur. Aufgrund zunehmender Vernetzung heutiger Systeme in Verbindung mit steigender Anzahl krimineller Aktivitäten über Online- Zugänge ist der Authentifizierung ein besonders hohen Stellenwert beizumessen. IT-Verantwortliche stehen vor der Herausforderung, eine den wachsenden Ansprüchen genügende Authentifizierungslösung umzusetzen, und versuchen mit unterschiedlichen Ansätzen dieser nachzukommen. Das Problem stellt sich nicht nur im privatwirtschaftlichen Sektor bzw. im Bereich staatlicher Behörden, sondern auch im nicht kommerziellen, wissenschaftlichen Sektor. Dabei geht es nicht allein um die Vermeidung des unberechtigten Zugriffs zur Wahrung der Vertraulichkeit. Vielmehr stellen Hochschulen mit ihrem großen Nutzerkreis und guten Internetanbindungen einen idealen Ausgangspunkt für Angreifer dar. So bieten die verschiedenen Dienste, die vielfältigen Zugangsmöglichkeiten und der heterogene Nutzerkreis mit hohem Anteil an nicht sicherheitsbewussten Nutzern einen lohnenswerten Angriffspunkt. Im Vergleich zu anderen Einrichtungen stellen sich für Hochschulen insbesondere zwei Probleme. Für die Erreichung adäquater Sicherheit steht zum Einen meist ein geringeres finanzielles Budget zur Verfügung. Auf der anderen Seite bieten gerade die Hochschulen einer großen Anzahl häufig wechselnder Nutzer den Zugriff auf netzgestützte Rechner und den Onlinezugang. Eine Sicherheitsschulung ist nicht durchführbar, wäre aber Anbetracht der Angreifbarkeit erforderlich, um das Augenmerk der Nutzer auf die Bedeutung der Authentifizierung und den richtigen Umgang mit den Authentifizierungsmerkmalen zu lenken. Das meist eingesetzte Verfahren an Hochschulen besteht in der Vergabe von ein oder mehreren Zugangskennwörtern (Passwörtern), welche den Nutzern zur Authentifizierung (z.b. bei Netzzugang oder Dienstanmeldung) dienen. Aber gerade die passwortbasierte Authentifizierung bietet viele Angriffspunkte, insbesondere wenn sie von ungeschulten Nutzern unzureichend eingesetzt wird [1]. Im Hinblick auf die Einführung einer bzgl. Sicherheit verbesserten Lösung an Hochschulen ist folgendes zu bedenken. Erhöhte Sicherheit erfordert meist einen erhöhten Aufwand, sowohl in finanzieller Hinsicht, als auch unter dem Aspekt der bequemen Anwendbarkeit. Da aber gerade der Fakt der bequemen Anwendung meist entscheidend ist, wird ein anderes Verfahren mit höherem Aufwand gegenüber dem Einsatz von Passwörtern auf Skepsis und Ablehnung stoßen. Außerdem ist die Umstellung mit hohem organisatorischem und logistischem Aufwand verbunden. In Anbetracht der Anzahl möglicher Nutzer kann keine komplette Umstellung zu einem festen Termin erfolgen. Gesucht wurde deshalb eine Lösung für den Einsatz eines Authentifizierungsverfahrens mit adäquater Sicherheit, welches von den Nutzern akzeptiert wird und parallel zu beste- Projekt , Martin-Luther-Universität Halle-Wittenberg

7 3 henden Verfahren eingesetzt werden kann. Der damit verbundene Nachteil des erhöhten Aufwandes sollte durch geeignete Maßnahmen kompensiert werden, zu denen die Schaffung zusätzlicher Anwendungsmöglichkeiten gehören. Insgesamt sollte erreicht werden, dass mit verbesserter Sicherheit, insbesondere bei der Authentifizierung aber auch in anderen Bereichen, gleichzeitig neue Möglichkeiten geschaffen werden, die für eine moderne Kommunikation erforderlich sind und die sich in die Abläufe der Hochschulen integrieren. 1.2 Lösungsansatz Die Einführung einer alternativen Authentifizierungsvariante, die gleichzeitig eine Verbesserung im Hinblick auf Sicherheit (Authentizität) bedeutet, muss mehrere Aufgaben erfüllen. Sie muss möglichst einfach anwendbar sein und dabei im Vergleich zu Passwörtern ein höheres Sicherheitsniveau bieten, parallel zu bestehenden Systemen einsetzbar sein, die Weitergabe der Authentisierungsmerkmale verhindern, für die Anmeldung am Rechner und an Netzwerken geeignet sein und weitere Funktionalitäten zur Erhöhung der Akzeptanz des neuen Ansatzes bieten. Bei einem Vergleich der Sicherheit (wenngleich nicht messbar) schneiden die Verfahren, welche auf zeitlich beschränkten oder einmal nutzbaren Passwörtern oder auf Nutzerzertifikaten bestehen, gut ab. Der logistische Aufwand für die Verwendung von Einmal- Passwörtern bzw. der Hardwareaufwand in Form von Passwort-Generatoren (SecurID Token), welche keine weiteren Einsatzzwecke haben, lässt diese Verfahren für Hochschulen aber als nicht praktikabel erscheinen. Ähnlich sicher ist die zertifikatsbasierte Authentifizierung, sofern der private Schlüssel sicher abgelegt ist. Im Gegensatz zu Einmal-Passwörtern können wir bei der zertifikatsbasierten Authentifizierung die Zertifikate für weitere Zwecke nutzen, z. B. im Rahmen elektronischer Signaturen und der Datenverschlüsselung. Möchte man im Vergleich zu Passwörtern eine markante Verbesserung erreichen, so bettet man die zu den Zertifikaten gehörenden privaten Schlüssel in Hardware-Crypto-Token ein. Das Kopieren des Authentisierungsmerkmals in Form des privaten Schlüssels wäre damit nicht möglich, was das Authentifizieren einer weiteren Person unter dieser Identität verhindert. Allerdings ist mit diesem Verfahren ebenfalls ein höherer Hardwareaufwand in Form von Crypto-Token und zugehörigen Lesegeräten, z.b. in Form von Smartcards und Smartcard- Readern, erforderlich. Da aber bereits an vielen Hochschulen Chipkarten für andere Zwecke, z.b. als elektronische Geldbörse der Studentenwerke eingesetzt werden, sind Studierende deren Einsatz gewöhnt und das Mitführen einer Smartcard stellt keinen wesentlich höheren Aufwand dar. Wenn die Smartcards mit der Studierendenkarte kombiniert werden, lassen sich die Kosten reduzieren. Die Ausrüstung mit entsprechenden Lesegeräten Projekt , Martin-Luther-Universität Halle-Wittenberg

8 4 in den Pools sind im Rahmen der Anschaffungskosten neuer Rechner eher gering, so dass der finanzielle Aufwand u berschaubar ist. Da fu r die Authentifizierung die Smartcard mit dem Rechner verbunden werden muss und die Eingabe einer PIN1 erforderlich ist, stellt dies einen zusa tzlichen Aufwand gegenu ber der Eingabe eines Passwortes dar. Zur Kompensation dieses Aufwandes wurde deshalb die PINEingabe auf einen Zeitpunkt wa hrend einer Rechnersitzung reduziert, anschließend kann die Karte fu r nachfolgende Authentifizierungen, z.b. bei der Anmeldung an Diensten, ohne weitere PIN-Eingabe, quasi im Hintergrund ge- Abbildung 1: Token in Form von USBSticks und Smartcards nutzt werden. Dies erlaubt folgendes Szenario: Ein Nutzer authentifiziert sich gegenu ber einem Rechner nicht mehr durch Eingabe von Nutzername und Passwort, sondern durch Einstecken der Smartcard und Eingabe der PIN. Anschließend kann er die Webseiten der universita ren Portale aufrufen oder abrufen, ohne erneut die PIN oder ein Passwort eingeben zu mu ssen. Somit ermo glichen Smartcards den Einsatz fu r Single Sign-On (SSO) und ko nnen gleichzeitig als Container fu r elektronische Schlu ssel zur elektronischen Signatur oder Verschlu sselung mit hohem Grad an Sicherheit verwendet werden. Um die Authentizita t auch u ber den Rahmen der Hochschule hinaus zu belegen, werden die Zertifikate von einer u bergeordneten Stelle, die landes- oder bundesweit agiert und als vertrauenswu rdig angesehen wird, ausgestellt. Daru ber hinaus ko nnen die Smartcards, mit ihrer Fa higkeit Informationen zu speichern und intern unter Anwendung kryptographischer Verfahren zu verarbeiten, fu r andere Einsatzfelder genutzt werden. So kann z.b. ein Tu ro ffnungssystem mit einem biometrischen Lesegera t gekoppelt werden und die sensible Information, das biometrische Muster, u ber die Karte verarbeitet werden und muss nicht außerhalb der Karte gespeichert werden. Derartige Einsatzfelder ko nnen die Nutzung der Token weiter befo rdern und somit helfen, die Akzeptanzschwelle zu deren Einsatz zu u berwinden. Um nachzuweisen, dass sich dieses Prinzip im praktischen Einsatz bewa hrt, wurde eine zertifikatsbasierte SSO-Authentifizierungslo sung mit Studierenden aufgebaut und getestet. Dabei wurde nicht nur die Authentifizierung gepru ft, sondern auch der erforderliche organisatorische Aufwand bei der Einfu hrung und im Regelbetrieb ermittelt sowie weitere Einsatzfelder fu r die Smartcards gepru ft, um mo glichst viele Facetten des SmartcardEinsatzes zu erfahren. 1 Die Authentifizierung gegenu ber dem Token erfolgt meist durch die Eingabe einer PIN, welche bei Anwendung durch mehrere Applikationen mehrmals einzugeben wa re. Alternativ kann die Authentifizierung auch durch biometrische o.a. Verfahren erfolgen. Projekt , Martin-Luther-Universita t Halle-Wittenberg

9 5 PKCS#11 Bibliothek vom Token Hersteller PKCS#11- Proxy Hilfsprogramme SSO-System Steuerung des Agenten Agent Applikationen geschützte Kommunikation Lokales System Abbildung 2: Schema der SSO-Software (blau hinterlegt) 1.3 Vorarbeiten zum Projekt Im Rahmen einer Dissertation wurde die prinzipielle Anwendbarkeit der plattform- und applikationsübergreifenden SSO-Lösung auf Basis von Zertifikaten in Verbindung mit Hardware Crypto-Token (Smartcards) als Proof-Of-Concept gezeigt [7, 8]. Es handelt sich um eine clientseitig arbeitende SSO-Software, die über eine standardisierte Schnittstelle die Verbindung zu Smartcards und USB-Crypto-Token herstellt. Diese Lösung ermöglicht dem Nutzer nach einer einmaligen Anmeldung gegenüber dem Token sämtliche Applikationen mit Token-Unterstützung ohne weitere PIN-Eingabe zu verwenden. Abbildung 2 skizziert den schematischen Aufbau. Zu den in der Grafik dargestellten Applikationen gehören viele Standardapplikationen, wie z. B. Firefox, Thunderbird und OpenSSH, die kompatibel zu dem System sind, sodass ein großes Einsatzfeld abgedeckt wird. Eine Diplomarbeit auf dem Gebiet der zertifikatsbasierten Authentifizierung, angefertigt an der Universität Halle, zeigt die einfache Einsetzbarkeit dieses Verfahrens im Hochschulbereich für den Zugang zum universitären Netz und für den Einsatz bei Diensten innerhalb der hochschulweiten IT-Landschaft [6]. Projekt , Martin-Luther-Universität Halle-Wittenberg

10 6 1.4 Arbeitsprogramm Zur Einführung der Smartcard-basierten Single Sign-On Lösung an der Martin-Luther- Universität Halle-Wittenberg waren folgende Punkte umzusetzen: 1. Aufbau einer Zertifikats-Infrastruktur (Public-Key-Infrastruktur PKI) 2. Beschaffung, Ausgabe und Initialisierung der Crypto-Token (Smartcards) 3. Installation von Hardware (Smartcard-Reader) 4. Installation und Konfiguration der zugehörigen Middleware, bestehend aus Smartcard-Bibliotheken und SSO-Software auf den Arbeitsplatz- und Poolrechnern 5. Anpassungen der universitären Dienste für die zertifikatsbasierte Authentifizierung 6. Planung und Inbetriebnahme der Zutrittskontrollsysteme 7. Testbetrieb im größeren Nutzerkreis und Auswertung der Rückmeldungen 8. Aufbau der Zusatzdienste (Online-Zertifikatsprüfung, Zeitstempel) Die ausgestellten Zertifikate sind für den Einsatz innerhalb der Universität bestimmt, sollen aber auch darüber hinaus genutzt werden können. Wird die PKI und die ausstellende Stelle (Certificate Authority, CA) von der Universität selber betrieben, sind bestimmte Anforderungen (entsprechend den Maßgaben des Signaturgesetzes) umzusetzen [3]. Ohne deren Einhaltung wäre das Vertrauen in die ausgestellte Zertifikate nicht gewährleistet. Aus diesem Grund sollte für den Aufbau der PKI ein überuniversitär agierender Dienstleister hinzugezogen werden, dessen Unterschriftszertifikat von gängiger Software akzeptiert wird. Bei der Beschaffung und dem Einsatz der Smartcards war darauf zu achten, dass diese von den Studierenden auch wirklich genutzt werden. Deshalb kommt nur die Kopplung mit dem bereits vorhandenen Studierendenausweis, welcher in Form einer kontaktlosen Chipkarte vorliegt, in Frage. Abbildung 3: Studierendenausweis mit kontaktlosem Chip Für eine spätere Überführung in einen nachhaltigen Regelbetrieb war erforderlich, dass die aufgebauten Systeme und Strukturen möglichst reibungslos interagieren und wartungsarm arbeiten. Die zusätzliche Belastung der Administratoren, Mitarbeiter und Mitarbeiterinnen innerhalb der Verwaltung sollte möglichst gering sein. Projekt , Martin-Luther-Universität Halle-Wittenberg

11 7 2 Umsetzung und Ergebnisse 2.1 Arbeitsablauf In einem ersten Schritt wurde eine eigene PKI-Infrastruktur aufgebaut und der Zertifizierungsbetrieb unter Verwendung von Smartcards bzw. USB-Token unterschiedlicher Hersteller sowie der Einsatz der Karten getestet. Die Tests offenbarten, dass frei verfügbare Software zum Aufbau einer PKI starke Einschränkungen besitzt und einen hohen Zusatzaufwand für Anpassungen benötigt. Die Pflege einer angepassten Software wäre somit über den Projektzeitraum hinaus nicht gewährleistet. Zudem schien nicht gewährleistet zu sein, dass mit der Software der Betrieb einer Sub-CA mit Anbindung an eine überuniversitär anerkannte CA möglich ist. In Absprache mit dem Universitätsrechenzentrum wurde aus diesem Grunde entschieden, keine eigene CA zu betreiben, sondern diese auszulagern (siehe Punkt 1 der abgeschlossenen Arbeiten). Bei der Entscheidung für ein konkretes Token zur Durchführung eines Feldtests mit ungefähr 1000 Studierenden mussten neben dem Anschaffungspreis und der Möglichkeit zur Einbettung in die vorhandene Studierendenkarte beachtet werden, dass die verbauten Crypto-Chips von der Software (PKI- und Anwendungsprogramme) über eine entsprechende Middleware (die PKCS#11-Bibliothek in Abbildung 2) unterstützt werden. Zu berücksichtigen waren in diesem Zusammenhang zudem die mit der Middleware verbundenen Lizenzkosten. Nach verschiedenen Tests fiel die Wahl auf die Einbettung eines Crypto-Chips SLE66CX642P mit CardOS-4.3b, da diese Kombination preislich relativ günstig ist, eine adäquate Sicherheit bietet und von der freien PKCS#11-Middleware aus der OpenSC-Suite teilweise unterstützt wurde [2]. Im Rahmen des Projektes wurden Ergänzungen zu OpenSC implementiert, die die Nutzung der Karten in einer zu den anderen getesteten kommerziellen Systemen kompatiblen Art und Weise erlaubt. Die Erweiterungen sind in die offizielle OpenSC-PKCS#11 Middleware eingeflossen und werden in dem aktuellen Release der Middleware mitgeliefert. Nach Aufbau der PKI-Infrastruktur und Beschaffung der Smartcards wurde die Applikations-Software für den konkreten Smartcardtyp angepasst. Dazu gehörte die Entwicklung der RA-Software zur Ausstellung der Zertifikate für Studierende und zur Ablage auf die Smartcard. Anschließend wurden personalisierte Smartcards an interessierte Studierende des Instituts für Informatik ausgegeben. Im Vorfeld wurden bereits die Linux- Pools des Instituts für die Benutzung mit Smartcards ausgerüstet, später auch weitere Pools, bei denen insbesondere die ThinClient-Pools eine Herausforderung darstellten. Die Studierenden können sich mit der Smartcard an den Rechnern anmelden und anschließend die Karte für weitere Zwecke nutzen. Dabei gibt es keinen Zwang zur Verwendung der Smartcard, man kann zwischen Karte und Passwort wählen. Im weiteren Verlauf der Arbeiten wurden die Netzwerkdienste mit der Nutzung der Smartcards getestet und notwendige Anpassungen durchgeführt. Projekt , Martin-Luther-Universität Halle-Wittenberg

12 8 Die Arbeitsabläufe wurden in einem Projektverwaltungssystem dokumentiert, welches für Administratoren nach vorheriger Anmeldung zur Verfügung steht 2. In diesem System wurden die Informationen zur Einrichtung der PKI, zur Anpassung und Konfiguration der Applikationen und zur Benutzung der RA-Software gesammelt und stehen registrierten Nutzern zur Nachnutzung zur Verfügung. Auf einer öffentlichen Webseite wurden Informationen zum Zertifizierungsbetrieb hinterlegt. Hier finden alle Nutzer die erforderliche Middleware und die technischen Informationen zu deren Einrichtung 3. Die Seite wurde gezielt auf einem einfachen technischen Niveau für die Endanwender gehalten. 2.2 Abgeschlossene Arbeiten Folgende der im Arbeitsprogramm genannten Punkte wurden umgesetzt die Nummerierung bezieht sich auf die Nummerierung im Arbeitsprogramm: 1. Aufbau einer Zertifikats-Infrastruktur (Public-Key-Infrastruktur PKI) Dieser wesentliche Punkt bildete den Grundstein für die restlichen Arbeiten und wurde demzufolge zuerst umgesetzt. Für den Aufbau der PKI wurde die Dienstleistung der DFN- PKI 4 in Anspruch genommen. Die DFN-PKI erlaubt die Auslagerung der CA, bei der die organisatorische und technische Umsetzung des CA-Betriebs durch den DFN-Verein übernommen wird. Neben der Minderung des technischen Aufwands für die Universität erlaubt die Auslagerung des Zertifizierungsbetriebs an die DFN im Sicherheitsniveau Global die Ausstellung von Server- und Personenzertifikaten, abgeleitet vom Wurzelzertifikat der Deutschen Telekom Root CA 2. Der Vorteil besteht darin, dass dieses Zertifikat in gängiger Software und gängigen Betriebssystemen (MS Windows XP, Thunderbird ab V.2, Firefox ab V.3.5) hinterlegt ist und somit als vertrauenswürdig eingestuft wird. Für die Inbetriebnahme der PKI werden Registrierungsstellen (Registration Authority RA) innerhalb der Universität benötigt, welche die erforderliche Überprüfung der Identität der Antragsteller (Studenten/Studentinnen und Mitarbeiterinnen/Mitarbeiter) im persönlichen Kontakt durchführen. Zur Registrierung der Studierenden bietet sich der Aufbau dieser Stelle im Immatrikulationsamt an 5. Im Rahmen des Projekts wurde eine Software (RA- Tool) konzipiert und implementiert, welche die einfache Beantragung von Zertifikaten durch Mitarbeiterinnen/Mitarbeiter der Universität ermöglicht. Nach Einlegen der Smartcard erkennt die Software den Inhaber/die Inhaberin anhand der im kontaktlosen Teil enthaltenen Informationen, ergänzt die fehlende Daten aus Datenquellen des universitären Identity- Managements und füllt damit die Bildschirmmaske aus. Im Anschluss wird der Zertifikats- 2 Zur Anmeldung eine an sandro.wefel@informatik.uni-halle.de senden Momentan erfolgt die Ausgabe der Zertifikate durch die Projekt-Mitarbeiter. Dies verkürzt die Kartenausgabezeit, ermöglicht das Erkennen von Bedienfehlern in der RA-Software und führt somit zu einer höheren Usability. Projekt , Martin-Luther-Universität Halle-Wittenberg

13 9 antrag ausgedruckt und muss von dem Antragsteller/der Antragstellerin unterschrieben werden. Im Hintergrund beantragt die Software u ber eine SOAP-Schnittstelle bei der ausgelagerten CA die Zertifikate und schreibt diese bei Erhalt auf die Smartcard, welche dem Antragsteller/der Antragstellerin zusammen mit dem parallel ausgedruckten PIN-Brief ausgeha ndigt wird. Der RA-Mitarbeiter/Die RA-Mitarbeiterin muss somit lediglich die auf dem Bildschirm angezeigten Daten mit dem Lichtbild-Ausweis der Person vergleichen, die Antragstellung durch Knopfdruck besta tigen sowie den Antrag zur Unterschrift, den PIN-Brief und die Smartcard ausgeben. Dies sollte dem Anspruch des geringen Zusatzaufwandes bei der Einfu hrung der zertifikatsbasierten Authentifizierung genu gen. Fu r die Ausgabe auf den PIN-Brief wurde eine Version entwickelt, welche die PIN in das verdeckte Sichtfeld eines Hydalam-Formulars6 druckt. Nach dem Druck bleibt der Inhalt des verdeckten Feldes im Gegensatz zum Rest der Seite verborgen. Der Antragsteller muss zuerst das hinterlegte Sichtfeld o ffnen, ein Vorgang, der nicht ru ckga ngig gemacht werden kann. Dadurch wird sichergestellt, dass RA-Mitarbeiter die PIN nicht lesen ko nnen. Jeder Versuch, Zugriff auf die PIN zu erlangen, kann anhand der Bescha digung der Sichtfeldabdeckung vom Antragsteller erkannt werden. Die Antragsteller erhalten insgesamt drei ZertiAbbildung 4: Hydalam fikate, eines fu r die Benutzeranmeldung (SSOAuthentifizierung), eines zur elektronischen Signatur (z.b. fu r den Nachweis der Authentizita t einer ) und ein Zertifikat zur Verschlu sselung. Bei einer verschlu sselten Nachricht an eine Person beno tigt diese die Karte fu r deren Entschlu sselung. Bei Verlust einer Karte ko nnen die Zertifikate als ungu ltig erkla rt (Ru ckruf) und neue Zertifikate zusammen mit einer neuen Karte ausgestellt werden. Dies gilt jedoch nicht fu r das Verschlu sselungszertifikat, da andernfalls mit dem neuen Schlu ssel kein Zugriff auf alte verschlu sselte Daten besteht. Aus diesem Grund wurde ein Mechanismus in das RA-Tool eingebaut, welcher die Verschlu sselungsschlu ssel zum Zertifikat in verschlu sselter Form fu r ein spa teres Recovery speichert. Der Zertifikatsru ckruf wird ebenfalls durch das entwickelte RA-Tool abgedeckt und kann auf Knopfdruck vom RA-Mitarbeiter ausgelo st werden. Fu r das Recovery des Verschlu sselungszertifikats, welches ebenfalls u ber das RA-Tool mo glich ist, wird etwas mehr Aufwand beno tigt. Dazu existiert eine weitere Smartcard, deren PIN nur zur Ha lfte zwei unabha ngigen Personen, die nicht zur RA geho ren, bekannt ist. Fu r ein Recovery mu ssen diese beiden Personen vor Ort sein und ihren Teil der PIN eingeben, bevor das Zertifikat, genauer der zugeho rige Schlu ssel aus der Datenbank zuru ck geholt, entschlu sselt und auf die neue Karte geschrieben werden kann. Nach Festlegung dieses Ablaufs wurde die Policy fu r den Zertifizierungsbetrieb der Uni6 Projekt , Martin-Luther-Universita t Halle-Wittenberg

14 10 Abbildung 5: Zertifikatsausstellung Halle-Chipcard CA 7 festgelegt und der Betrieb für die Ausstellung von Personenzertifikaten auf Smartcards bzw. Token in Verbindung mit der DFN aufgenommen. Der Ablauf der Zertifikatsausstellung ist in der Abbildung 5 dargestellt. Der Aufwand des Mitarbeiters beläuft sich auf die Prüfung der Identität, das Einlegen der Smartcard des Antragstellers, die Prüfung der Unterschrift auf dem Antragsbogen, die Betätigung der Ausstellungstaste in der RA-Software und die Ausgabe der Smartcard und des PIN-Briefes. Alle anderen Abläufe erfolgen im Hintergrund in elektronischer Form. 2. Beschaffung, Ausgabe und Initialisierung der Crypto-Token Für eine hohe Akzeptanz der Smartcards war es erforderlich, den bereits vorhandenen Studierendenausweis in Form einer kontaktlosen Chipkarte mit der Smartcard zu einer Hybridkarte zu verbinden. Aufgrund vertraglicher Bindung der Universität mussten die Hybridkarten vom Lieferanten der kontaktlosen Chipkarten gekauft werden. An der Universität wurden bisher Karten des Typs Mifare Classic eingesetzt. Die 2008 entdeckten Sicherheitsmängel an der zugrunde liegenden Verschlüsselung Crypto 1 (siehe [5, 4]) zwangen die Universität und das Studentenwerk zu einem Wechsel der Kartentechnologie auf eine sicherheitstechnisch verbesserte Variante. Der Karten-Lieferant musste die entsprechende Infrastruktur an der Universität umstellen, was zu Verzögerung in unserem Projekt führte, speziell in Bezug auf den Beginn des Testbetriebs. So war die Anschaffung der ersten Smartcards laut Projektplan bereits für das Jahr 2009 angesetzt. Da zu diesem Zeitpunkt nur Hybridkarten mit Mifare Classic geliefert worden wären, entschieden wir uns für die Verschiebung nach 2010, um bereits die aktuellen auf DESFire beruhenden Karten in Verbindung mit Crypto-Chip zu erhalten. Dies soll den nachhaltigen Betrieb des Systems auch über einen Testzeitraum hinaus sicherstellen und somit die Bereitschaft der Studierenden zur Mitarbeit befördern. Die Karten mit eingebetteten Chip wurden im Herbst 2010 bestellt und verzögert im Januar 2011 geliefert. Die Verzögerungen beruhte auf einer erforderlichen Kompatibilitätsprüfung des auf der Karte 7 Projekt , Martin-Luther-Universität Halle-Wittenberg

15 11 (a) Vorderseite (b) Ru ckseite mit Cryptochip Abbildung 6: Neuer Studierendenausweis mit kontaktlosem und mit Cryptochip enthaltenen TRW-Streifens8 mit den Validierungsterminals der Universita t. Diese Terminals hinterlegen auf dem TRW-Streifen in jedem Semester verschiedene Informationen, z. B. zur Gu ltigkeit der Karte und zum Semesterticket des Mitteldeutschen Verkehrsverbundes MDV (unterer Bereich in Abbildung 6(a) ). Da mit den neuen Karten auch der Hersteller des TRW-Streifens wechselte, war ein vorheriger Kompatibilita tstest erforderlich. Der Testbetrieb mit einer kleinen Anzahl an Testkandidaten startete im Ma rz Wie bereits unter Punkt 1 erwa hnt, erfolgt die Initialisierung der Smartcards mit perso nlichen Zertifikaten u ber eine eigens dafu r entwickelte Software. Mittels dieser Software werden fu r die Karteninhaber perso nliche Zertifikate beantragt und auf der Karte ausgegeben. Die notwendigen organisatorische Regelungen konnten rechtzeitig zur Kartenausgabe umgesetzt werden Installation von Hardware (Smartcard-Reader) und Middleware Die Computerpools der Informatik wurden zum gro ßten Teil mit Smartcard-Readern ausgestattet. Fu r die Universita t wurde die Festlegung getroffen, neue Pools bei Beschaffung mit Smartcard-Readern auszuru sten. Auf diese Art ist in der Zwischenzeit schon eine fast fla chendeckende Nutzung der Karten in Computerpools der Universita t mo glich. Die Middleware (OpenSC) wurde erweitert und in eine installationsfertige Form gebracht. Sie unterstu tzt die ausgewa hlten Crypto-Chips und steht aktuell unter den Betriebssystem Linux zur Verfu gung. Eine Windows-Version war Mitte des Jahres 2011 verfu gbar und wurde erweitert, um mit den an der MLU ausgegebenen Karten genutzt werden zu ko nnen. Im Rahmen des Projektes wurde im Jahr 2009 die bereits entwickelte SSO-Software auf einen Stand gebracht, der den Einsatz in den Pools erlaubt. Fu r den Feldtest wurde sie zusammen mit der Middleware in einem Pool des Instituts fu r Informatik installiert. Im Anschluss wurde die Installation auf weitere Pools ausgeweitet. Da es sich bei der SSO-Software um eine Neuentwicklung handelt, wurden in den folgenden Monaten die beim Test erkannten Fehler in der Software beseitigt und die Software in mehreren Iterationen aktualisiert und an neue Betriebssysteme angepasst. Problematisch war die Einbindung der ThinClient-Pools der Informatik. Diese Pools sind 8 TRW: Thermo-ReWrite, ein thermisches Druckverfahren, welches das Lo schen und Wiederbeschreiben des Kartenaufdrucks ermo glicht. Projekt , Martin-Luther-Universita t Halle-Wittenberg

16 12 ThinClient mit Reader Netzwerkverbindung Server mit Applikationen Video / Audio Applikationen lokal? Tastatur / Maus ggf. USB erforderlicher, aber nicht vorhandener Kanal Abbildung 7: Anbindung ThinClients mit Thin- oder UltraThin-Clients ausgerüstet, welche die Daten nicht selber verarbeiten. Sie dienen lediglich als Terminal für die Arbeit auf einem Remote-System, üblicherweise ein leistungsstarker Server. Abbildung 7 skizziert das Prinzip. Die Tastatur- und Mauseingaben der ThinClients werden an den Server geleitet und dessen Antwort in Form von Video- und Audioausgabe zum ThinClient reflektiert. Auf dem ThinClient selber können zwar Programme ausgeführt werden, dies entspricht aber nicht der üblichen Arbeitsweise. Da keine Weiterleitung der Smartcardverbindung zum Server durch den ThinClient vorgesehen war, blieben vorerst die ThinClients von der Nutzung mit Smartcard ausgeschlossen. Dies war ein sehr unbefriedigender Zustand, da die ThinClients des Instituts von vielen Studierenden genutzt werden, insbesondere zu Zeiten, in denen andere Pools durch Lehrveranstaltungen belegt sind. Im Bezug auf einen Lösungsansatz war zudem zu beachten, dass die Server meist von mehreren Nutzern parallel verwendet werden können. Eine eindeutige Zuordnung der Applikation zu dem Nutzer oder genauer, eine Zuordnung zum ThinClient des Nutzers ist erforderlich. Diese Probleme konnten im Rahmen einer Bachelorarbeit gelöst werden [9]. Dazu wurde eine Applikation entwickelt, welche einen parallelen Kanal zwischen ThinClient und Server aufbaut und darüber den Fernzugriff der Server-Applikationen auf die Smartcard ermöglicht. Diese Lösung steht seit August 2011 zur Verfügung und wird aktuell in den Pools getestet. 5. Anpassungen der universitären Dienste Als erster universitärer Dienst wurde das zentral eingesetzte Lehr- und Lernmanagement- System Stud.IP auf parallele Authentifizierung mit Smartcard umgestellt. Die Studierenden können sich nunmehr bei eingelegter Smartcard an Stud.IP ohne Passwort anmelden. Als weiterer Dienst wurden der Online-Zugang zur Bibliotheksplattform für das System angepasst. Dazu wurde eine Smartcard-Erweiterung für den Shibboleth-Dienst entwickelt. Bei Shibboleth handelt es sich um ein verteiltes SSO-System, welches an Universitäten häufig in Bibliotheken zum Einsatz kommt. Grund dafür ist die mögliche Anbindung an Verlage in der EU. Auch an der MLU wurde im Jahr 2011 auf dieses System umgestellt. Aktuell befindet sich die entwickelte Smartcardanbindung im Testbetrieb und wird in nächster Zeit der Öffentlichkeit zur Verfügung stehen. Ebenfalls geplant, zum Teil umgesetzt, aber noch nicht öffentlich verfügbar ist eine Anbindung von Software zum -Versand und -Empfang über die Universität. Diese Softwa- Projekt , Martin-Luther-Universität Halle-Wittenberg

17 13 re soll mit Verschlüsselung und Signatur kombiniert werden, um den Schutz der Inhalte zu erhöhen und gleichzeitig als Medium zur verbindlichen Anmeldung zu etablieren. Der Grund, mit der Freischaltung zu warten, liegt in der ebenfalls geplanten Umstellung des universitären -Systems auf eine neue Software. Eine Lösung für die alte Software wird aktuell nicht weiter entwickelt. 6. Planung und Inbetriebnahme der Zutrittskontrollsysteme Bereits zu Beginn des Projektzeitraums begann die Entwicklung eines Zutrittskontrollsystems, welches in Verbindung mit Smartcards den Zutritt in Bereiche mit unterschiedlich hohen Sicherheitsanforderungen im autonomen Betrieb kontrolliert. Gegenüber den bereits eingesetzten Kartensystemen bietet die Verbindung mit einem biometrischen Venenscanner Abbildung 8: Stud.IP Login mit Smartcard zusätzliche Sicherheit, um z.b. den Missbrauch einer gestohlenen Karte durch nicht rechtmäßige Inhaber auszuschließen. Das eingesetzte System wurde in Zusammenarbeit mit einem Ingenieurbüro entwickelt und basiert auf einer bereits getesteten Variante ohne Verbindung zu Smartcards. Durch die Smartcard können die biometrischen Muster auf der Karte gespeichert werden und verbleiben damit im Besitz des Inhabers 9 dies sollte helfen, prinzipielle Bedenken gegen biometrische Authen- tifizierung auszuräumen. In Zukunft wird untersucht, wie eine zusätzliche Absicherung der gespeicherten Muster durch die kryptographischen Möglichkeiten der Smartcard erreicht werden kann. Die Pools im Gebäude der Informatik wurden mit einem Zutrittskontrollsystem ausgerüstet. Studierende im Besitz einer gültigen Karte können mit der Karte diese Räume betreten. Als Bereich mit höherer Sicherheitsanforderung gilt der Serverraum, welcher nur von bestimmten Nutzern nach zusätzlicher biometrischer Authentifizierung betreten werden kann. 9 Momentan können die Muster zwar nicht vom Nutzer, jedoch vom Zutrittskontrollsystem ausgelesen und verarbeitet werden. In einem Folgeprojekt soll die Karten-interne Verarbeitung untersucht und entwickelt werden. Dadurch könnten die Muster nicht auslesbar in der Karte abgelegt werden. Projekt , Martin-Luther-Universität Halle-Wittenberg

18 14 3 Teilabgeschlossene Arbeiten 7. Testbetrieb im größeren Nutzerkreis, Auswertung der Rückmeldungen Ein Testbetrieb im größeren Nutzerkreis erfordert eine funktionale Infrastruktur, Smartcards und die Anpassung der Software. Um mögliche Fehler in der Software zu beheben, wurde ein erster Test mit einem kleinen, nicht repräsentativen Nutzerkreis gestartet. Der Test im größeren Nutzerkreis wurde erst nach Behebung der durch die Beta-Tester erkannten Probleme gestartet. Da die Smartcards erst Anfang 2011 zur Verfügung standen und sich der Probebetrieb über eine Jahreshälfte erstreckte, konnte der umfassendere Feldtest erst im letzten Quartal 2011 gestartet werden. Die Ergebnisse der Evaluation stehen Mitte 2012 zur Verfügung. 8. Aufbau der Zusatzdienste Als Zusatzdienste waren die Online-Zertifikatsprüfung und ein Zeitstempel-Dienst geplant. Zertifikate werden für einen bestimmten Gültigkeitszeitraum ausgestellt. An der Universität haben wir einen Zeitraum von 3 Jahren angesetzt, der durchschnittlichen Regelstudienzeit eines Bachelor-Studiums. Aufgrund verloren gegangener Smartcards kann es aber erforderlich werden, dass bereits vor Ablauf des Gültigkeitszeitraumes Zertifikate als ungültig erklärt werden müssen. Dazu wurde eine entsprechende Funktion in das RA-Tool integriert, welches einem RA-Mitarbeiter die Sperrung der Zertifikate ermöglicht. Die Sperrung wird vom RA-Mitarbeiter ausgelöst, wenn der betreffende Inhaber persönlich mit einem Lichtbildausweis vorstellig wird und den Verlust der Karte bekannt gibt. Zur Verkürzung der Zeiträume wurde auch eine Sperrung per oder telefonisch vorgesehen. Um Missbrauch zu vermeiden, indem z. B. eine Person fremde Zertifikate sperren lässt, wurde eine Sperr-TAN eingeführt. Diese wird auf dem PIN-Brief neben der PIN ausgedruckt. Der Inhaber kann bei Verlust seiner Karte die Sperr-TAN z. B. telefonisch dem RA-Mitarbeiter mitteilen. Das RA-Tool prüft diese TAN und bei korrekter Angabe werden die betreffenden Zertifikate gesperrt. Für die Prüfung auf vorzeitig als ungültig erklärte Zertifikate werden in bestimmten zeitlich festlegbaren Abständen Zertifikatssperrlisten erzeugt. Diese CRL-Dateien (CRL: Certificate Revocation List) stehen online für den Abruf zur Verfügung und werden von den Poolrechnern täglich aktualisiert. Derart ist sichergestellt, dass ein Login mit ungültigem Zertifikat spätestens am Folgetag der Sperrung nicht mehr möglich ist. Eine Online-Prüfung bei jeder Anmeldung erwies sich als unpraktikabel, da sie gewisse Verzögerungen mit sich bringt. Diese ist abhängig von der Anzahl paralleler Anmeldungen und kann z. B. bei Beginn einer Poolveranstaltung, bei der sich viele Teilnehmer gleichzeitig anmelden, merklich wahrgenommen werden. Durch Zertifikatssperrlisten ist eine Offline-Prüfung gesperrter Zertifikate möglich, vorausgesetzt die Verteilung der Sperrlisten ist organisatorisch geregelt. Ein Zeitstempel-Dienst wurde aufgebaut, bedarf aber weiterer Tests, bevor er offiziell in Betrieb geht. Die Tests erfolgen bis zum Ende des Jahres Projekt , Martin-Luther-Universität Halle-Wittenberg

19 15 4 Verwendung der Mittel Die Mittel wurden, abgesehen von der Beschaffung der Software und Smartcards entsprechend der Projektplanung umgesetzt. Es wurde ein redundantes Serversystem beschafft, dessen Hauptaufgabe die Bereitstellung der Zertifikatsdienste ist. Dazu gehört die Hinterlegung des Verschlüsselungs-Keys für das Recovery sowie die Hinterlegung der Zertifikate und Dienste zur Abfrage und Online-Prüfung der Gültigkeit. Das System steht für das zentrale Identity-Management der Universität zur Verfügung und wird bereits genutzt (Zertifkatsrecovery, LDAP-Server). Zwei Büro-Rechnersysteme wurden für den Testbetrieb der RA beschafft. Die Beschaffung der Smartcards überstieg den ursprünglich angesetzten Finanzbedarf aufgrund der Einbettung in DESFire- anstatt der geplanten Mifare-Karten. Da aber die Software zu einem günstigeren als den angesetzten Preis angeschafft werden konnte, standen die Mittel für die Hybridkarten zur Verfügung und wurden nach Rücksprache mit den Geldgebern dementsprechend verwendet. Für das Schließsystem wurden zwei biometrische Terminals angeschafft und eine Etage des Gebäudes der Informatik mit einem Simons-Voss Schließsystem ausgestattet und mit den Terminals verbunden. Die Nutzung des Simons-Voss Schließsystems war eine universitäre Vorgabe, da für den gesamten Bereich eine spätere Erweiterung auf Basis dieses Systems bereits vorgesehen ist. Die ausgegebenen Mittel blieben im geplanten Rahmen. Die Hilfskraftmittel wurden entsprechend der Planung umgesetzt. Weitere Ausgaben umfassen Kartenlesegeräte zur punktuellen Ausrüstung von Mitarbeiterrechnern und für Selbstbedienungsterminals sowie die Hydalam-Formulare und ein passender Drucker. Literatur [1] BSI: BSI-Lagebericht IT-Sicherheit. Lageberichte/bsi-lageberichte.html. [2] Security Confirmation and Report T-Systems TE [3] Gesetz über Rahmenbedingungen für elektronische Signaturen (Signaturgesetz - SigG). [4] 25C3: Analyzing RFID Security en.html. [5] Courtois, N.T., Nohl, K., und O Neil, S. Algebraic Attacks on the Crypto-1 Stream Cipher in MiFare Classic and Oyster Cards [6] Sparenberg, J. Einführung einer zertifikatsbasierten IEEE 802.1x Infrastruktur an der Martin-Luther-Universität Halle-Wittenberg. SHW?FRST=4. Projekt , Martin-Luther-Universität Halle-Wittenberg

20 16 [7] Wefel, S. Hardware-Crypto-Token gestütztes Single Sign-On für zertifikatsbasierte Authentifizierung [8] Wefel, S. und Molitor, P. Client Hardware-Token Based Single Sign-On over Several Servers without Trusted Online Third Party Server. Communications in Computer and Information Science, Springer Berlin Heidelberg (2009). [9] Wiegleb, S. Smartcard-Schnittstelle für ThinClients Projekt , Martin-Luther-Universität Halle-Wittenberg

21 17 ecampus-services & -Infrastrukturen für eine gesicherte und verbindliche elektronische Hochschulverwaltung Ausführende Einrichtung(en): Hochschule Harz, Hochschule Anhalt Projektleiter: Prof. Dr. Hermann Strack, Hochschule Harz, Friedrichstr , D Wernigerode. zusammen mit: Dr. Nico Brehm, Dipl.-Ing. (FH) Peter Kußmann, Dipl.-Inf. (FH) Martin Henning, M.Eng. Nico Scheithauer, Dipl.-Inf. (FH) Hendrik Werner, Prof. Dr. Volkmar Richter, Hochschule Anhalt, Lohmannstraße 23, D Köthen (Anhalt). E- Mail: zusammen mit M. Sc. Hagen Weise, Förderung: Dieses Vorhaben wird mit Mitteln der Europäischen Kommission aus dem Europäischen Fonds für regionale Entwicklung (EFRE) im Rahmen der Maßnahme 11.03/41.03 gefördert (FKZ: ). Zusammenfassung Im Rahmen des Projekts ecampus Services & -Infrastrukturen für gesicherte und verbindliche vollelektronische Hochschulverwaltungen werden ausgewählte Verfahrenselektronisierungen für Verwaltungsprozesse an Hochschulen untersucht und auf Basis verfügbarer egovernment-standards und -Komponenten umgesetzt. Auf Basis entsprechender Architekturmodelle und unter Integration von innovativen egovernment- und Sicherheitskomponenten (u.a. auf Basis des egovernment- Standards OSCI) soll dabei gewährleistet werden, dass das Kommunikations- und Datenmanagement in den ausgewählten sensitiven Szenarien vollelektronisch umgesetzt und dabei nach Standards nachweisbar abgesichert, datenschutzkonform realisiert und dabei elektronische Dokumente nachweisbar zugestellt und rechtsverbindlich elektronisch signiert werden können. Für alle ausgewählten Fachverfahren werden Realisierungen entwickelt, zum Teil bereits im Realeinsatz. Die Realisierungen basieren dabei auf Architekturmodellen mit unterschiedlichen Integrationsmodi für vorhandene bzw. zukünftige Campusmanagementsysteme (HIS, HISinOne): OSCI-HIS-Access-, OSCI- HIS-Shell- und OSCI-Builtin-Architektur. Die Umsetzung ist dabei modular gestaltet, so dass die Integration in vorhandene Systemumgebungen und Nachnutzung auch an anderen Hochschulen erleichtert wird. Hinsichtlich der Berücksichtigung neuester egovernment-komponenten konnten neben Konzeptentwicklungen ebenfalls bereits Prototyp-Realisierungen umgesetzt werden (über Plan). Die Realisierungen werden umfangreichen Erprobungen und Evaluierungen unterzogen. Keywords: egovernment-basiskomponenten, OSCI, qualifizierte elektronische Signatur (QES), PKI, Verfahrenselektronisierungen, HIS, HISinOne Projekt , Hochschule Harz, Hochschule Anhalt

22 18 1 Projekt ecampus a. Vorhaben Im Rahmen des Projekts ecampus - Services & -Infrastrukturen für gesicherte u. verbindliche vollelektronische Hochschulverwaltungen sollen ausgewählte Verfahrenselektronisierungen für Verwaltungsprozesse an Hochschulen untersucht und auf Basis verfügbarer egovernment-standards und -Komponenten umgesetzt werden. Unter Einsatz von innovativen egovernment- und Sicherheitskomponenten soll dabei gewährleistet werden, dass sensitive Kommunikations- und Datenmanagement-Anteile in den ausgewählten Szenarien nach Standards nachweisbar abgesichert, datenschutzkonform umgesetzt und elektronische Dokumente rechtsverbindlich elektronisch signiert und nachweisbar zugestellt werden können unter Nutzung von Synergien und Kostenentlastungen aus dem Bereich der Umsetzung des egovernment-aktionsplans des Landes Sachsen-Anhalt (LSA). Auf dieser Basis soll die Vision der vollektronischen Verwaltung auch im Hochschulbereich umgesetzt werden. Die egovernment-nutzerkomponenten selbst werden bereits im allgemeinen egovernment der öffentlichen Verwaltung in einem Qualitätssicherungs-Lifecycle gepflegt. Zusätzlich werden in ecampus in Feldversuchen die entsprechenden Realisierungen evaluiert, insbesondere auf Akzeptanz und nutzerfreundliche Handhabbarkeit. b. Betrachtete Fachverfahren Zu den zu betrachtenden ecampus-verfahren gehören: Kürzel Verfahren Kurzbeschreibung etor Prüfungsdatenübermittlung Elektronische Prüfungsdatenübermittlung zwischen Hochschulen (z. Studi.mobilität) eexamreg Prüfungsanmeldungen und -bewertungen Prüfungsanmeldungen (Studierende) u. elektron. Prüfungsbewertungen (Dozenten) ezeugnis Zeugniskopien Elektronische Erstellung und Management beglaubigter elektronischer Zeugniskopien epraxreg Vereinbarungen für Praxissemester Elektronische Anmeldung und Vertragsabschlüsse mit Praxissemesterbetrieben ebafögsch Leistungsscheine für Bafög Elektr. Bafög-Leistungsbescheinigung der Hochschule für Studierende (f. Bafög-Amt) eschein Studentische Bescheinigungen Elektron. Studien-Bescheinigungen u. Bescheide der Hochschule für Studierende Tabelle 1: die ausgewählten Fachverfahren in ecampus Projekt , Hochschule Harz, Hochschule Anhalt

23 c. Genutzte Komponenten Als Kompoenten und Infrastrukturen für die ecampus-realisierungen werden egovernment-basiskomponenten des Landes genutzt, s. Überblick in Tabelle 1 (G2, G3, G5, G6, G8 nach Governikus-Pflegevertrag LSA; G1, G7 als Infrastrukturen/Dienste LSA): 19 egov-id Komponente Beschreibung G1 PKI-LSA Komponenten/Chipkarten für qual./akkred. Signaturverfahren/CA (QES), n. Signaturgesetz SigG G2 OSCI-Intermediär (Governikus) G3 OSCI-Client (Govello/ Governikus Communicator, EGVP) OSCI-Server/-Vermittlungsstelle / zentrale Si.dienste, egov.-standard f. "Einschreiben m. Quitt.", Produkt Governikus (Landespflegevertrag LSA) Client-Software für Governikus-Intermediär, für gesicherte & rechtsverbindliche OSCI-Zustellungen (Landespflegevertrag LSA) G4 Open Limit CC Sign Client-Software für qualifizierte Signaturen (QES) G5 Governikus-Signer Client-Software für qualifizierte Signaturen (QES) G6 Telesignaturserver Automat. "Massensignaturserver" n. SigG (QES) G7 Formular-Server bzw. -Tools G8 Governikus Dyn. Fachdatenschnittstelle Webserver f. Formular-Management (f. interaktive Online-Formulare) / Produkt Adobe LifeCycle (offline Autorisierung) bzw. Adobe Acrobat (online) Dynamische Schnittstelle (Web/FileSystem), für Web-Integration/Parametrisierung für Govello sowie für automat. Übergaben/OSCI-Versendungen G9 PDF-Converter Konvertierungs-Tool: PDF-Formulare/Inhalte nach XML (mit Signatur) Tabelle 2: egovernment-komponenten für den Einsatz in ecampus d. Kooperationen Als Projektpartner und Durchführende sind die Hochschule Harz und die Hochschule Anhalt mit je einer Arbeitsgruppe beteiligt. Die Arbeitsgruppen konzentrieren sich dabei entsprechend der Projektplanung arbeitsteilig auf die Analyse von relevanten Hochschulprozessen, den Entwurf und die Realisierung entsprechender Anwendungen auf Basis der Integration von Sicherheits- und egovernment-komponenten bzw. Standards und auf entsprechende Erprobungen und Evaluierungen. Für die ausgewählten relevanten Verfahrenselektronisierungen werden dabei als Basis dieser Anwendungsrealisierungen wiederverwendbare und integrationsfähige Architekturentwicklungen angestrebt (bzgl. vorhandener und zukünftiger Campusmanagementsysteme (HIS / HISinOne)). Projekt , Hochschule Harz, Hochschule Anhalt

24 20 2 Konzeption der ecampus-verfahren 2.1 Kriterien für die Konzeption Vor dem Hintergrund des Zielspektrums ecampus wurden Kriterien für entsprechende Konzeptionen und Umsetzungen entwickelt. Da personenbezogene Daten und insbesondere Prüfungsdaten zu den wertvollsten und schützenswertesten elektronischen Daten überhaupt an Hochschulen gehören, u.a. da diese Daten auch Einflüsse auf ganze Lebensläufe nehmen könnnen, wurden kriterienorientiert entsprechende Anforderungen an Sicherheit, Vertrauenswürdigkeit und Integrationsfähigkeit für einzusetzende Systeme entwickelt. In diesem Zusammenhang zeigte sich ein Sicherheitsdefizit einfacher (passwort-basierter) Schutzsysteme im Bereich web-basierter Campusmanagementsysteme für den Hochschuleinsatz, speziell bei einfachen Single-Sign-On- Lösungen für den Zugang von Dozenten zum Prüfungsdatenmanagement: die vertraulichen Passworte/Credentials müssen immer wieder in offenen, leicht ausspähbaren Umgebungen eingesetzt werden. Die ausgewählten Kriterien: K1 Sicherheitsziele (Verbindlichkeit, Vertraulichkeit, Integrität, Authentizität), K2 Rechtsverbindlichkeit/Signatur von elektr. Dokumenten, K3 Datenschutzkonformität, K4 Nachweisbarkeit von Dokumenten-/Nachrichten-Zustellungen (Verbindlichkeit), K5 Nutzerentlastung bzgl. Signatur- & PKI-Prüfungen, K6 Nutzung von Internet-Standards (u.a. XML/SOAP), K7 Integration von XML und (Verwaltungs-/eGovernment-)Standards, K8 HIS-Integration, K9 Kosteneffektive Nachnutzbarkeit von egov.-komponenten & Wartung, K10 Vertrauenswürdigkeit von Komponenten & Services, K11 Handhabbarkeit, K12 Kosten-Nutzen-Analysen. 2.2 Einsatz der egovernment-komponenten Projekt , Hochschule Harz, Hochschule Anhalt

25 Hinsichtlich Umsetzungen von relevanten Sicherheitsaspekten stehen egovernmentund Sicherheits-Standards wie OSCI und PKI nach Signaturgesetz (QES) mit wiederverwendbaren Komponenten zur Verfügung: Rechtsverbindlichkeit für Dokumente (QES) und deren Zustellung/Datenschutz (OSCI) Hochwertige Sicherheit sowie Vertrauenswürdigkeit für die Signaturstufen Qualifizierte Signatur (QES) und Akkreditierte (qualifizierte) Signatur (AKQES). OSCI (Online Service Computer Interface) ist in Verwaltungen und Wirtschaft auch für Massenverfahren im Einsatz (z.b. im Meldewesen) und ermöglicht die abgesicherte und rechtsverbindliche (nachweisbare) Zustellung von Nachrichten zwischen den Teilnehmern. So bildet OSCI das Verfahren Einschreiben mit Rückschein elektronisch ab, in dem nachweisbare Zustellungen durch das Erzeugen von sogenannten Laufzetteln (signiert durch den OSCI-Intermediär) für jeden OSCI-Nachrichtenaustausch durchgeführt werden. Mittels OSCI wird u.a. durch Ende-zu-Ende-Verschlüsselungen und Signaturen sichergestellt, dass Vertraulichkeit, Integrität und Authentizität personenbezogener Daten bei der Übertragung über unsichere Netze, wie dem Internet, gewährleistet werden können. Daher wird OSCI auch entsprechend von der Konferenz der Datenschutzbeauftragten von Bund und Ländern empfohlen [4]. Für die Standards PKI/QES und OSCI können wesentliche egovernment-basiskomponenten LSA im Projekt ecampus zur Verfügung gestellt werden: PKI LSA, die OSCI-Clients Govello/Governikus Communicator und EGVP, OSCI-Intermediär (Server)/Governikus, vgl. [LDVK2010]. Mittels OSCI und vorgenannter egovernment- Basiskomponenten können, maßgeblich Anforderungen und Ziele aus Kapitel 2, mittels folgender Sicherheitsfunktionen, erfüllt werden: 21 Funktionen Integrität Nichtabstreitb arkeit Ziele Si- Vertraulichkeit Authentizität Zurechenbarkeit/Verbindlichkeit Verschlüsselung Entschlüsselung Signatur Signaturprüfung Zertifikatsprüfung Zeitstempel Laufzettel/Quittierung Benutzerauthentisierung Nachrichten-IDs Tabelle 3: OSCI - Gegenüberstellung Sicherheitsziele und Sicherheitsfunktionen Im Vergleich zum Kriterienkatalog (s. Tabelle 2) ergibt sich damit das OSCI für das Erreichen der Sicherheitsziele geeignet ist. Hinsichtlich der Integrationsfähigkeit von Basiskomponenten, Standards und Diensten lassen sich vier grundsätzliche Architekturansätze aufzeigen, mit denen sich entsprechende Integrationen von zusätzlichen (OSCI-)Sicherheitsfunktionen in ein ecampusmanagement-systeme (wie HIS) umsetzen lassen (vgl. Strack/Richter et.al [20]): A1: OSCI-Access-Architektur Projekt , Hochschule Harz, Hochschule Anhalt

26 22 A2: OSCI-Schalen-Architektur A3: Builtin-Architektur A4: SOA-eCampus-Architektur. Die Built-In-Architektur verfolgt dabei den Ansatz, dass die für das Projektumfeld notwendigen (OSCI-)Sicherheitsfunktionalitäten und -techniken direkt in das ecampus- System integriert werden (wie z.b. zukünftig in HISinOne), die SOA-eCampus- Architektur als deren Spezialfall berücksichtigt dabei zusätzlich SOA/WebService- Standards auch außerhalb von OSCI. Die Schalen-Architektur hingegen ist dadurch gekennzeichnet, dass durch die zusätzliche schwachstellen-abschirmende Einbindung von bestehenden egovernment-(osci)komponenten existierende ecampus-systeme um zusätzliche Sicherheitsschalen auf OSCI-Basis ergänzt werden ("minimal invasiv" bzgl. der Eingriffe in vorhandene Campus-Systeme), z.b. zum OSCI-Ersatz schwachstellenbehafteter Eingabe-Schnittstellen auf Web-Basis (http/ssl) für dann gesicherte und automatisierte elektr. Prüfungsdateneintragungen in herkömmlichen ecampus- Systemen. Bei der OSCI-Access-Architektur wird hierbei dagegen nur die Anlieferung der Daten / der Zugang per OSCI-Weg ersetzt, ohne automatisierte Eintragungen. 2.3 ecampus-konzeption und Umsetzung - Beispiel eexamreg Beispielhaft werden die ecampus-architekturen und -Umsetzungen im folgenden für das sensitive und komplexe Fachverfahren eexamreg aufgezeigt, die weiteren ecampus-verfahren (s. Tabelle 1) lassen sich in ähnlicher Weise umsetzen, vgl. [21] Prozessanalyse (bisherige Abläufe) Folgende Abbildung veranschaulicht den bisherigen Vorgang der Prüfungsbewertung: Projekt , Hochschule Harz, Hochschule Anhalt

27 Folgende Risiken und Schwachstellen sind im zuvor dargestellten bisherigen Ablauf beispielhaft erkennbar (es gibt weitere): 1) Gefälschte Prüfereintragungen bzw. Überschreibungen valider Prüfereintragungen bei Online-Prüfungsbewertungen auf Basis von einfachen Nutzername- Password-Authentifikationsverfahren für entsprechende webbasierte Prüfungssysteme (selbst bei einseitiger SSL-Server-Absicherung, wie üblich). 2) Entwendung von Nutzername-Password ist (sogar ohne spezielle IT-Kenntnisse) im organisatorischen Umfeld von Hochschuldozenten leicht möglich (auch bei innovativen SingleSignOn-Verfahren ohne Nutzerzertifikate; weitere Risiken bei noch z.t. üblichen Klartext-Passwort-Haltungen). Auch bei der Übertragung auf Einsatzszenarien für studentische Prüfungsanmeldungen können ähnliche Risiken bzgl. Verbindlichkeit durch die herkömmliche elektronische Datenhaltung und deren Sicherungen bei Online-Anmeldungssystemen entstehen. Aus solchen Gründen wurden bisher häufig ergänzende aufwendige organisatorrische Zusatzregelungen getroffen (ggf. unter Einbindung von "Papierwegen"), als zusätzlicher Vertrauensanker. Beim bisherigen Ablauf des Verfahrens gibt es folgende Problematiken und Herausforderungen: Vielzahl von Medienbrüchen, Echtheit beteiligter Dokumente, Datenschutz bzgl. der Übersendung, Vielzahl an Übertragungswegen, Notenübermittlung aufwendig, da auf doppeltem Wege (zusätzlich "per Papier"). Vorgenannte Problematiken und Herausforderungen können durch den Einsatz von Signatur- und OSCI- Infrastrukturen/-Tools vollelektronisch gelöst werden (vgl. Kriterien aus Abschnitt 3.1). An dem entsprechend neu-modellierten Verfahren der Online-Prüfungsbewertungen sind weiterhin die bisherigen Akteure beteiligt. Änderungen finden hinsichtlich des Vorgehens und dem Einsatz genutzter Komponenten/Anwendungen statt. Auf der Seite des Dozenten werden im Szenario nunmehr keine Noten über das Webinterface des Online-Systems eingetragen (als Formularvorlage können Leerformulare jedoch weiterhin über das Web heruntergeladen werden). Der Dozent bereitet nun die Daten lokal formularbasiert auf (z.b per Excel-, PDF- oder XML-Format) und verschickt diese rechtsverbindlich und elektronisch signiert (QES). Dies geschieht unter Nutzung des PKI-Arbeitsplatzes und dessen Anwendungen für qualifizierte Signaturen. Hierzu werden Signaturerstellungssoftware und entsprechende Programme zur Darstellung von Dokumenten zur Signaturerbringung verwendet. Mittels OSCI-Client wird das unterzeichnete Dokument als OSCI-Anhang abgesichert und rechtsverbindlich vom Dozenten an zuständige Stellen des Prüfungsamts nachweisbar zugestellt. Für die Entgegennahme der OSCI-Zustellungen samt Gültigkeitsprüfungen im Prüfungsamt gibt es sowohl interaktive persönliche Szenarien (Mitarbeiter mittels OSCI-Client, Access- Architektur) als auch automatisiert umsetzbare Szenarien (OSCI-Export im Batch, Schalen-Architektur). Daraufhin wird diese OSCI-Nachricht (inkl. Noten-Anhang) ins Dateisystem (auch ggf. in automatisierter Variante) exportiert. Ein Adapter für die HIS- Software nimmt den so abgelegten Anhang entgegen, entnimmt die Einzelnoten und trägt diese exklusiv geschützt in das (bisherige) HIS-System ein (Shell-OSCI-HIS- Projekt , Hochschule Harz, Hochschule Anhalt 23

28 Architekturvariante) oder aber übernimmt die signierten Daten in eine angepasste HIS- Architektur (Builtin-OSCI-HIS-Architekturvariante), jeweils nach erfolgreicher (automatischer) Prüfung der auf dem Anhang/Dokument jeweils angebrachten Signatur. Beim Generieren sowohl von herkömmlichen papiergebundenen Zeugnissen oder Leistungsbescheinigungen als auch von deren elektronischen Varianten können diese signierten Daten in diversen Formen für Validierungen eingesetzt werden. Die folgende Abbildung veranschaulicht den neu-modellierten Vorgang der Prüfungsbewertung (inkl. Mehrwerte u.a. bei der Prüfung und Aufbereitung von Daten): Überblick Architektur, HIS-Integration und Umsetzungen Das Szenario zur Umsetzung der Verfahrens der Prüfungsbewertungen kann mittels zweier OSCI-Umsetzungsansätze realisiert werden: einer Komponenten- oder einer Bibliotheks-basierten OSCI-Integarationsvariante. Die angedachte Prototyp-Implementierung Komponenten nutzt dabei durchgängig die vorhandenen OSCI-relevanten Basiskomponenten zur Umsetzung: die OSCI- Infrastruktur als Grundlage für die abgesicherte, rechtverbindliche Kommunikation, den Client Govello/Goernikus Communicator bzw. EGVP mit entsprechend eingerichteten Postfächern für die Teilnehmer zur Übermittlung von Daten, sowie dessen konfigurierbare Optionen für automatischen Export bzw. die Übergabe von Daten per Dateisystem. Für die Übernahme von Prüfungsbewertungen in das Hochschulinformationssystem (HIS) ist die Interaktion der beteiligten Akteure notwendig sowie ein zu entwickelnder "Mediator"-Adapter, welcher den eigentlichen Vorgang der rechtsverbindlichen und qualifizierten Dokumentensignatur-Prüfung und der Übernahme der Prüfungsbewertungsdaten in das web-basierte HIS-System anstößt bzw. durchführt. Die Bibliotheksversion unterscheidet sich von der vorhergehenden dahingehend, dass statt separater vorhandener OSCI-Programmkomponenten dann OSCI-Bibliotheks- Projekt , Hochschule Harz, Hochschule Anhalt

29 funktionen in eigenprogrammierte Anwendungen integriert werden (höherer Entwicklungs-Aufwand) ecampus-entwurf, Realisierungen, Tests und Einsätze Im Folgenden werden Komponenten, Entwürfe und Realisierungen bzw. Realisierungsschritte/Stati sowie Tests und Einsätze zu den drei ecampus-architekturen (OSCI-Access-HIS, OSCI-Shell-HIS, OSCI-Builtin-HIS, s. [20]) und den sechs -Fachverfahren vorgestellt, sowie erste Auswertungen dazu. Zur Architektur-Übersicht: OSCI-Access-HIS (für Papierersatz + manuelle Zustellungen z.b. f. Prüfg.amt) OSCI-Shell-HIS (PKI/OSCI Sicherheitsschale, "minimal invasiv für HIS) OSCI-Builtin-HIS (Integration von PKI/OSCI für HIS/HISinOne). Im Kurzbericht hier können nur zusammenfassend ausgewählte Realisierungsausschnitte vorgestellt werden, dabei hier zu den komplexen Verfahren/Infrastrukturen zu eexamreg und ebafögsch. Die in diesen beiden Verfahren eingeführten generischen ecampus-komponenten und Vorgehensweisen werden ähnlich in den anderen vier ecampus-verfahren wiederverwendet. Zusammenfassend kann bereits jetzt hier von sehr erfolgreichen Realisierungen für alle Verfahren berichtet werden, insbesondere zum Teil bereits in Realbetrieb an der Hochschule Harz. Die Stati der Fertigstellungen der Umsetzungen reichen dabei derzeit von "Fertig/in Real-Betrieb" über "Fertig/im Test" bzw. "Prototyp" bis "Prototyp in Entwurf/Erstellung", wobei erfreulicherweise die aufwändigsten Implementierungs- Teilaufgaben, insbesondere für zentrale generische Komponenten und Infrastrukturen (wie Mediator, OSHC) als mächtige wiederverwendbare System- und Komponentenbasis für verschiedenste Fachverfahrens-Elektronisierungen bereits absolviert sind. In diesem Zusammenhang kann weiter vom erfolgreichen Abschluss eines HISinOne- Entwicklungspartnervertrages zwischen Hochschule Harz/Projekt ecampus und der HIS GmbH berichtet werden. 3.1 Realisierung der OSCI-Access-HIS-Architektur (Prüfg.amt) Für "manuelle" elektronische Prüfungsdatenaustausche zwischen Dozenten und Prüfungsamt mit integrierter Sicherheit (OSCI, PKI), die später dann in der Schalen- sowie Builtin-Architektur bzgl. HIS-Eintragungen automatisiert werden, werden in der Access- Architektur "manuelle" Nutzungen der OSCI/PKI-Tools/Clients und damit verbundenen Tools eingesetzt. Damit ist das Einsatzszenario im Wirkbetrieb hier sinnvollerweise nur für explizit notwendige manuelle Übermittlungen vorgesehen (z.b. für den Ersatz von Papiersendungen (Anforderung Prüfg.amt) oder für Zustellungen von Nachprüfungsergebnissen "ausser der Reihe"), nicht dagegen für Massendaten-Eintragungen in HIS (für solche "Massen-Fälle" sind dann die Shell-/Builtin-Architekturen vorgesehen). Projekt , Hochschule Harz, Hochschule Anhalt

30 Ausgewählte Dozenten sowie das Prüfungsamt der Hochschule Harz sind zunächst als hauptsächliche Anwender innerhalb der Fachfahren des ecampus-projektes mit Prüfungsdateneintragungen vorgesehen und sind somit Pioniere für die Erprobung verschiedener Abläufe, zunächst mittels Access-Architektur. Als Grundlage diente dabei das Fachverfahren eexamreg. Nach dem Basis-Rollout der egovernment-infrastruktur, einem folgenden Workshop für die Prüfungsamtsmitarbeiterinnen sowie der Vorstellung der Access- sowie Shell/Builtin-Architekturzugänge im Fachbereich Automatisierung und Informatik (AI) erfolgte eine erste Umsetzung des Fachverfahrens eexamreg mittels Access-Architektur bei FB AI und Prüfungsamt an der Hochschule Harz. Hierbei reichten Dozenten des FB AI Prüfungsergebnisse zu Prüfungen durch Nutzung von egovernment-basiskomponenten, insbes. OSCI und PKI LSA, mittels entsprechender Tools beim Prüfungsamt ein. Nach der Umsetzung der Access-Lösung im Prüfungsamt und ersten erfolgreichen Prüfungsdatenzustellungen per OSCI waren zusätzliche Integrationsanpassungen zu leisten. Bereits im Vorfeld, bei Diskussionen mit dem Prüfungsamt, hat sich gezeigt, dass die Überführungen von der Access-Architektur zur Schalen-Architektur (und später auch Builtin-Architektur) nicht nur wegen der Mehrwerte hinsichtlich Sicherheitsfragen begrüßt werden, sondern insbesondere auch wegen der Automatismen bzgl. Prüfungsdaten-Einspeicherungen in HIS-System, mit entsprechend favorisierten Arbeitserleichterungen für das Prüfungsamtspersonal (manuelle Entlastung bzgl. HIS-Einträgen und Papierverkehr). Für eine angedachte Massenumsetzung im Regelbetrieb wurden einerseits diese Automatismen (OSCI-Shell-HIS), als auch parallel die gesicherte vollelektronische Zusendung der vom Dozenten rechtsverbindlich qualifiziert signierten finalen elektronischen Prüfungsdokumente zum Vergleich mit den HIS-Einträgen und zur entsprechenden Prüfungsamtsfinalisierung des Prüfungsvorgangs (insbes. bzgl. Fällen von fehlenden Prüfungsteilnehmern mit Krankheitsbescheinigungen) Übersicht: Realisierung der OSCI-Shell-HIS-Architektur (RZ) Die in Kapitel grundlegend vorgestellte Schalen-Architektur (OSCI-Shell-HIS), welche es ermöglicht, das HIS-System um die im Projektumfeld notwendige Sicherheitsfunktionalität vorhandener egovernment-basiskomponenten zu ergänzen, wurde wie im folgenden beschrieben in verschiedenen Entwicklungs- und Testumgebungen in einem mehrstufigen Test- und Rollout-Verfahren realisiert und erfolgreich auf eine (virtuelle) ecampus-serverumgebung im RZ der Hochschule Harz migriert, vorgesehen dann nach weiteren Test/Freigaben für ausgewählte Realeinsätze. 3.3 Übersicht OSCI-Shell-HIS-Architektur (RZ-Migration) Zentrale Komponenten sind insbesondere folgende fünf Server, welche einen Großteil der notwendigen Funktionalität zur Umsetzung der Architektur bzw. der ecampus- Verfahren erbringen und bereitstellen: Projekt , Hochschule Harz, Hochschule Anhalt

31 27 HIS-Server, OSCI-Intermediär, ecampus-server Mediator, ecampus-registry. Der HIS-Server stellt dabei wie gehabt die Funktionalität des hochschulweit eingesetzten HIS-Systems zur Verfügung. Der OSCI-Intermediär stellt das Herzstück der OSCI-Infrastruktur dar. Als zentraler Vermittler bei der OSCI-Kommunikation sorgt er im Umfeld der Schalen-Architektur für datenschutzkonforme und rechtsverbindliche Zustellungen von Verfahrensdaten - zusammen mit den OSCI-Clients auf Nutzerseite. Der ecampus-server bietet ein zentrales Hosting für Applikationen für Nutzer der ecampus-verfahren in Form eines Webportals an. Dieses stellt dabei dem Nutzer der ecampus-anwendungen einen zentralen markanten Einsprungspunkt zur Verfügung und ermöglicht darüber hinaus den webbasierten Zugriff auf Verwaltungswerkzeuge der einzelnen ecampus-verfahren. Der Mediator hat eine Mittlerfunktion zwischen der OSCI-Anlieferung von sensitiven Daten auf der einen Seite und auf der anderen Seite der geeigneten Übertragung der Daten (nach entsprechenden Sicherheitsprüfungen) in eine exklusiv im RZ bereit gestelltes und geschütztes HIS-Webformular. Dabei erbringt der Mediator notwendige (Sicherheits-)Funktionen, Operationen und Mehrwertdienste für ecampus-verfahren (z.b. Auswertung von Signaturprüfungen, eid-mapping zwischen qualif. Zertifikatsebene und UID im Hochschulsystem für Dozenten). Die ecampus-registry ist ein Registry-Service zur Aufnahme von eid-daten (u.a. bzgl. QES und UID des RZ) der ecampus-verfahrensteilnehmer. Der Mediator arbeitet gesichert mit der Registry zusammen, um seine Mehrwertdienste für die ecampus-verfahren erbringen zu können. Das Zusammenspiel der vorgestellten Komponenten sorgt dabei zum einen für die Umsetzung der Shell-Architektur (OSCI-HIS-Shell) zur Integration von Sicherheitsfunktionalität, zum anderen für eine einheitliche Plattform für Zugang und Nutzung der ecampus-verfahren relativ zu HIS (Push- und Pull-Datenflüsse). In der folgenden Abbildung wird die Umsetzung der OSCI-HIS-Architektur grundlegend dargestellt: Erkennbar ist dabei insbes. das gesicherte Zusammenspiel aller Komponenten inkl. der Beteiligung der Nutzer im Verfahrensrahmen, die exklusive Einbettung einzelner Komponenten in das geschützte Umfeld des Rechenzentrums als notwendige Randbedingung für deren sicherheitskritische Funktionalität, sowie der Einsatz von egovernment-komponenten zur Umsetzung von Projektzielen bzgl. Shell-Architektur. Projekt , Hochschule Harz, Hochschule Anhalt

32 28 Nutzer Rechenzentrum Webportal everfahren Dozent HTTPS FW HTTPS FW ecampus-server ecampus-registry HTTPS Netzwerklabor FW Pull (eschein) Mediator HTTPS OSHC-Mediator LSF - QISPOS Push (eexamreg) OSCI-Intermediär (inkl. Telesignatur) HIS-Server Bild 1: Realisierung OSCI-Shell-HIS-Architektur (nach Migration zum RZ) 3.4 Realisierung der OSCI-Shell-HIS-Architektur (RZ) Nachfolgend wird das generische Konzept zur Realisierung und Nutzung der OSCI- Shell-HIS-Komponente (OSHC) zur Umsetzung einer OSCI-Shell-HIS-Lösung für beliebige Fachverfahren beschrieben. Dazu werden sowohl allgemeine Abläufe einer Interaktion zwischen Nutzer und HIS-System für eine OSCI-Shell-HIS-Lösung veranschaulicht als auch die Komponentenstruktur der OSHC dargestellt, als auch die intern verwendeten Teilkomponenten und deren Relation untereinander beschrieben Nutzungsverlauf einer OSCI-Shell-HIS-Lösung (allg.) Bei der Kommunikation sind die drei Instanzen (Client, OSHC und HIS) beteiligt. Im ersten Teilbereich des Kommunikationsprozesse (vgl. Bild 3) werden die an das HIS zu übertragenden Daten vom Client (Person) in einer Datei von einem zuvor für den jeweiligen Anwendungsfall festgelegten Typ (z.b. Excel- Dokument) abgelegt und anschließend qualifiziert digital signiert. Darauf aufbauend verfasst der Client eine OSCI-Nachricht mit Hilfe eines zuvor beim Client installierten OSCI-Client-Programms (z.b. Governikus Communicator). Diese OSCI-Nachricht beinhaltet das zuvor signierte Dokument inkl. der zugehörigen Signatur. Diese OSCI- Nachricht (Anfragenachricht) wird anschließend an die OSHC gesendet. Die OSHC übernimmt die Aufgabe des Bearbeiters des betreffenden Fachverfahrens. Nach Empfang der OSCI-Anfragenachricht werden die fachverfahrensspezifischen Daten extra- Projekt , Hochschule Harz, Hochschule Anhalt

33 hiert und auf Vollständigkeit und die fachverfahrensspezifische Korrektheit geprüft (einschließlich Signaturprüfung). Im Fehlerfall wird eine OSCI-Nachricht mit der Fehlerbeschreibung an den anfragenden Client zurückgesendet. Ggf. wird zusätzlich eine OSCI-Nachricht mit der Fehlerbeschreibung an den zuständigen Administrator gesendet. Im Normalfall (kein Fehlerfall) werden die gesendeten Daten in ein Format transformiert, das sich für die HTTP-basierte Übertragung an das HIS eignet. Anschließend werden die Daten per HTTPS-Verbindung an das HIS übertragen. Für die Verbindung zwischen OSHC und HIS wird eine HTTPS-Nutzer-Session (inkl. HTTPS-Login) analog der browserbasierten Kommunikation mit dem HIS aufgebaut. Nach Abschluss der Datenübertragung zum HIS wird eine Erfolgsmeldung per OSCI-Nachricht an den anfragenden Client übermittelt. Im Fehlerfall wird eine OSCI-Nachricht mit der Fehlerbeschreibung an den Client und eine detaillierte Fehlerbeschreibung an den Administrator gesendet (ebenfalls als OSCI-Nachricht) Modulare Komponentenstruktur für OSCI-Shell-HIS In Bild 2 ist die modulare Komponentenstruktur der OSHC dargestellt. Das Teilsystem besteht aus acht Teilkomponenten. Weiterhin nutzt das Teilsystem eine Schnittstelle zu einem OSCI-Server sowie eine weitere Schnittstelle zum HIS-Server (Modul "HIS Procedure Operator" als exklusiven "HIS-Webadapter"), sowie weitere Schnittstellen für die Benutzer-Kommunikation. OSCI-Shell-HIS Component (OSHC) OSCI Message Handler HIS Procedure Manager Remote- File-System HIS Procedure Archive Mediator (exchange via file system) <<Interface>> HIS Procedure Operator OSCI-Server Governikus Communicator (OSCI-Client) HIS HTTP Client HIS-Server (HTTP) Bild 2: Komponentenstruktur der OSCI-Shell-HIS-Komponente Lösungsansatz eexamreg Projekt , Hochschule Harz, Hochschule Anhalt In Bild 3 sind zunächst die Schritte zur Übermittlung von Notenlisten an das Prüfungsamt dargestellt. Im Anwendungsfall hier werden Notenlisten im HIS-Excel-Format pro Prü-

34 fung vom Prüfer editiert (alternativ später möglich: PDF-Dokumente). Eine ausgefüllte Notenliste wird vom Prüfer qualif. signiert und inkl. des Signaturanhangs als Attachment einer OSCI-Nachricht an das Prüfungsamt versendet. Die Notenliste wird anschließend geprüft und durch die Komponente OCSI-HIS-Mediator in das bereits bestehende HIS (Webanwendung) zur Notenverwaltung übertragen. 30 Bild 3: OSCI-Shell-HIS: Schritte/Komponenten für automat. Notenzustellungen Projekt , Hochschule Harz, Hochschule Anhalt

35 31 POS / HIS Bild 4: ExamReg: Kommunikationsszenario aus technischer Sicht Bei der Kommunikation sind die drei Instanzen (Client, OSHC und HIS) beteiligt. Der grundlegende Ablauf der Kommunikation orientiert sich am generischen Konzept der Nutzung einer OSHC-Mediatorkomponente mit RZ-lokalem/exklusivem Zugriff auf HIS. Mediator-Autorisierung Für die Umsetzung einer Autorisierungslösung bzgl. der Mediator-Komponente existieren drei vorstellbare alternative Ansätze (unter Bedingungen einer möglichst "minimal invasiven" HIS-Integration). Jede der drei Alternativen HIS-Admin., ecampus-regristry, Mediator-Stellvertreter betrachtet das Problem zur Übertragung von Authentisierungen bzw. Zugriffberechtigungen von tatsächlichen HIS-Usern auf den Mediator, der Operationen im Auftrag des betreffenden Nutzers ausführt. Aktuelle Varianten-Entscheidung an der Hs Harz (mit RZ): Aufgrund der Bestrebung zur Minimierung des administrativen Aufwands auf HIS-Seite wird nach ausführlicher Diskussion mit dem RZ der Hs Harz für die Einführung einer ecampus-lösung die zweite Variante (ecampus-regristry) zur Weiterverarbeitung empfohlen. Der Zugang zur exklusiven HIS-Formulareintragung für den Mediator ist auf dieser Basis hochwertig zusätzlich auf PKI/QES-Basis abgesichert. Projekt , Hochschule Harz, Hochschule Anhalt

36 3.5 eexamreg-variante etestat: pseudonymisierte und authentisierte Labortestate - mit npa-option (neuer Ausweis) Beteiligt an dem Alt-Verfahren der Erstellung und Einreichung pseudonymisierter und authentisierter elektronischer Labortestat-Listen für die Bewertungen von Laborpraktika sind: am Praktikum teilnehmende Studierende, der das Laborpraktikum leitende Dozent sowie das Prüfungsamt. Initiatoren des Vorgangs sind die Dozenten. Für die Bewertung von Laborpraktika wird in einem ersten Schritt die Anwesenheit der Studierenden während der Laborpraktika erfasst auf vom Dozenten herausgegebenen Teilnehmerlisten (in Papierform). Die Studenten werden dabei mit Namen und unummer auf Papier erfasst. Später werden auf den Teilnehmerlisten aufbauend auch die entsprechenden erreichten Labortestat-Ergebnisse vermerkt (mit Dozentenunterschrift). Möchte nun ein Dozent die Testat-Ergebnisse in ein für die Übertragung zum Prüfungsamt vorgesehenes Format eintragen, muss dieser eine Zuordnung zwischen den unummern/klarnamen der Teilnehmerlisten und Matrikelnummern der Studierenden vornehmen. Dies entspricht aber nicht der allgem. Datenschutz-Policy-Empfehlung an der Hochschule Harz. Um jedoch zu einer für das Prüfungsamt geeigneten Darstellung gelangen zu können, werden die während der Laborpraktika angefertigten Teilnehmerlisten derzeit gesondert aufbereitet und manuell in Matrikelnumer-orientierte Labortestat-Listen überführt (enthalten lediglich noch Matrikelnummer-Testat-Paare). Abbildung 5 veranschaulicht den bisherigen Vorgang. 32 Labor-PCs Datenbank Applikationsserver Teilnehmerlisten Prüfungsamt Testat-Ergebnis-Liste Dozent Bild 5: Überblick Prozessanalyse Labortestate (bisherige Abläufe) Überblick eprozess-redesign etestate (mit egov-komp.) An dem neumodellierten Verfahren sind weiterhin die bisherig Involvierten beteiligt. Änderungen finden sich dabei hinsichtlich Art und Einsatzes genutzter Komponenten/Anwendungen auf, mit denen die Kommunikation abgewickelt wird. Der Dozent bleibt die den Vorgang initiierende Person. Dieser gibt jedoch nicht mehr eine papierorientierte Teilnehmerliste zur Feststellung der Anwesenheit von Studenten an Laborpraktika heraus. Der Vorgang wird nun elektronisch über die Anmeldung der Projekt , Hochschule Harz, Hochschule Anhalt

37 Studenten an einer Web-Anwendung durchgeführt - optional auch mittels npa oder anderer Hochschulkarten (vgl. LDVK-Projekt Molitor/Wefel: Chipkarten-basiertes SSO, Uni. Halle). Hierfür wurde eine etestat-web-anwendung auf dem ecampusserver eingerichtet, welche die entsprechenden Mehrwertdienste anbietet. Nachdem der Dozent den Zugriff auf Anmelde-Rechner im Labor freigeschaltet hat, können sich die Studierenden anmelden. Basierend auf diesem Vorgang wird sogleich eine jeweils aktuelle Namen-/uNummern-basierte Teilnehmerliste durch die besagte Web-Anwendung generiert. Nach Veranstaltungsende kann der Dozent - ebenfalls über die etestat-web- Anwendung - die Bewertung der abgeleisteten Laborpraktika der Studierenden in einem entsprechenden Webformular vornehmen. Dabei können vom Dozenten die für das Prüfungsamt vorgesehenen Labortestat-Dateien erzeugt sowie vollelektronisch und rechtsverbindlich elektronisch signiert werden (allerdings jetzt noch Namen- /unummerr-orientiert). Diese signierten Labortestat-Dateien werden in Folge vom Dozenten per OSCI gesichert und datenschutzkonform an einen automatisierten U-M- Konverter zugestellt (im RZ), der die unummer/klarnamen-einträge jeweils durch die Matrikelnummer datenschutzkonform ersetzt (exklusiver RZ-LDAP-Zugriff), diese dann einem automatisierten Telesignatur-Server für die qualifizierte elektronische Signierung zuleitet und die Testat-Prüfungsdaten dann automatisiert per OSCI gesichert und datenschutzkonform an das Prüfungsamt und das HIS-Prüfungssystem per OSCI-Shell- HIS-Architektur zustellt. Abbildung 6 veranschaulicht den neu elektronisierten Vorgang. 33 Registrierungs-PC Autom. Eintragung HIS-Server Prüfungsamt (Prüfung bei Bedarf) etestate-server Testat-Verwaltung Dozent OSCI-Intermediär OSHC-Mediator U-M-Konverter Telesignatur-Server Bild 6: Überblick eprozess-redesign etestate (mit egov-komponenten wie npa) etestate: Überblick zu Architektur und Realisierungen Zur Umsetzung des vorgestellten Szenariums bietet sich der Einsatz von egovernment-basiskomponenten an. Dies sind insbesondere die PKI-Arbeitsplätze, Projekt , Hochschule Harz, Hochschule Anhalt

38 die OSCI-Infrastruktur sowie OSCI-Clients sowie die Komponente Telesignaturserver - optional auch der neue Personalausweis (npa) sowie die für die Nutzung der eid- Funktion notwendige eid-infrastruktur. Die PKI-Arbeitsplätze ermöglichen dabei die vollelektronische und rechtsverbindliche elektronische Signatur von Teilnehmerlisten, die OSCI-Infrastruktur sowie die zugeordneten Clients, dass der Transport zwischen den Akteuren des Verfahrens automatisiert gesichert und datenschutzkonform erfolgt. Die Zustellung von Matrikelnummer-Listen an das Prüfungsamt und dessen Prüfungssystem erfolgt dabei mittels der im ecampus-projekt entwickelten Komponenten OSCI- HIS-Mediator (vgl. Konzept der OSCI-HIS-Shell-Architektur und Realisierungen zu eexamreg), wobei der Mediator um eine Zusatzkomponente U-M-Konverter zur geschützten Umkonvertierung von namen/unr-orientierten Testatlisten in matrikelnrorientierte Testatlisten dient. Der neue Personalausweis (npa) und dessen eid- Funktion gewährleisten die Authentifizierung/Identifizierung von Studenten. Abbildung 7 veranschaulicht die Architektur bzgl. der Finalisierung und Übersendung von pseudonymisierten Labortestat-Listen (u. Einbeziehung von Detailkomponenten wie U-M-Konverter etc.): 34 eid-server SAML-Request/-Response Authentisierungs- Formular https LDAP-Server RZ-Automat inkl. U-M-Konverter Dozenten-Rechner https Testat-Verwaltung OSCI-Intermediär https Web-Server Prüfungs-Amt U-M-Konverter Telesignatur-Server OSCI-HIS-Mediator HIS-System Dateisystem Datenbank Bild 7: Überblick Architektur und Realisierungen etestate Realisierungen etestate Der Mediator wurde um eine matrikelnr-orientierte etestat-schnittstelle für entsprechende HIS-Einträge ergänzt. Projekt , Hochschule Harz, Hochschule Anhalt

39 Zur Umsetzung der etestat-verwaltung mit npa-testausweisen der Bundesdruckerei (für Familie Mustermann) und eid-services des Partners bremen online services (bos) wurde ein Prototyp entwickelt mit Unterstützung durch ein studentisches Teamprojekt (npa-teamprojekt PSC 2011), der das Szenarium entsprechend als Prototyp lauffähig umsetzt. Entwicklungstechnische Nachbearbeitungen und Erweiterungen durch das ecampus-team werden momentan durchgeführt Realisierungsstand ebafögsch Überblick Prozessanalyse (bisherige Abläufe) Beteiligt an dem Verfahren Beantragung/Ausstellung von Bafög-Leistungsscheinen sind Studenten, Mitarbeiter des Prüfungsamts sowie die Bafög-Beauftragten der Fachbereiche und die Mitarbeiter des zuständigen Bafög-Amts. Initiatoren des Vorgangs sind Bafög-berechtigte Studierende beim zuständigen Bafög- Beauftragten. Die Studierenden haben für die Fortzahlung ihres Bafög den Nachweis zu erbringen, dass sie für sie geltenden notwendigen Leistungen während ihres bisherigen Studiums erbracht haben. Auf Basis entsprechender Zuarbeiten des Prüfungsamtes bearbeitet der Bafög-Beauftragte das entsprechende Formular. Zum Abschluss der Formular-Bearbeitung bescheinigt der Bafög-Beauftragte per Vermerk auf dem Formular plus Unterschrift, dass die für die Fortzahlung der Ausbildungsförderung notwendigen Leistungen vom Studenten erbracht worden sind (ggf. unter Hinweis auf zugrundeliegende Nachweise). Abbildung 8 veranschaulicht den bisherigen Vorgang bzgl. der Ausstellung eines Bafög-Leistungsscheins, dessen Übersendung (inkl. Mehrwerten u.a. bei der Prüfung und Aufbereitung). Bild 8: Überblick Prozessanalyse (bisherige Abläufe) Projekt , Hochschule Harz, Hochschule Anhalt

40 Überblick eprozess-redesign ebafögsch (mit egov-komp.) An dem neumodellierten Verfahren sind weiterhin bisherig Involvierten beteiligt. Änderungen finden hinsichtlich des Einsatzes genutzter Komponenten/Anwendungen statt, mit denen die Kommunikation abgewickelt wird. Ebenso wird der Workflow angepasst. Die Studierenden sind die Initiatoren des Vorgangs (datenschutzkonform). Diese senden dazu eine OSCI-Nachricht mit der Bitte um Ausstellung eines Leistungsbescheides an das Prüfungsamt. Daraufhin greift das Prüfungsamt per Webbrowser auf ein System - vornehmlich einen Formularserver - zu. Das Formular wird dabei abgerufen und entsprechend der Studierenden-Daten (HIS) mit den erforderlichen Informationen gefüllt. Ggf. werden dabei unter Zugriff auf das die Studierendendaten verwaltende IT- System (z.b. HIS) in das Formular unterstützend automatisch Studierendendaten eingetragen. Daraufhin stellt das Prüfungsamt dem Bafög-Beauftragten per OSCI-Client das vorausgefüllte Leistungsbescheid-Formular zu. Dieser prüft das Formular auf logische Korrektheit. Befindet er diese Prüfung für positiv, unterschreibt der Bafög- Beauftragte den Antrag des Studenten elektronisch und sendet den Antrag an das zuständige Bafög-Amt (per OSCI-Zustellung). Auf Seiten des Bafög-Amts rufen die dortigen Mitarbeiter die eingegangenen Antrags-Daten ab und prüfen die Nachrichten. Die Daten könnten daraufhin (automatisch) ins Dateisystem exportiert und nach einer (automatisch) erfolgten Prüfung der Signaturen auf den Dokumenten/Bafög-Anträgen sowie evtl. Prüfung der Anträge bzgl. logischer Korrektheit ggf. per Adapter (XML-Basis) in die von dem Bafög-Amt genutzten Fachanwendungen übernommen werden. Student Anfrage Applikationsserver Adapter Prüfungsamt Abruf/Bearbeitung Zustellung Formularserver (Sammel-)Zustellung Bafög-Amt Applikationsserver (HIS) Bafög-Beauftragter Bild 9: Überblick eprozess-redesign ebafögsch (mit egov-komponenten) Projekt , Hochschule Harz, Hochschule Anhalt

41 Überblick Architektur, Integration & Realisierungen Zur Umsetzung des angedachten Szenarios bietet sich der Einsatz von egovernment- Basiskomponenten an, dies sind insbesondere: Formularserver, OSCI(-Clients). Formularserver bieten sich an, da die in dem Verfahren involvierten Formulare von ihrer Art und ihrem Aufbau her vorgeschrieben sind. So können diese zum Abruf ohne das Nutzen von komplexen Infrastrukturen zentral bereit gestellt und zu dem eine Reihe von komfortablen Funktionen (Eingabeprüfung etc.) für die weiteren Bearbeitung der Formulare genutzt werden. Das Protokoll OSCI sowie die dahinter stehende Infrastruktur werden in diesem Szenario für den gesicherten Transport von Formulardaten eingesetzt. Als Formularserver kommt die Lösung des Lifecycle-Servers der Firma Adobe in Betracht - welcher auch die egovernment-basiskomponente Formularserver des Landes Sachsen-Anhalt im LRZ Halle darstellt. Dieser bietet eine Reihe PDF-spezifischer wertvoller Funktionen (Bereitstellung, Auslieferung, rechtemäßige Modifikation zur Verwendung mit Servern/dem Adobe Reader). Doch auch ohne Online-Einsatz des Adobe-Lifecycle-Servers kann mit einer (einmaligen) Offline-Vorbereitung des PDF- Leer-Formulars eine weitere recht einfache Umsetzung der Formularverarbeitung umgesetzt werden. Durch den Einsatz eines einfachen Applikationsservers verbunden mit dem Einsatz von Webbrowsern inkl. Adobe Plug-In auf Nutzerseite, der dynamischen Übergabe von Daten an OSCI-Clients (inkl. der Erstellung versandfertiger OSCI- Nachrichten) besteht die Möglichkeit PDF-Formulare elektronisch qualifiziert signieren zu können, den OSCI-Versand aus PDF-Formularen heraus vorzubereiten/aufzurufen, was für das Szenario bereits die notwendige Funktionalität bietet. Die zuletzt genannte Variante auf Basis von qualif. Sign. PDF-Leerformularen und OSCI-Übersendung für den Bafög-Leistungsschein wurde bereits in Zusammenarbeit mit dem Bafögamt Halle im Rahmen einer studentischen Abschluss-Arbeit als integrierbare Prototyp-Lösung entwickelt und getestet [17]. Dabei lag der Fokus auf dem Bereitstellen von Formularen, dem Vorgang des Ausfüllens bzw. Signierens der PDF- Formulare sowie der automatisierten Erstellung versandfertiger OSCI-Nachrichten. 4 Handhabung und Nutzer-Evaluation Im Folgenden wird ein Überblick zum Stand und zur weiteren Planung der Untersuchungen zur Handhabbarkeit und Nutzerevaluation mit entsprechenden Testverfahren gegeben (Schwerpunkt Hochschule Anhalt). 4.1 Anwendbare Testverfahren - Cognitive Walkthrough Applikation wird durch Experten anhand eines Workflows untersucht. Projekt , Hochschule Harz, Hochschule Anhalt

42 trifft nicht zu trifft weniger zu trifft mittelmäßig zu trifft ziemlich zu trifft zu 38 - Fragebogen Proband beantwortet Fragen zur Gebrauchstauglichkeit der Applikation. - Heuristische Evaluation wird von Experten anhand von Usability-Prinzipien (Heuristiken) durchgeführt. - Usability-Labor der HS Anhalt Das Usability-Labor der Hochschule Anhalt bietet dabei folgende Möglichkeiten für Testverfahren: stationäres Eyetracking, Rich Recording Technology, zeitsynchrones Audio- / Videorecording. 4.2 Evaluation an der HS Harz (Projektwoche) Im Rahmen der Projektwoche fand an der Hochschule Harz im Sommersemester 2011 eine erste Evaluation statt. Inhalt der Evaluation war die Untersuchung der egovernment-tools: - Governikus Signer - OpenLimit CC Sign - Govello Communicator - EGVP. Als Probanden kamen Studenten zum Einsatz, wobei die vorhandenen Studenten in zwei Gruppen eingeteilt wurden. Der Fragebogen wurde an der HS Anhalt ausgearbeitet und enthält insgesamt 30 Fragen, wie: Index Benutzeroberfläche A1 Die Benutzeroberfläche kann intuitiv bedient werden X Das Ergebnis der Fragebögen ist grundsätzlich positiv. Jedoch kann noch keine genaue Aussage über die Gebrauchstauglichkeit getroffen werden, da eine Fragebogenauswertung erst ab 50 Probanden genügend Signifikanz aufweist. Projekt , Hochschule Harz, Hochschule Anhalt

43 Unterschiede der HIS-Implementationen Es wurde bei den Workshops von HS Harz und HS Anhalt ermittelt, dass es Unterschiede bezüglich der Ausgestaltung von HIS-Webinterfaces für die Prüfungsdatenverbuchung für Dozenten gibt: - Felder-Sortierungen möglich bei HS Anhalt (bei HS Harz nicht), - nur matrikelnummer-orientierte Eingaben bei HS Harz möglich (Datenschutz-Empfehlungen), - bei HS Anhalt Anzeige mit Klarnamen der Studierenden. 4.4 HIS-Einsatz an weiteren Hochschulen im Land Sachsen- Anhalt HIS wird an den folgenden Hochschulen bzw. Universitäten eingesetzt: - Hochschule Magdeburg Stendal - Hochschule Merseburg - Burg Giebichenstein Kunsthochschule Halle - Martin-Luther-Universität Halle-Wittenberg. Welche Unterschiede für Web-Interfaces für Noteneintragungen für Dozenten an den aufgeführten Hochschulen bzw. Universitäten in welcher Relevanz existieren, ist gegenwärtig unbekannt (noch zu ermitteln). Interface-Unterschiede wären beim Transfer der ecampus-eexamreg-lösung an andere Hochschulen durch entsprechende Subkomponenten-Anpassungen (Webadapter) des dafür entsprechend modular vorbereiteten OSHC-Mediators auszugleichen (im Falle der OSCI-Shell-HIS-Architektur). 4.5 Roll-Out an der HS Anhalt und weitere Evaluationen 1. Zu Ende 2011 ist eine ganzwöchige Evaluation und Befragung geplant. Dabei werden die technischen und organisatorischen Maßnahmen für das Roll-Out in Köthen geklärt. Ausgehend vom Vorgehen der HS Harz wird ein Leitfaden für das Roll-Out an der HS Anhalt erstellt. 2. Eine expertenorientierte Evaluation ist Ende 2011 an der HS Harz geplant. 3. Zu Anfang 2012 werden die Ergebnisse der Evaluation und der Leitfaden gemeinsam mit dem Vizepräsidenten ITK und den beteiligen Struktureinheiten (Amt für Studentische Angelegenheiten und ZIK) in einen Plan für das Roll-Out an der HS Anhalt umgesetzt. 4. Anschliessend erfolgen die Installation des Erprobungssystems (parallel) und 5. entsprechende Tests im Usability-Labor der HS Anhalt sowie vor Ort an den Arbeitsplätzen. Projekt , Hochschule Harz, Hochschule Anhalt

44 Personelle und materielle Absicherung Ein Workshop für den sicheren Umgang mit den Komponenten wird bereits Anfang 2011 durchgeführt. Die materielle Ausstattung pro Anwender wurde bereits beschafft: - ein Kartenlesegerät (Kobil KAAN Advanced) - Signatur mit Signaturkarte (qualifiziertes Signaturzertifikat) - Installierte Software (OSCI-Nachrichtensystem, Signatur-Programm). 5 Fazit, weiteres Vorgehen und Ausblick 5.1 Resümee Das Gesamtvorgehen bzgl. Konzeption, Rollout Basiskomponenten und Realisierungen, insbesondere von fundamentalen ecampus-basissystemen (Mediator) mit zentraler Bedeutung für die meisten Anwendungen, ist im wesentlichen im Gesamtplan bzgl. des Projektabschlusses (für die nicht HIS-inOne-bezogenen Projektteile), sogar mit Übererfüllungen (z.b. bzgl. egovernment-innovationen wie npa-systemen). Arbeitspakete aus dem egovernment-innovationsbereich konnten bereits vorfristig und zusätzlich in Übererfüllung auf Testebene umgesetzt werden (Mitwirkung im öffentlichen Anwendungstest neuer Personalausweis, Test-Integration in eexamreg). Zusätzlich zu den hier im Kurzberichte zusammenfassend und ausgewählt vorgestellten Realisierungen gab es weitere Entwürfe und Entwicklungen für alle sechs Fachverfahren. Die Entwicklung einer Lösung für die OSCI-Shell-HIS-Architektur auf Basis des Schalen-Systemmodells wurde erfolgreich abgeschlossen und im RZ der Hs Harz getestet. Auf dieser Basis kann nunmehr mit gutem Erfolgspotential die entsprechende Ankopplung an reale HIS-Systeme erfolgen. 5.2 Weitere Schritte Als weitere Möglichkeit bietet sich in Zusammenarbeit mit HIS die Erprobung von Varianten zur Entwicklung und Integration einer Builtin-OSCI-HIS-Architektur an (zusätzlich web-services-basiert). Eine entsprechende Entwicklungs-Kooperation auf vertraglicher Basis mit der HIS GmbH wurde abgeschlossen. Allerdings haben sich bedingt durch Lieferzögerungen für HISinOne die entsprechenden ecampus-arbeiten verzögert. Auf diese externen Verzögerungen wird ggf. mit Ersatzmassnahmen reagiert (z.b. Demonstratoren für OSCI-Builtin-HIS). Auf Basis von ggf. nutzbarer (secure) Webservices (in HISinOne) dürfte eine zum OSCI-Shell-HIS-Ansatz analoge OSCI-Builtin-HIS- Variante entwicklungs- und pflege-technisch einfacher umzusetzen sein als nach OSCI-Shell-HIS-Ansatz. Angepasst an die Integrations-, Entwicklungs- und Rolloutfortschritte werden weitere Evaluierungs- und Transferphasen zusammen mit der Hs Anhalt eingeplant. Bisher wurde in Tests bereits deutlich, dass durch Einsatz der automatisierten Verfahren (OSCI-Shell-HIS) sowie von OSCI-Tools mit zusammengefassten Zertifikats- und Signaturcheck-Ergebnissen nach dem Ampel -Prinzip" sowie weiter von Test-nPA- Projekt , Hochschule Harz, Hochschule Anhalt

45 Systemen vergleichsweise nutzerfreundliche und effiziente Formen für gesicherte Elektronisierungen gefunden wurden. Weiterhin gibt es bereits weitere hochschulübergreifende und weiter ausbaufähige Kooperationen - so zusammen mit den Partnern von der Univ. Halle (Arbeitsgruppe Chipkartenbasiertes SSO). 5.3 Nachhaltigkeit und Wiederverwendung 41 Der modulare und komponenten-basierte Entwurf auf Basis von Standards für die ecampus-lösungsarchitekturen und deren HIS-Integrationen ermöglicht eine vereinfachte Übertragung, Anpassung und Nachnutzun der ecampus-lösungen für andere Hochschulen. Durch den Entwicklungsvertrag mit der HIS GmbH werden weitere Integrationen direkt in HIS-Lieferungen und Nachnutzungen ermöglicht. Das Aufsetzen auf egovernment-komponenten und -Standards ermöglicht eine vereinfachte und kosteneffektive Nachnutzung von bewährten egovernment-komponenten und deren Pflege mit entsprechender Interoperabilität. Literatur: [1] Bundesfinanzverwaltung: Informationen zum Formular-Management-System der Bundesfinanzverwaltung. Unter: Letzter Zugriff: [2] Projektgruppe Strack, Richter: Antrag und Vorhabensbeschreibung ecampus-services & - Infrastrukturen - für eine gesicherte und verbindliche elektronische Hochschulverwaltung. Hochschule Harz, 2009 [3] Grohs, R.: Konzeption und Realisierung elektronischer Zeugnisse und zugehöriger Zugriffsinfrastrukturen auf Basis von egovernment- und Sicherheitsstandards mit datenschutzgerechten Nutzungsmöglichkeiten für Verwaltung und Wirtschaft. Diplomarbeit, Hochschule Harz, 2007 [4] Pressestelle des Senats Bremen: Datenschutzbeauftragte empfehlen Bremer Entwicklung bundesweit. Unter: bremen.de/detail.php?id=11601, Letzter Zugriff: [5] Strack, H.; Karich, Ch.; Werner, W.: Evaluation von Signaturanwendungs-und OSCI- Komponenten für den standardisierten Einsatz im Land Sachsen-Anhalt. Studie, Hochschule Harz, 2008 [6] Strack, H., Karich, Ch.: BeGovSAH Begleitforschung zur Umsetzung des egovernment- Aktionsplans in Sachsen-Anhalt ; in: Jana Dittmann (Ed.): Tagungsband Sicherheit 2006, Sicherheit Schutz und Zuverlässigkeit, Beiträge der 3. Jahrestagung des Fachbereichs Sicherheit der Gesellschaft für Informatik e.v. (GI), 02/2006 Magdeburg; LNI, Band 77, Springer-Verlag, 2006 [7] Strack, H.: Architecture and procedures for the exchange of student data using egovernment standards, RS3G-Gründungs-workshop, Rom, 2007 [8] Strack, H., Karich Ch.: A Distributed Architecture for the Management of Transcripts of Records and Student Mobility Data within the Bologna Process Framework ; in: Proceedings of EUNIS 2007 Conference, Universities of Grenoble and University P.M. Curie of Paris, France, 2007 [9] Strack, H.: egovernment und IT-Sicherheit ; in: F.Bieler, G. Schwarting (ed.): e-government Perspektiven, Probleme, Lösungsansätze, Erich Schmidt Verlag, Berlin, 2007 Projekt , Hochschule Harz, Hochschule Anhalt

46 [10] Strack, H.: egovernment und Begleitforschung Infrastrukturen, Entwicklungen, Erfahrungen und Chancen (Abstract), in: Tagungsunterlagen zum Workshop der Staatskanzlei Sachsen- Anhalt "Was braucht eine moderne Verwaltung? - Anforderungen an die Informations- und Kommunikationstechnologie"; Landesportal [11] Werner, H.: Zusammenfassung der Tests der Komponenten Govello, EGVP, GUI-loser Govello, SEK, Governikus Signer und OpenLimit CC Sign, OSCH-Mediator. Testberichte, Hochschule Harz, 2010 [12] Kußmann, P., Henning, M., Strack, H.: ecollabsec Plattform für elektronische Collaboration mit integrierter Sicherheit ; Tagungsband Nachwuchswissen-schaftlerkonferenz 2011, Wernigerode, 2011 [13] Henning, M., Kußmann, P., Strack, H.: ecampus-services & -Infrastrukturen egovernment- Komponenten- und Service-orientierte elektronische Campusverwaltung mit verbesserter Sicherheit; Tagungsband Nachwuchswissenschaftlerkonferenz 2011, Wernigerode, 2011 [14] Brehm, N., Strack, H.: ecampus OSCI-Shell-HIS Komponente (OSHC). Konzept, Hochschule Harz, Wernigerode, 2011 [15] Brehm, N., Strack, H.: Spezifikation der OSCI-Shell-HIS-Mediator-Produktivumgebung für den Anwendungsfall der Prüfungsdaten-Übermittlung (ExamReg) an der Hs-Harz. Konzept, Hochschule Harz, Wernigerode, 2011 [16] Brehm, N., Strack, H.: ecampus OSCI-Builtin-HIS Architektur. Konzept, Hochschule Harz, Wernigerode, 2011 [17] Wörfel, T.: Konzeption und Realisierung einer gesicherten Formular- und Work flowmanagement-lösung unter Integration von egovernment-basiskomponenten Fallbeispiel aus dem BAföG-Verwaltungsverfahren, DA-Einreichung IIN, 2011 [18] Sarodnick, F., Brau, H.: Methoden der Usability evaluation. Wissenschaftliche Grundlage und praktische Anwendung, Huber & Lang, Bern, 2006, Auflage 1 [19 ] Brehm, N., Strack, H.: ecampus-konzept: OSCI-Builtin-HIS Architektur, 2011 [20] Strack, Richter et. al.: LDVK-Bericht zu ecampus, 2010 [21] Strack, Richter et. al.: LDVK-Bericht zu ecampus, Langfassung (135 S.), 2011 [22] HIS GmbH: Veröffentlichungen zu HISinOne, unter: und Zugriff Projekt , Hochschule Harz, Hochschule Anhalt

47 43 Projekt Campusmanagement Einführung und Nutzung von webbasierten Onlineplattformen für die effektive Unterstützung der Prozesse in Forschung, Lehre und Verwaltung an verschiedenen Hochschultypen Zwischenbericht September 2011 Ausführende Einrichtung(en): Martin-Luther-Universität Halle-Wittenberg, Hochschule Merseburg, Burg Giebichenstein Kunsthochschule Halle Projektkoordinator: Martin Kohlmann, Abteilung 5 Hochschulplanung u. Informationsmanagement, Martin-Luther-Universität Halle-Wittenberg, D Halle (Saale). Martin.Kohlmann@verwaltung.uni-halle.de Projektmitarbeiter: Lars Deumer (Umsetzung Universität Halle), Lars.Deumer@verwaltung.uni-halle.de Michael Spindler (Umsetzung Kunsthochschule Halle), spindler@burg-halle.de Michael Hoffmann (Umsetzung Kunsthochschule Halle). michah@burg-halle.de Elena Sazina (Umsetzung Hochschule Merseburg), elena.sazina@hs-merseburg.de Förderung: Dieses Vorhaben wird mit Mitteln der Europäischen Kommission aus dem Europäischen Fonds für regionale Entwicklung (EFRE) im Rahmen der Maßnahme 11.03/41.03 gefördert (FKZ: ). Burg Giebichenstein Kunsthochschule Halle Zusammenfassung Der vorliegende Bericht zum Abschluss der Projektphase Analyse und zu der laufenden Projektphase praktische Umsetzungen ist die Fortsetzung der Berichterstattung zum Projekt Einführung und Nutzung von webbasierten Onlineplattformen für die effektive Unterstützung der Prozesse in Forschung, Lehre und Verwaltung an verschiedenen Hochschultypen Kurzname Campusmanagement mit dem Förderkennzeichen , das von der Martin-Luther-Universität Halle-Wittenberg (MLU) im Verbund mit der Hochschule Merseburg (HoMe) und der Burg Giebichenstein Kunsthochschule Halle (Burg) bearbeitet wird und stellt eine Weiterführung des Zwischenberichtes 2010 zur Projektphase Bestandsaufnahme dar. Die Projektphase Analyse konnte fristgerecht im Zeitraum vom 01. September 2010 bis zum 31. Mai 2011 bearbeitet und abgeschlossen werden. Die Projektphase Umsetzung hat fristgerecht am 01. September 2010 begonnen und verläuft in ihrer Bearbeitung durch die Projektmitarbeiter/innen planmäßig. Der geplante Abschluss dieser Phase erfolgt bis zum 15. September 2012.

48 44 Im Ergebnis der Projektphase Analyse liegen Prozessmodelle des gesamten Studierendenlebenszyklus als Referenzen vor, die eine hochschulübergreifende Nutzung im Hinblick auf die zukünftige Ermittlung von hochschulinternen Prozessabläufen ermöglichen und für andere Hochschulen als ADONIS-Datei bzw. im HTML-Format zur Verfügung stehen. Die Prozessabläufe der drei verschiedenen Hochschultypen einer Universität, einer Fachhochschule und einer Kunsthochschule sind in einem einzigen Referenzmodell abgebildet, da in der Analyse keine wesentlichen Unterschiede der Prozesse bezüglich des Merkmals Hochschultyp auf dieser Abstraktionsebene zu erkennen waren. Die erzielten Ergebnisse bieten eine gute Basis für die Bearbeitung der Arbeitspakete und die Formulierung der SOLL-Prozesse im Rahmen der HISinOne-Einführung sowie für die Nutzung durch andere Hochschulen, die eine Aufnahme der IST-Prozesse und eine Modellierung von SOLL-Prozessen sowie die Einführung einer Campusmanagementsoftware planen. Im weiteren Verlauf dieses Berichtes bezieht sich die Bezeichnung HISinOne nur auf die Bereiche Campusmanagement und Kernsegment. Mit diesem Bericht werden die zusammengefassten Ergebnisse der Projektphase Analyse sowie die bisherigen Resultate der Phase praktische Umsetzungen entsprechend den Vorgaben dem Kultusministerium und der Landes-Hochschul-DV-Kommission des Landes Sachsen-Anhalt (LDVK) präsentiert. Die in der ersten Projektphase bewährte Projektstruktur wurde fortgeführt. In der personellen Zusammensetzung der Projektgruppen gab es eine kleine Änderung. Das Projektmanagement wurde mit den turnusmäßigen Sitzungen der Arbeits- und Koordinierungsgruppe, den quartalsweise anfallenden Statusberichten und den aktualisierten Übersichten zum Projektfortschritt beibehalten. Auch im weiteren Verlauf des Projektes arbeitet die EFRE-Projektgruppe Campusmanagement als Team eng mit anderen Projekten der beteiligten Hochschulen (vor allem mit den Hochschulprojekten zur Einführung von HISinOne Campusmanagement ) sowie mit der HIS GmbH, dem Entwickler der neuen Softwaregeneration HISinOne, zusammen. In der Zusammenfassung (Management Summary) der Projektphase Analyse (siehe Ordner Abschlussbericht) finden sich als Teil der Dokumentation die Zusammenfassung der Ergebnisse und die Aufgliederung der Arbeitsphasen, die auch im Weiteren beschrieben werden. Projekt , Verbundprojekt Martin-Luther-Universität Halle-Wittenberg Burg Giebichenstein Kunsthochschule Halle Hochschule Merseburg

49 45 Gliederung des Zwischenberichtes Zusammenfassung Projektphase Analyse Ziele und Vorgehensweise bei der Analyse Darstellungsweise der Referenzprozesse Analyse der IST-Prozesse und Erstellung der Referenzprozesse Evaluierung der Referenzprozesse Nutzen für andere Hochschulen Projektphase praktische Umsetzungen Ergebnisse 2010 / Ergebnisse der Analyse Ergebnisse der praktischen Umsetzungen Ergebnisse an der Martin-Luther-Universität Halle-Wittenberg Ergebnisse an der Hochschule Merseburg Ergebnisse an der Burg Giebichenstein Kunsthochschule Halle Hochschulübergreifende Schulungen Zusammenarbeit mit anderen Projekten Literatur- und Quellenverzeichnis Projekt , Verbundprojekt Martin-Luther-Universität Halle-Wittenberg Burg Giebichenstein Kunsthochschule Halle Hochschule Merseburg

50 46 1 Projektphase Analyse 1.1 Ziele und Vorgehensweise bei der Analyse Grundlage für die Projektphase Analyse sind die Erkenntnisse, die in der vorangegangenen Projektphase Bestandsaufnahme und Prüfung gewonnen wurden. Aufgabe war es, die aufgenommenen Prozesse innerhalb der beteiligten Einrichtungen und hochschulübergreifend zu analysieren. Dabei sollte der IST-Zustand an den jeweiligen Hochschulen aufgezeigt und Gemeinsamkeiten sowie Unterschiede verdeutlicht werden. Der Gegenstand der Prozessanalyse war die Untersuchung der IST-Prozesse im Hinblick auf etwaige Überschneidungen innerhalb der Prozesse sowie die anschließende Aufgliederung in einheitliche Prozessschritte. Es wurde das Ziel verfolgt, Referenzprozesse zu erarbeiten, welche für die drei beteiligten Hochschulen gelten und von anderen Hochschulen als Vorlage genutzt werden können. Die Besonderheiten der einzelnen Hochschultypen (Volluniversität, Hochschule für angewandte Forschung und Kunsthochschule) sollten dabei identifiziert und in der Formulierung der Referenzprozesse berücksichtigt werden. Die erzielten Ergebnisse werden zukünftig anderen Hochschulen zur Verfügung gestellt, die eine Aufnahme der IST- Prozesse planen und eine Modellierung von SOLL-Prozessen beabsichtigen. Somit kann künftig eine hochschulübergreifende Abstimmung bzw. Angleichung der Abläufe ermöglicht werden. Des Weiteren wurden die Definition von Schnittstellen sowie die Erstellung von Anforderungsprofilen und Referenzen für die drei beteiligten Hochschulen angestrebt. Auch diese Phase ist durch eine enge Zusammenarbeit mit der Projektarbeitsgruppe sowie den potentiellen Nutzern anderer Hochschulen geprägt. Das Ziel dieser Phase ist eine vollständige Dokumentation, bestehend aus Referenzprozessen, welche den gesamten Studierendenlebenszyklus widerspiegeln und deren Nutzung innerhalb der Hochschulen und bis zu einem gewissen Maße über die Grenzen der o.g. Hochschulen hinaus gewährleisten. 1.2 Darstellungsweise der Referenzprozesse Unter Referenzprozessen werden Informationsmodelle verstanden, deren Inhalte bei der Konstruktion anderer Informationsmodelle dienlich sein können. Die Verwendung besteht in der Übernahme von Teilprozessen sowie deren Anpassung und Erweiterung im anwendungsspezifischen Kontext [1]. Bei der Darstellung der Referenzprozesse wurden verschiedene Varianten erstellt und in der Projektarbeitsgruppe sowie mit potentiellen Nutzern diskutiert und abgestimmt. Das Ziel war es, die Referenzprozesse entsprechend der Darstellung der HIS eigenen Prozesse zu gestalten und somit den Abgleich mit den hochschulinternen Prozessen bei einer zukünftigen Einführung von HISinOne an den Hochschulen zu vereinfachen. Aufgrund dessen fiel die Entscheidung entgegen der Darstellungsweise der IST-Prozesse in der ersten Projektphase auf die Darstellung der Referenzprozesse in horizontal ausgerichteten Geschäftsprozessmodellen unter Nutzung sogenannter Swimlanes (Schwimmbahnen). Die Modelle entsprechen sogenannten Aktivitätsdiagrammen, sie dienen der Prozessbeschreibung und spiegeln in ihrer Struktur die zeitlich-sachlogische Abfolge der betrachteten Funktionen wider. Auf Grund ihrer allgemeinen Modellcharakteristik dienen Geschäftsprozessmodelle der Dokumentation, Analyse und Gestaltung von Geschäftsprozessen sowie zur Unterstützung der Kommunikation über Geschäftsprozesse [2]. Projekt , Verbundprojekt Martin-Luther-Universität Halle-Wittenberg Burg Giebichenstein Kunsthochschule Halle Hochschule Merseburg

51 47 Die Swimlane-Grafiken, welche die Vorteile von Zuständigkeitsdiagrammen und klassischen Flussdiagrammen vereinen, können Geschäftsprozesse verständlich und übersichtlich darstellen, weil sie ihren Schwerpunkt in der Beschreibung von bereichsübergreifenden Prozessabfolgen und dabei auftretenden Schnittstellen haben. In den Swimlane-Grafiken können einerseits Aktivitäten, Vorgänger-/Nachfolgerbeziehungen und Konnektoren, andererseits Schnittstellen und Zuständigkeiten visualisiert werden. Durch Verbindungen, die als Pfeile dargestellt werden, erfolgt die logische Verknüpfung von Aktivitäten. Gehen mehrere Verbindungen aus einer Aktivität hervor, erfolgt eine Differenzierung anhand von UND- (Parallelität) bzw. ODER-( Entscheidung) Verknüpfungen. Die Aktivitäten werden in Bahnen, den so genannten "Swimlanes" oder "Lanes" angeordnet und können somit organisatorische Zuständigkeiten im erzeugten Modell abbilden. Ein wesentlicher Vorteil der Swimlane-Methode ist die Möglichkeit, schnell, strukturiert und verständlich Prozesse abzubilden [3]. Bei der Erstellung der Referenzprozesse wurde darauf Wert gelegt, system-unabhängig zu modellieren, damit bei einer zukünftigen Analyse hochschulinterner Prozesse und der damit verbundenen Erstellung von SOLL-Prozessen die Sichtweise nicht durch einen systemseitigen Blick eingeschränkt wird. Die Navigation durch die Referenzprozesse wird durch die Erstellung einer übergeordneten Prozesslandkarte für das gesamte Modell sowie mittels Übersichten für die einzelnen Phasen des Studierendenlebenszyklus erleichtert. Bild 1: Beispiel eines Referenzprozesses 1.3 Analyse der IST-Prozesse und Erstellung der Referenzprozesse Das Ziel der Analyse bestand darin, anhand der IST-Prozessmodelle (Geschäftsprozess-, IT-, Dokumenten- und Organisationsmodelle), Schwachstellen bzw. Verbesserungspotenziale bzgl. der DV-Unterstützung sowie der Ablauf- und Aufbauorganisation zu identifizieren und zu dokumentieren. Weiterhin wurde das Ziel verfolgt, hochschulübergreifend geltende Referenzprozesse zu erarbeiten, welche die Good-practice innerhalb eines abgegrenzten Anwendungsbereiches dokumentieren. Die Referenzmodelle haben den Projekt , Verbundprojekt Martin-Luther-Universität Halle-Wittenberg Burg Giebichenstein Kunsthochschule Halle Hochschule Merseburg

52 48 Vorteil, dass sie für eine Klasse von Anwendungsfällen gültig sind und somit verschiedene Prozessvarianten widerspiegeln können. Diese sollen zukünftig anderen Hochschulen zur Verfügung gestellt werden und die Grundlage für eine Analyse hochschulinterner Prozesse darstellen. Des Weiteren dienen die Ergebnisse der IST-Prozessanalyse der Unterstützung der SOLL-Prozessformulierung im Rahmen der Projekte zur Einführung von HISinOne Campusmanagement an den drei beteiligten Hochschulen. Das Zielsystem für die Analyse der Geschäftsprozesse wurde am Aspekt der Leistung der Organisation ausgerichtet. Es standen funktionale Ziele im Vordergrund, wie z.b. die Verbesserung des Ablaufs bei der Bearbeitung von Problemstellungen mittels geeigneter DV-Unterstützung sowie die Bereitstellung zusätzlicher Funktionalitäten für Studierende und Mitarbeiter im Rahmen des Studierendenlebenszyklus. Hierbei wurde untersucht, welche Prozesse zukünftig durch Funktionalitäten von bestehenden sowie neuen Anwendungssystemen unterstützt werden können. Die bereits durch Anwendungssysteme unterstützten Prozesse wurden auf potentielle Schwachstellen analysiert. Dabei lag der Schwerpunkt auf der Benutzerfreundlichkeit der Anwendungen, der Vermeidung von redundanter Datenhaltung, dem elektronischen Austausch von Daten sowie der Nutzung unterschiedlicher Anwendungslösungen für ähnliche Problemstellungen. Damit einhergehend wurden die Schnittstellen zwischen den Bereichen der Organisation im Hinblick auf etwaige Medienbrüche bei der Daten- und Informationsübermittlung untersucht, damit zukünftig eine Verbesserung der Daten- und Informationsbereitstellung ohne redundante Datenhaltung erzielt werden kann. In einem weiteren Schritt wurden mit Hilfe der Erkenntnisse der IST-Prozessanalyse und unter Berücksichtigung der Unterschiede der verschiedenen Hochschultypen systemunabhängige Referenzprozesse im Sinne einer Good-practice erarbeitet. Dabei wurden Informationen aus anderen Hochschulen bzgl. des Umgangs mit Prozessabläufen in die Betrachtung einbezogen. Für die Modellierung der Referenzprozesse mit Hilfe der Software ADONIS wurden im Vorfeld strikte Notationsregeln festgelegt, damit die Gefahr einer subjektiv intuitiven Modellierung ausgeschlossen und die Qualität der Modelle sichergestellt werden konnte. Bei der Festlegung der Modellierungsrichtlinien wurden grundsätzliche Festlegungen bezüglich der syntaktischen (formalen Korrektheit) und semantischen Richtigkeit (Struktur und Verhaltenstreue), der Relevanz (Informationsumfang in Abhängigkeit von den Modellierungszielen) sowie der Wirtschaftlichkeit (Verhältnis von Nutzen und Aufwand bei der Verarbeitung von Informationen) berücksichtigt. Des Weiteren wurden ergänzende Festlegungen im Sinne der Klarheit (Strukturiertheit, intuitive Zugänglichkeit, Verständlichkeit, Lesbarkeit) und Vergleichbarkeit getroffen. Dazu gehören Richtlinien bezüglich der optischen Darstellungsweise (Modellierungsrichtung, Modellierung von Beziehungen, Modellierung des Normalfalles, Modellierung in Flussrichtung, Modellierung von Kreuzungen, Modellierung ohne Swimlanes) sowie Konventionen bei der Namensgebung und Beschriftung der Modelle und Objekte (z.b. Bezeichnung, Nummerierung). Im Anschluss an die Modellierung konnten die einzelnen Modelle entsprechend ihrer Zuordnung zu einem Funktionsbereich strukturiert und mittels einer übergeordneten Navigationsebene (Prozesslandkarte) miteinander verknüpft werden. Die Prozesse selbst beinhalten neben der Darstellung der Aktivitäten, Konnektoren und beteiligten Akteure Projekt , Verbundprojekt Martin-Luther-Universität Halle-Wittenberg Burg Giebichenstein Kunsthochschule Halle Hochschule Merseburg

53 49 Hinweise zu einer möglichen IT-Unterstützung. Es wurde bei der Modellierung darauf Wert gelegt einen Abstraktionsgrad zu erreichen, der es jeder Hochschule ermöglicht, sich mit ihren hochschulinternen Prozessen im Referenzmodell wieder zu finden. Das Referenzmodell kann daher künftig als Leitfaden für die Prozessaufnahme und -analyse an anderen Hochschulen verwendet werden und die Identifikation relevanter Prozesse des Studierendenlebenszyklus vereinfachen. 1.4 Evaluierung der Referenzprozesse Im Vorfeld der Erstellung der Referenzprozesse wurden verschiedene Darstellungsalternativen im Projektteam, mit der Projektarbeitsgruppe sowie mit potenziellen Nutzern anderer Hochschulen entsprechend der möglichen Nutzungsszenarien diskutiert und abgestimmt. Des Weiteren erfolgte in regelmäßigen Abständen im Rahmen von Projektgruppensitzungen eine kritische Auseinandersetzung mit den erstellten Referenzprozessen hinsichtlich ihrer Lesbarkeit, Logik, Übertragbarkeit und der Einhaltung der Modellierungsrichtlinien. Damit wird sichergestellt, dass zukünftig die verschiedenen Nutzerkreise auch ohne eine intensive Vorbereitungsphase mit den Prozessen arbeiten können. Weiterhin erfolgte im Interesse der Einheitlichkeit bei der Prozessdarstellung ein permanenter Abgleich mit den Referenzprozesse der HIS GmbH. 1.5 Nutzen für andere Hochschulen Der Nutzen von Referenzmodellen besteht grundsätzlich darin, im Hinblick auf eine bevorstehende Prozessanalyse, Anhaltspunkte für die generell zu modellierenden Prozesse zu erhalten und damit über eine Basis für den Vergleich der dokumentierten IST-Prozesse zu verfügen [4]. Die Hochschulen können bei einer geplanten IST-Prozessaufnahme auf das Referenzmodell zurückgreifen und mit dessen Hilfe ihre hochschulspezifischen Prozesse identifizieren. In einem weiteren Schritt kann das im Referenzmodell abgebildete Wissen im Sinne einer Good-practice auf die IST-Prozesse angewendet werden und somit die Formulierung der SOLL-Prozesse vereinfachen. Ferner kann bei der Erstellung der IST- Prozessmodelle unter Verwendung gleicher oder ähnlicher Modellierungstechnik und Fachterminologie die Qualität der Modelle erhöht und die Vergleichbarkeit vereinfacht werden. Entscheidend für die Arbeit mit den Referenzmodellen ist das Verständnis für die Diskrepanz zu den IST-Modellen in Bezug auf den Abstraktionsgrad. Die Referenzprozesse repräsentieren eine Vielzahl von möglichen Prozessvarianten. Ein weiterer Vorteil erschließt sich aus der Gestaltung der Referenzprozesse in Anlehnung an die Darstellung der HIS-Prozessmodelle. Hier kann bei künftigen Einführungsprojekten für Softwareprodukte der HIS GmbH ein barrierefreier Abgleich der hochschulinternen Prozesse mit den HIS-Referenzmodellen realisiert werden. 2 Projektphase praktische Umsetzungen Die Projektphase der praktischen Umsetzungen unterstützt den reibungsfreien und gesicherten Betrieb bestehender HIS-Systeme und des zukünftigen Nachfolgers HISinOne. Grundlage dafür stellt zunächst die Erhebung und Konzeption der fachlichen Anforderungen für HISinOne dar. Dies führt zu einer parallelen Rückkopplung mit den Phasen Projekt , Verbundprojekt Martin-Luther-Universität Halle-Wittenberg Burg Giebichenstein Kunsthochschule Halle Hochschule Merseburg

54 50 Bestandsaufnahme und Analyse, da der Abgleich von Teilergebnissen mit den Rahmenbedingungen des HIS-Systems nicht erst nach Beendigung dieser Projektphasen erfolgen kann. Die Ergebnisse aus den Phasen Bestandsaufnahme und Analyse stellen somit eine wesentliche Grundlage für die praktische Umsetzung der Prozesse in den Systemen dar. Ziel ist demnach die Anpassung und Erweiterung ausgewählter Softwaresysteme. Allgemeine Forderungen wie Anpassung der bisherigen Softwareprodukte, Formulierung neuer Anforderungen an die bestehende Software, die Notwendigkeit für den Erwerb neuer Produkte und die Änderung von Prozessen an den drei Hochschulen anhand von Referenzprozessen sowie die Vermeidung von Arbeitsüberschneidungen sind trotz ihrer Beschränkung auf den Studierendenlebenszyklus nicht in allen Bereichen und Verfahren realisierbar. Deshalb erfolgt eine Konzentration auf die Integration ausgewählter Verfahren des Web-Content-Managements und des Lernmanagements. Primäre Informationen für die Prozesse des Studentenlebenszyklus werden in HISinOne gepflegt und anderen Systemen zur Verfügung gestellt. Mit diesem System sind nicht nur die Verwaltung der Daten der Bewerbung und Zulassung, der Studierenden, der Prüfungen, der Veranstaltungen und des Lehrpersonals, sondern auch die Abbildung der zentralen Geschäftsprozesse möglich. Für einen reibungsfreien Betrieb dürfen die Phasen Bestandsaufnahme und Analyse nicht unabhängig von HISinOne betrachtet werden. Es ist zwingend notwendig, einerseits die Prozesse hinsichtlich der Rahmenbedingungen des HIS-Systems zu begutachten und abzuwandeln, andererseits schon vor der Inbetriebnahme notwendige inhaltliche Änderungen in HISinOne zu erkennen und zu realisieren. Von HISinOne werden u.a. Funktionen für Studierende und Prüfer bereitgestellt, die über das Campusmanagement-System verfügbar gemacht werden sollen. Hier wird keine simple Verlinkung angestrebt, sondern eine tiefe technische Integration zwischen der HIS- Applikation und den weiteren Bestandteilen des Campusmanagement-Systems (bspw. ILIAS, TYPO3). Insbesondere handelt es sich hier um die Funktionsbereiche der Zulassungs-, Studierenden- und Prüfungsverwaltung. Dabei geht es beispielsweise um eine zuverlässige und sichere Registrierung zu Vor-, Zwischen-, und Abschlussprüfungen, die Einführung eines Online-Bewerbungsverfahrens sowie die effiziente Abwicklung und Dokumentation von Prüfungen sowie deren Ergebnissen. Mit dem Projekt Campusmanagement soll die Einführung und Nutzung von Onlineplattformen forciert werden, um die Prozesse in Forschung, Lehre und Verwaltung effektiv zu unterstützen. Aus diesem Grund ist die Implementierung und Etablierung einer neuen Generation eines integrierten Verwaltungssystems für die Hochschulen Merseburg und Burg Giebichenstein (HISinOne) bis zum Ende des Jahres 2012 und für die Universität Halle bis 2014 geplant. Die Basis für eine Einführung von HISinOne an den drei beteiligten Hochschulen wurde bereits gelegt, so dass sich für jede Hochschule ein eigenes Projekt zur Einführung von HISinOne ergibt. Die zuvor gewonnenen Erkenntnisse bilden die Grundlage für die Abbildung des gesamten Studierendenlebenszyklus, wodurch eine übergreifende Zusammenarbeit zwischen dem EFRE-Projekt Campusmanagement und den Projekten zur Einführung von HISinOne unerlässlich ist. Aus diesem Grund sind die HISinOne-Projekte bereits gestartet (Universität Halle als eine der ersten Volluniversitäten Deutschlands am 01. Juli 2010, Hochschule Merseburg und Burg Giebichenstein am 01. Januar 2011). Die Kooperation des EFRE-Projekts mit den HISinOne-Projekten bzw. den HISinOne-Projekten Projekt , Verbundprojekt Martin-Luther-Universität Halle-Wittenberg Burg Giebichenstein Kunsthochschule Halle Hochschule Merseburg

55 51 untereinander hat den Vorteil, dass sich Synergieeffekte besser nutzen lassen und eine Abstimmung bezüglich Vorgehensweise und Fehlerbehebung bei der Einführung und Umstellung auf HISinOne erfolgen kann. Zur besseren Abstimmung und Nutzung der Synergieeffekte werden deshalb regelmäßige Treffen zwischen den HISinOne-Projektleitern der drei Hochschulen untereinander sowie mit den Mitarbeitern des EFRE-Projekts Campusmanagement durchgeführt. 3 Ergebnisse 2010 / Ergebnisse der Analyse Während der Erhebung der IST-Prozesse wurden bereits von den Interviewpartnern einzelne Probleme bzw. komplexe Problemfelder, z.b. in Struktur, Ablauf und Kommunikation ihrer Arbeitsaufgaben thematisiert und erfasst. Im Zuge dessen wurden Übersichten erarbeitet, welche potenzielle Schwachstellen (sogenannte Potenzialtabellen) sowie Vorschläge zur Vereinfachung und Optimierung der Arbeitsprozesse in den jewwiligen Hochschulbereichen dokumentieren. Diese Änderungsempfehlungen resultierten aus Anmerkungen der Befragten selbst oder wurden von den Interviewern herausgestellt. Des Weiteren ergaben sich aus dem Abgleich der Prozesse aus den verschiedenen Hochschulen weitere Handlungsempfehlungen. Die Analyse zeigte hinsichtlich der Formulierung der Referenzprozesse, dass keine wesentlichen Unterschiede der Prozesse bezüglich des Merkmals Hochschultyp auf dieser Abstraktionsebene bestehen. Lediglich die Existenz von einzelnen Prozessen und Teilprozessen variiert bei den verschiedenen Hochschultypen. Da dies jedoch nicht generell zutreffen muss, wurde ein Modell für alle Hochschultypen entwickelt. Dies gibt der jeweiligen Hochschule die Möglichkeit eines umfassenden Einblicks in die Prozesslandschaft einer Hochschule - ohne dabei in ihrer Sichtweise eingeschränkt zu werden. Die Hochschule hat somit die Chance, selbst zu entscheiden, welche Prozesse für die Untersuchung von Bedeutung sind und welche keine Berücksichtigung finden sollen. Das Referenzmodell ist so aufgebaut, dass es ausgehend von einer Prozesslandkarte auf die verschiedenen Bereiche Orientierung, Werbung, Anbahnung/ Bewerbung und Zulassung/ Studierendenmanagement/ Prüfungs- und Veranstaltungsmanagement/ Alumnimanagement sowie bereichsübergreifende Unterstützungsprozesse zugreifen kann. Im jeweiligen Funktionsbereich sind Übersichten zu den darin enthaltenen Prozessen angelegt. Demzufolge können die Prozesse eines bestimmten Bereiches direkt aufgerufen werden. Die Prozesse selbst sind so aufgebaut, dass sie bis auf einige Ausnahmen keine Unterprozesse beinhalten, so dass die Navigation vereinfacht und ein Gesamtüberblick über den jeweiligen Prozess ermöglicht wird. Im Gegensatz zu den Referenzprozessen der HIS GmbH sind die Referenzprozesse des EFRE-Projekts systemunabhängig und beschreiben lediglich den Ablauf der Arbeitsschritte. Der Nutzer ist somit frei von jeglichem Systemdenken. Er kann anhand objektiver Kriterien entscheiden, mit welcher Anwendung er einen bestimmten Prozess unterstützt oder welche Prozesse zukünftig ohne eine solche Unterstützung auskommen können. Für eine entsprechende Entscheidungsunterstützung wurde eine Diskussionsgrundlage in Form möglicher IT-Anwendungen in den einzelnen Prozessen integriert. Projekt , Verbundprojekt Martin-Luther-Universität Halle-Wittenberg Burg Giebichenstein Kunsthochschule Halle Hochschule Merseburg

56 52 Die EFRE-Projektgruppe stellt im Internet auf den Seiten der Universität Halle ( die Ergebnisse der Phase Analyse für Interessenten zur Verfügung. Hier sind zudem Informationen zum Projektstand sowie zu aktuellen Entwicklungen im Campusmanagement zusammengestellt. 3.2 Ergebnisse der praktischen Umsetzungen Ergebnisse an der Martin-Luther-Universität Halle-Wittenberg In Vorbereitung auf die Einführung von HISinOne Campusmanagement wurde zunächst der Aufbau eines Kollaborationsportals vorangetrieben. Hierbei kam das Produkt Microsoft Sharepoint 2010 zum Einsatz. Bei einem Sharepoint-System handelt es sich um eine Business Plattform, welche die Zusammenarbeit der Projektteams innerhalb und außerhalb der Organisation erleichtert. Es bietet neben der Möglichkeit des Webzugriffs, Funktionen zur Dokumentenablage und bearbeitung, zudem ein differenziertes Rechte und Rollensystem sowie Möglichkeiten der Terminkoordination und Informationsbereitstellung. Die Projektbeteiligten können sich zum Beispiel bei Statusänderungen (Änderung an Dokumenten, neue Dokumente, News etc.) per informieren lassen. Ein weiterer Vorteil stellt die nahtlose Integration in MS Office, Exchange Server und das Kommunikationssystem der Universität dar. Eine Anpassung der Oberfläche an das Design der Hochschule wurde ebenfalls durchgeführt. Das Sharepoint-System bildet somit die Basis für eine gute Kommunikation innerhalb und zwischen den Projekten Campusmanagement und Einführung von HISinOne Campusmanagement sowie mit den externen Projektbeteiligten der HIS GmbH. In einem weiteren Schritt wurde das Testsystem von HISinOne in der Version 2.0 installiert. Anhand der Informationen aus dem Testsystem wurden die vorhandenen Rollen und Rechte in HISinOne PSV identifiziert (Anlage 1) sowie die potentiellen Migrationsquellen und deren Synchronisationsmöglichkeiten (Anlage 2 + 3) für HISinOne PSV ermittelt. Die identifizierten Rollen und Rechte wurden im Hinblick auf die Entwicklung eines an die Hochschule angepassten Rollen- und Rechtekonzeptes mit den bisher verwendeten Rollen in den Altsystemen abgeglichen. Des Weiteren erfolgte eine Erfassung aller bisher im Rahmen des Studierendenlebenszyklus verwendeten Druckerzeugnisse und Dokumente. Diese werden im weiteren Verlauf bzgl. der Umsetzbarkeit bzw. Abbildungsmöglichkeit in HISinOne untersucht. Auf Basis der aufgenommenen IST-Prozesse sowie der entwickelten Referenzprozesse aus der Projektphase Bestandsaufnahme und Analyse wurden in Zusammenarbeit mit den Arbeitsgruppen des Projektes Einführung von HISinOne Campusmanagement die SOLL-Prozesse für die Bereiche Bewerbung und Zulassung/ Studierendenmanagement/ Prüfungs- und Veranstaltungsmanagement/ Alumnimanagement erarbeitet. Mit Hilfe der Informationen aus dem Testsystem sowie dem Abgleich der entwickelten SOLL-Prozesse mit dem Referenzmodell der HIS GmbH wurden die Anforderungen an das zukünftige System formuliert und der HIS GmbH im Hinblick auf die Weiterentwicklung von HISinOne übermittelt. In Abhängigkeit vom Entwicklungsstand der Software wurde ein vorläufiger Zeitplan für die Einführung von HISinOne Campusmanagement entworfen. Danach soll der Produktionsbetrieb im Wintersemester 2014 aufgenommen werden. Eine erste Nutzung von HISinOne wird jedoch bereits im Jahr 2012 mit dem Funktionsbereich PSV in Form eines Projekt , Verbundprojekt Martin-Luther-Universität Halle-Wittenberg Burg Giebichenstein Kunsthochschule Halle Hochschule Merseburg

57 53 Gästeportals angestrebt. Hierfür soll eine Schnittstelle zum Nutzerprojekt (Identitätsmanagement) im Universitätsrechenzentrum geschaffen werden. Ziel dabei ist die dezentrale Erfassung von Gastdozenten, Gastwissenschaftlern und Gasthörern, welche IT-Ressourcen der Universität verwenden. Mit der Registrierung soll zukünftig die Antragstellung für die Nutzung zentraler Ressourcen / Dienstleistungen im Rechenzentrum der Martin-Luther- Universität Halle-Wittenberg, welche bisher in Papierform erfolgt, abgelöst werden. Hierzu werden bei der Registrierung für jeden Gast die notwendigen Ressourcen ausgewählt und an das Rechenzentrum übermittelt. Die Zugangsdaten erhält der Gast dann wahlweise per Post oder . Das Gästeportal wird zudem an das Corporate Identity der Hochschule angepasst, sodass sich der Nutzer optisch in einer gewohnten Umgebung wiederfindet. Der Produktivbetrieb des Gästeportals dient somit als ein erster Test für die Performance und die Usability von HISinOne. Ein weiterer Vorteil ist die frühzeitige Identifikation von potentiellen Schwachstellen im Systems, welche somit bis zum eigentlichen Produktivstart 2014 beseitigt werden können. Bild 2: Schema Gästeportal Ein weiteres Ziel der Projektphase praktische Umsetzungen ist die vorgezogene Einführung von HIS LSF, einer Web-Anwendung für Lehre, Studium und Forschung, mit der Realisierung einer Schnittstelle zum bisher verwendeten System StudIP (internetbasierte Arbeitsumgebung zur Unterstützung von Lehrveranstaltungen an Bildungseinrichtungen). Hintergrund dieser Entscheidung ist mit Rücksicht auf die Verschiebung der Einführung von HISinOne in das Jahr 2014 der Bedarf an einer zeitnahen Nutzung eines ausgereiften Veranstaltungsmanagementsystems. Ein weiterer Vorteil ergibt sich aus der Ähnlichkeit der Datenmodelle in HIS LSF und HISinOne. Eine vorgezogene Einführung von HIS LSF lässt demnach eine Aufwandsreduktion bei der späteren Datenmigration in HISinOne erwarten Ergebnisse an der Hochschule Merseburg Projekt , Verbundprojekt Martin-Luther-Universität Halle-Wittenberg Burg Giebichenstein Kunsthochschule Halle Hochschule Merseburg

58 54 Vor dem Beginn des Projektes Einführung von HISinOne Campusmanagement, welches eine hochschulweite Kommunikation und Kooperation erfordert, wurde eine Arbeitsumgebung in ILIAS (Lernplattform) für alle Projektgruppen zwecks einer übersichtlichen Terminkoordinierung und eines vereinfachten Dokumentenaustausches innerhalb der Hochschule sowie mit den Projektbeteiligten der HIS GmbH eingerichtet. Direkt nach dem Projektstart konstituierten sich die Projektgruppen und nahmen ihre Arbeit auf. Die Gruppe Technische Basis führte den Aufbau der technischen Infrastruktur und anschließend die Installation von HISinOne (Version 2.07) durch. Bei der Installation wurde zunächst die Customizing-Umgebung aufgesetzt, wodurch ein flexibles Testen von hochschulspezifischen Konfigurationen bzw. neuen HISinOne Versionen gewährleistet wird. Die Web-, Applikations- und Datenbank-Server sind virtualisiert (VMware ESXi Server), als Betriebssystem wird Ubuntu Server LTS eingesetzt und zur Versionsverwaltung von Konfigurationsdateien wird Apache Subversion (SVN) genutzt. Als Konfigurations- und Testsystem bietet HISinOne in der Version 2.07 eine ausreichende Möglichkeit, die SOLL-Prozesse hinsichtlich ihrer Unterstützung durch HISinOne zu prüfen, so dass im Mangelfall entsprechende Anforderungen an das HISinOne Entwicklungsteam formuliert werden können. In der Projektarbeitsgruppe Kernsegment wurde die grundlegende Festlegung bzgl. des zukünftigen Identitätsmanagements an der Hochschule getroffen: HISinOne soll das führende Identitätsmanagementsystem werden und die Basis für die Realisierung von Single Sign-on legen. Der Aufbau der neuen Identitätsmanagementlösung erfolgt einerseits in HISinOne selbst und andererseits durch die Anbindung von LDAP an HISinOne. So wurden Konzepte zu den Objekten (Personen, Einrichtungen und Baudaten) erstellt, die in HISinOne als Identitäten fungieren. Die Einrichtungsstruktur, die u.a. den Wirkungsbereich von Rollen bestimmt, ist vorläufig festgelegt. Das Konzept für die Anbindung von LDAP wird gerade erarbeitet. In mehreren Schritten wurde die Datenqualitätsanalyse mit anschließender Datenbereinigung durchgeführt, damit die Datenmigration fehlerfrei erfolgen kann. Es wurde ein Migrationsplan erstellt, in dem notwendige Datenquellen und die Reihenfolge einzelner Migrationsschritte (Vorarbeiten, eigentliche Migration und Nacharbeiten je Datenquelle) dokumentiert sind. Die Mitglieder der Projektarbeitsgruppe Campusmanagement erarbeiteten Fachkonzepte für die Bereiche Bewerbung- und Zulassungsmanagement, Studierendenverwaltung, Prüfungs- und Veranstaltungsmanagement, welche einer weiteren Präzisierung bedürfen. Die SOLL-Prozesse für das Bewerbungs- und Zulassungsmanagement wurden auf der Grundlage der HIS-Referenzprozesse mit Berücksichtigung der aufgenommenen IST- Prozesse und der absehbaren Änderungen der Verwaltungsabläufe entwickelt. Die Abstimmung der Fachkonzepte mit der HIS GmbH erfolgt in regelmäßigen Workshops für die o.g. Produktbereiche. Der erste Workshop zum Thema Personalisierte Services und Verzeichnisse auf dem Fragen bzgl. des Identitätsmanagements zu klären waren, wurde für alle beteiligten Hochschulen gemeinsam durchgeführt und bot daher die Möglichkeit, diesen Produktbereich aus verschiedenen Sichten zu diskutieren. Diese Organisationsform der Projekt , Verbundprojekt Martin-Luther-Universität Halle-Wittenberg Burg Giebichenstein Kunsthochschule Halle Hochschule Merseburg

59 55 einführenden Workshops wurde sehr positiv von den Beteiligten aufgenommen und auf andere Produktbereiche von HISinOne ausgeweitet. Die Erstellung der Fachkonzepte initiierte Diskussionen bzgl. grundlegender Festlegungen in folgenden Prozessen: Modulverwaltung, Stundenplanung und Prüfungsmanagement; die Problematik wurde den Fachbereichen über den Lenkungsausschuss erörtert. Daraus resultierende Entscheidungen werden mit großer Wahrscheinlichkeit eine wesentliche Umstrukturierung der betroffenen Prozesse verlangen. Für die Veranstaltungsverwaltung an der Hochschule kommt die e-learning-plattform ILIAS zum Einsatz. Mit dem Ziel, ILIAS und HISinOne zu koppeln, wurde ein Lastenheftentwurf mit Hauptanforderungen bzgl. des Datenaustausches zwischen den beiden Systemen zur Diskussion in den Fachbereichen vorbereitet. Bild 3: Illustration des Integrationsansatzes der Lernplattform ILIAS Im Zuge der Erarbeitung der Fachkonzepte wurde eine Übersicht von den im Studierendenlebenszyklus benötigten Druckerzeugnissen und Dokumenten erstellt. Im nächsten Schritt ist zu prüfen, inwieweit sie sich in HISinOne einpflegen bzw. erstellen lassen. Auch verschiedene in den Verwaltungsabläufen genutzte Strukturdaten zu Studiengängen (wie PO-Versionierung, Laufzeit, Kapazität, Akkreditierung etc.) wurden in einer Gesamtübersicht zusammengefasst, welche zur Identifikation von Problemen im Studiengangsmanagement bei der Einführung von HISinOne genutzt werden kann. Zu den nächsten Arbeitsschritten gehören das Einpflegen der Einrichtungsstruktur, die Migration von Baulichdaten, Personen und Studiengängen bzw. die Migration einzelner Prüfungsordnungen zur Abschätzung des Nachbearbeitungsaufwandes und die Identifikation möglicher Fehlerquellen. Die Erarbeitung eines Rollen- und Rechte-Konzeptes erfolgt zunächst für den APP Produktbereich (Bewerbungs- und Zulassungsmanagement), der als Erster eingeführt werden soll. Nach der Abstimmung der SOLL-Prozesse aus dem Bereich Projekt , Verbundprojekt Martin-Luther-Universität Halle-Wittenberg Burg Giebichenstein Kunsthochschule Halle Hochschule Merseburg

60 56 Bewerbungs- und Zulassungsmanagement mit der HIS GmbH werden nötige Anpassungen in HISinOne laut dem erstellten Fachkonzept vorgenommen. In Vorbereitung der Einführung des Produktbereiches EXA (Veranstaltungs- und Prüfungsmanagement) wird ein Konzept für die Umsetzung des Lehrveranstaltungsmanagements (inkl. der Stundenplanung) gemeinsam mit den Fachbereichen entwickelt Ergebnisse an der Burg Giebichenstein Kunsthochschule Halle Eine relativ überschaubare Anzahl Studierender bei einem dennoch breit gefächerten Angebot an Studiengängen ist eine Besonderheit der Burg, der mit einem kleinen, aber flexiblen Kernteam Rechnung getragen wird. Mitarbeiter des Dezernates Studienangelegenheiten als fachlicher Part arbeiten hier eng mit Kollegen aus dem Zentrum für Information und Kommunikation zusammen, die den technischen Teil übernehmen. Zudem besteht eine gute Kommunikation mit der Hochschulleitung. Bei den einzelnen Bestandteilen des Campusmanagements werden die jeweiligen Zielgruppen mit hinzugezogen, wie z.b. das Transferzentrum im Bereich Alumnimanagement. Dieses Arbeitsmodell mit einer flachen Hierarchie bedeutet kurze Wege und Antwortzeiten und kann flexibel auf Veränderungen reagieren. Zur besseren Organisation sowie für die Projektdokumentation wurde anfangs ein Blog, später dann (speziell für die Anforderungen der technischen Umsetzung) das webbasierte Projektmanagement-Tool Redmine aufgesetzt. Insbesondere dessen Bestandteile Wiki, Ticketverwaltung und Dokumentenablage erleichtern die Bearbeitung der einzelnen Projektphasen. Sowohl die Projektbeteiligten als auch die HIS GmbH erhielten Zugriff auf diese Plattformen. Erstes Ergebnis dieser Maßnahmen ist die Einführung eines Fachbereichs übergreifenden Lehrangebotsverzeichnisses zum Wintersemester 2011/12 als ein Bestandteil des entstehenden Portals Burg Campus Online. Hierzu nutzt die Burg das bereits an anderen Hochschulen bewährte System LSF. Nebeneffekt hierbei ist eine vorbereitende Datensammlung und -qualitätsanalyse für das zukünftig einzusetzende System HISinOne. Parallel dazu fand eine detaillierte Raumdatenerfassung im Bereich Lehre statt, um eine hohe Qualität der Raumbeschreibung sicherzustellen. Bereits im Sommersemester 2011 wurden die entsprechenden Mitarbeiter in den Sekretariaten der Studiengänge für die Einpflege der Lehrangebote geschult, so dass ab diesem Zeitpunkt erste Lehrangebote zu finden waren. Damit gingen organisatorische Anpassungen einher, da die Lehrveranstaltungserfassung bisher nur als Aushang bzw. als PDF-Dokument auf der Internetpräsenz der Hochschule verfügbar gemacht wurde. Projekt , Verbundprojekt Martin-Luther-Universität Halle-Wittenberg Burg Giebichenstein Kunsthochschule Halle Hochschule Merseburg

61 57 Bild 4: Illustration des Lehrangebotsverzeichnisses BurgCampusOnline Ein nächster wichtiger Schritt war die Erarbeitung eines detaillierten Zeitplans, welcher den Studienjahresablaufplan der Hochschule und die zukünftigen Studentenjahrgänge berücksichtigt und übersichtlich darstellt. Dieser wurde auch als Basis für die Zeitpläne der beiden anderen beteiligten Hochschulen eingesetzt. Auf einer hochschulöffentlichen Infoveranstaltung ( Kick-Off ) im Juni 2011 wurde das Portal Burg Campus Online mit dem erarbeiteten Zeitplan vorgestellt. Hierzu gehörte auch eine Live-Vorführung des Lehrangebotsverzeichnisses mit dem aktuellen Lehrangebot des Sommersemesters Für eine höhere Flexibilität beim Aufbau der HISinOne-Testumgebung und eine bessere Ressourcenauslastung wurde eine Virtualisierungsumgebung auf Basis von Microsoft Hyper- V und Ubuntu aufgebaut und die Erfahrungen mit entsprechenden Lösungen der beiden anderen Hochschulen verglichen. Von Vorteil ist die nahtlose Einbindung in die an der Burg vorhandene Backupstrategie und die beliebige Skalierbarkeit. So ist es möglich, je nach Bedarf zusätzliche Anwendungsserver per Knopfdruck fertig konfiguriert als Kopie der bereits bestehenden Server zu erzeugen. Auf Basis dieser virtuellen Hardware erfolgte die Installation einer sogenannten Customizing- Säule, also einer Testumgebung, welche sukzessive visuell und inhaltlich an die konkreten Bedingungen der Hochschule angepasst wird. Die dabei entstehenden Konfigurationsdaten werden später auf das Produktivsystem übertragen, welches ebenso auf virtuellen Servern installiert wird und den Livebetrieb mit den echten Nutzerdaten sicherstellt. So können Änderungen vorher ausgiebigen Tests unterzogen werden, ohne das Produktivsystem zu beeinträchtigen. Die Datenbanksysteme, welche eine lückenlose Verfügbarkeit der zu verarbeitenden Daten garantieren müssen, wurden von der Virtualisierung ausgenommen und als konventionelle Projekt , Verbundprojekt Martin-Luther-Universität Halle-Wittenberg Burg Giebichenstein Kunsthochschule Halle Hochschule Merseburg

62 58 Server redundant aufgesetzt. Hierzu besuchten die Mitarbeiter der Burg und der beteiligten Hochschulen eine Intensivschulung zum verwendeten Datenbanksystem PostgreSQL. Diverse Workshops zu den einzelnen Produktbereichen des Campusmanagementsystems HISinOne wechselseitig organisiert durch die beteiligten Hochschulen klären Fragen und bereiten die Umsetzung somit fachlich vor. Bisher wurden an der Burg ein PSV-Workshop (Analyse und Optimierung der Prozesse rund um das Identitätsmanagement) sowie daran anknüpfend ein Workshop zu Webservices durchgeführt. Dies geschah im Hinblick auf die bevorstehende Anbindung von HISinOne an die vorhandenen Systeme RADIUS, Microsoft Active Directory und die auf TYPO3 basierende Hochschulwebsite. Bild 5: Illustration des Ansatzes zur Webservice-basierten Anbindung von Authentifizierungsdiensten Weitere Workshops finden zu den Themen Studierendenmanagement sowie Prüfungs- und Veranstaltungsmanagement statt. Im weiteren Projektverlauf werden die in der ersten Projektphase aufgenommenen Ist- Prozesse in Zusammenarbeit mit den betreffenden Arbeitsgruppen der Hochschule analysiert und bei Änderungsbedarf im Hinblick auf die Funktionalitäten des HISinOne Campusmanagementsystems entsprechende Soll-Prozesse formuliert und kommuniziert. 3.3 Hochschulübergreifende Schulungen Im Rahmen des EFRE-Projektes wurden zur Sicherstellung eines reibungsfreien Ablaufs der Phase praktische Umsetzungen hochschulübergreifende Schulungen zu den Themenbereichen Subversion (Versionskontrolle), Oberflächengestaltung HISinOne, PostgreSQL-Datenbankoptimierung und Webservices (Anbindung von bestehenden Fremdsystemen über SOAP-Schnittstellen) realisiert. Ziel hierbei war die Stärkung der Kompetenz der Projektmitarbeiter in den genannten Bereichen. Projekt , Verbundprojekt Martin-Luther-Universität Halle-Wittenberg Burg Giebichenstein Kunsthochschule Halle Hochschule Merseburg

63 59 Weiterhin wurden die Einführungsworkshops für die einzelnen Funktionsbereiche von HISinOne Campusmanagement gemeinsam von den 3 beteiligten Hochschulen organisiert und durchgeführt. Durch die gemeinsame Organisation und Durchführung von Schulungen und Workshops konnte ein adäquater Informationsaustausch zwischen den beteiligten Hochschulen sichergestellt sowie Synergieeffekte erzielt werden. Aufgrund der positiven Erfahrungen aus der gemeinsamen Arbeit wird dieser Weg im weiteren Verlauf des Projektes konsequent weiterverfolgt. 3.4 Zusammenarbeit mit anderen Projekten An den drei beteiligten Hochschulen wurde parallel zu den Projekten zur Einführung von HISinOne Campusmanagement" zusammengearbeitet. Die Zusammenarbeit umfasste den Austausch von Informationen zur Planung von zukünftigen Prozessabläufen im Hinblick auf die Einführung von HISinOne. Dieser Informationsaustausch erfolgte in gemeinsamen Sitzungen. Dabei wurden die identifizierten Schwachstellen in den bisherigen Abläufen und Funktionalitäten bestehender Systeme diskutiert und Anforderungen an die neue Software formuliert. Des Weiteren wurden die fertig gestellten SOLL-Konzepte aus dem Projekt HISinOne Campusmanagement" durch das EFRE-Projektteam in eine entsprechende Prozessdarstellung überführt, so dass eine Nutzung seitens der HIS GmbH barrierefrei erfolgen kann. Literatur- und Quellenverzeichnis [1] Becker, J. ; Delfmann, P. ; Knackstedt, R.: Adaption fachkonzeptioneller Referenzprozessmodelle. In: Industrie Management, 20(2004), Nr. 1, 19-21; Brocke, J.v.: Referenzmodellierung. Gestaltung und Verteilung von Konstruktionsprozessen. Logos Verlag, Berlin, 2003, zugl. Diss., Univ. Münster, [2] Schmelzer, H.J., Sesselmann, W.: Geschäftsprozessmanagement in der Praxis: - Kunden zufrieden stellen - Produktivität steigern - Wert erhöhen, 6. Auflage, Carl Hanser Verlag München, [3] [abgerufen am ] [4] Becker J., Kugeler M., Rosemann M., Prozessmanagement: Ein Leitfaden zur prozessorientierten Organisationsgestaltung, 6. Auflage, Springer Verlag Projekt , Verbundprojekt Martin-Luther-Universität Halle-Wittenberg Burg Giebichenstein Kunsthochschule Halle Hochschule Merseburg

64 60

65 61 Homogene Verzeichnisdienste Ausführende Einrichtungen: Otto-von-Guericke Universität Magdeburg / Hochschule Harz (FH) Projektleiter: Dr. Rolf Knocke, Leiter des Universitätsrechenzentrums, Otto-von-Guericke Universität Magdeburg, Magdeburg. rolf.knocke@ovgu.de Friedemann Hass, Leiter des Rechenzentrums, Hochschule Harz (FH), Wernigerode. fhass@hs-harz.de Projektmitarbeiter: Nataliya Kulyk, Mitarbeiterin des Universitätsrechenzentrums, Otto-von-Guericke Universität Magdeburg. nataliya.kulyk@ovgu.de Georges Gebara, Mitarbeiter des Rechenzentrums, Hochschule Harz (FH). ggebara@hs-harz.de Förderung: Dieses Vorhaben wird mit Mitteln der Europäischen Kommission aus dem Europäischen Fonds für regionale Entwicklung (EFRE) im Rahmen der Maßnahme 11.03/41.03 gefördert (FKZ: ). Zusammenfassung Dieses Dokument stellt eine Zusammenfassung des Projektes Homogene Verzeichnisdienste dar und präsentiert in kurzer Form seine Ziele und erreichten Ergebnisse. Das Projekt analysierte Schwachpunkte der bisher an beiden Hochschulen eingesetzten Identity Management-Verfahren, erarbeitete Lösungsansätze und setzte diese um. Der Schwerpunkt lag dabei auf der Synchronisation verbindlicher Quellen mit einem zu implementierenden Meta-Verzeichnis und dessen Nutzungsmöglichkeiten zum Aufbau einer hochschulübergreifenden Föderation. Eine umfassendere Version wird Institutionen, die vor ähnlichen Aufgaben stehen, gerne auf Anfrage zur Verfügung gestellt. Projekt , OvGU Magdeburg / FH Harz

66 62 Inhaltsverzeichnis 1 Ausgangssituation HS Harz OvGU Magdeburg Zielvorstellung Soll-Zustand HS Harz Soll-Zustand OvGU Magdeburg Umsetzung der Zielvorstellung Softwareverwendung Aufbau des Verzeichnisbaumes LDAP Schema Gruppen-, Rollen- und Rechtekonzept Zusammenfassung der Umsetzung Anschluss weiterer Systeme Shibboleth Grundsätzliches Verfahren Föderationen Bibliotheksverbund (HS Harz) Mailsystem Active Directory Nachteile der momentanen HISinOne-Version Zusammenfassung Literatur Projekt , OvGU Magdeburg / FH Harz

67 63 1 Ausgangssituation Die Ausgangssituation des Identity Managements an beiden Hochschulen entspricht nicht den modernen Anforderungen: verschiedene Systemen betreiben eigene Nutzerverwaltungen, gleiche Daten werden oft mehrmals an unterschiedlichen Stellen erfasst. Dies führt zu Nachteilen wie Dateninkonsistenzen, Zeitverzögerungen, starker Dezentralisierung, mehr Administrationsaufwand und nicht ausreichende Rollen- und Rechtemodelle. Die Einzelheiten der Ausgangsituationen beider Hochschulen werden in den nächsten Abschnitten beschrieben. 1.1 HS Harz Die momentan stattfindende Synchronisation der LDAP-Server für Fachanwendungen ist ein Abgleich mit den führenden Datenquellen ohne Abgleich der Server untereinander. Es finden zwar Echtzeit-Synchronisationen zwischen einzelnen LDAP-Servern statt, dies beschränkt sich jedoch auf Produktionsmaschinen und Ihre Hot-StandBy - Pendants zur Ausfallsicherheit. Ein Abgleich durch LDAP-eigene Synchronisationsmechanismen zwischen internem und öffentlichem Netz ist z.zt. nicht möglich, da unterschiedliche Produkte Verwendung finden (Sun Java System DS Enterprise Edition / Sun One DS, OpenLDAP, Novell NDS, Active Directory). Der eigentliche Abgleich zwischen Datenquellen und LDAP-Servern ist skriptbasiert. Unterschiedliche Skripte lesen täglich mehrere Datenquellen aus und generieren für die unterschiedlichen LDAP-Server und Endsysteme einzelne Dateien, die von ihnen eingelesen werden. Ein großes Problem hierbei sind die vielen Unterschiede und Doppelungen, bedingt durch die Serverstruktur. Neben dem allgemein erhöhten Administrationsaufwand und dem Problem des Zeitverzuges wird so auch die Datenkonsistenz über die verschiedenen LDAP-Server hinweg beeinträchtigt. Viele Rollen und Berechtigungen wurden im bestehenden System durch statische Gruppen umgesetzt, was einen erhöhten Administrationsaufwand zur Folge hat und verschiedene Probleme mit sich bringt. Sollte z.b. eine Person vorübergehend deaktiviert werden müssen, wären Ihre Gruppenzugehörigkeiten zu löschen, um die Datenkonsistenz zu wahren. Wird diese Person später wieder aktiviert, müsste Sie erneut in alle früheren Gruppen eingetragen werden. Dies lässt sich zwar automatisieren, führt aber dazu, dass die Informationen in anderen Systemen gehalten werden müssten und bringt wieder einen gewissen Zeitverzug mit sich. Ganz allgemein bedeuten statische Gruppen ohne den Einsatz von Methoden, die Funktionalitäten dynamischer Gruppen imitieren (forward referencing by operational attributes), auch einen erhöhten Suchaufwand, sobald es nicht nur um reine Gruppenzugehörigkeiten sondern um bestimmte Eigenschaften der Mitglieder geht, da erst die Mitglieder ermittelt und dann ihre jeweiligen Attributwerte durch weitere Suchen zusammengestellt werden müssen. Viele Personen haben aufgrund verschiedener Rollen mehrere Identitäten, was zwar legitim ist, aber das System umständlich und fehlerträchtig macht. Hier wäre eine Zusammenführung auf einen Nutzeraccount wünschenswert. Projekt , OvGU Magdeburg / FH Harz

68 64 sos sva LDAP int LDAP ext endsys endsys meinacc Bild 1: Vereinfachte Ausgangsserverstruktur der HS Harz 1.2 OvGU Magdeburg An der OvGU Magdeburg dient bis jetzt eine Datenbank als zentrales System für Nutzerinformationen (Bild 2). Die Studentendaten werden aus HISSOS bezogen. Das sind die Daten über neu immatrikulierte Studenten und die Nutzernamen von exmatrikulierten Studenten. Der Datenaustausch zwischen HIS und der Oracle-Datenbank wird offline mit großem Zeitabstand (24 Stunden) mit Hilfe von Skripten durchgeführt. Die Mitarbeiterdaten wurden zum Projektanfang noch per Hand erfasst. Neue Mitarbeiter müssen sich selbst im Kontaktbüro des Universitätsrechenzentrums anmelden. Diese Daten aus der Datenbank werden dann bearbeitet und mit Hilfe von Skripten an LDAP und andere Endsysteme weitergegeben. Die Rollen und Rechte sind zurzeit nur wenig im LDAP abgebildet, deshalb bevorzugen einige Administratoren, eine eigene Nutzerverwaltung durchzuführen. Nicht alle Systeme verfügen über eine LDAP- Schnittstelle. Beim Ausscheiden aus der Universität werden alle Nutzereinträge aus dem LDAP mit Hilfe von Skripten entfernt. Die Gäste der Hochschule müssen bis jetzt ins Kontaktbüro des URZs kommen und sich in die DB eintragen lassen. Für externe Bibliotheknutzer war ein anderes Verfahren gültig: Sie bekommen Zugangsdaten, die schon im Vorfeld nicht personenbezogen generiert wurden und der Bibliothek zu Verfügung stehen. SOS Kontaktbüro Oracle DB LDAP endsys endsys Bild 2: Vereinfachte Ausgangsserverstruktur der OvGU Magdeburg Projekt , OvGU Magdeburg / FH Harz

69 65 2 Zielvorstellung Die in der Ausgangssituation beschriebenen Schwächen sollen behoben werden, indem ein hochschulweites Meta-Directory als zentraler Synchronisationspunkt für alle Quell- und Zielsysteme implementiert wird. Hierzu sind die Personendaten verschiedener Systeme auf ein Schema zu konsolidieren und in einem Verzeichnis zusammenzuführen. Für die einzelnen Attribute ist jeweils eine verbindliche führende Quelle zu nennen. Eine Homogenisierung der Topologie soll alle LDAP-Server auf ein Produkt zusammenzuführen, so dass diese sich mittels LDAP-eigener Synchronisationsmechanismen in Echtzeit untereinander aktualisieren können. Zielsysteme sollen die LDAP-Server direkt als Datenquellen nutzen oder, wo dies nicht möglich ist, durch andere Mechanismen möglichst unmittelbar provisioniert werden, um weitestgehend auf den Einsatz von Skriptlösungen und den mit ihnen verbundenen gravierenden Nachteilen verzichten zu können. Wegen neuer Anforderungen im Zuge der Virtualisierung und der Vielzahl im Einsatz befindlicher Windows-Klienten ist die Anbindung eines Active Directory- Servers als integraler Bestandteil des Meta-Directories anzusehen. Darauf aufbauend werden Personen über Rollen- und Rechtedarstellungen im Nutzereintrag effektiv mit allen Zugangsberechtigungen versorgt und Gruppen zugeordnet. Ein einfaches Umschalten eines Attributes kann so Personen aus den verschiedensten Gruppen löschen und sie ohne Zeitverzug wieder hinzufügen. Gleiches gilt für ähnliche Anwendungsfälle wie z.b. den Wechsel des Fachbereiches und damit verbundener Berechtigungen. So werden alle eine Identität betreffenden Informationen im Eintrag der Entität selbst gespeichert, Gruppenzugehörigkeiten wandeln sich von separat gehaltenen, die Person zusätzlich beschreibenden Informationen, zu Abbildungen von direkt an die Personen geknüpften Eigenschaften. Unterschiedliche hochschulspezifische Ziele werden im Folgenden beschrieben. 2.1 Soll-Zustand HS Harz Anstatt dass Zielsysteme direkt auf das Metadirectory zugreifen, soll eine für alle Institute und Einrichtungen zugängliche Infrastruktur aus drei LDAP-Servern an das zentrale Meta-Directory angeschlossen werden. Dies erhöht die Ausfallsicherheit auch in Wartungsfällen und ermöglicht eine Trennung der Aufgabenverteilung von Datenimport, Datensicherung sowie Datenverteilung. Zudem kann der Metadirectory-Kern mit seinen Replikanten in ein abgeschottetes internes Verwaltungsnetz verlegt werden, welches durch geeignete Maßnahmen vor Zugriffen aus öffentlichen Netzen geschützt ist. Weder natürliche Personen noch Fachanwendungen erhalten direkten Zugriff auf den Metadirectory-Kern, sondern nutzen die untergeordneten LDAP-Server im öffentlichen Bereich. HISinOne wurde als Hauptdatenquelle zum Aufbau des IDM festgelegt. Das Änderungsmanagement folgt klar definierten Workflows von HISinOne und erfolgt zentral an den führenden Quellen. Die Datenerfassung in die HIS-PSV-DB geschieht durch HIS- Projekt , OvGU Magdeburg / FH Harz

70 66 Fachanwendungen im Personal- bzw. Studentenamt, gleiches gilt für die spätere Datenpflege. Als weitere Quelle für durch den Nutzer selbst setzbare Attribute kommt eine Weboberfläche meinaccount hinzu, über die Personen Ihre persönlichen Angaben direkt pflegen können. Auch die Selbstauskunft zur Einsicht über die zur eigenen Person gespeicherten Daten ist hier angesiedelt. Zusätzliche Daten für Telefonie, Fax und Mailing werden durch eine im Rechenzentrum zentralisierte Administration direkt auf dem LDAP eingepflegt. Für Gäste existieren spezielle Accounts, die auf Anfrage durch das Rechenzentrum freigeschaltet werden. Die stärkere Verwendung dynamischer Gruppen (s. 3.4) soll die angesprochenen Probleme der inhaltlichen Modellierung elegant lösen, da dieser Gruppentyp anhand von Attributen der Person gebildet wird. Gäste TK HIS RZ MetaDir ADS int LDAP endsys endsys meinacc Bild 3: Vereinfachte künftige Serverstruktur an HS Harz 2.2 Soll-Zustand OvGU Magdeburg Die Hauptquelle für das Metaverzeichnis wird das HIS-System bleiben. Zu den bis jetzt synchronisierten Studentendaten werden auch Mitarbeiterdaten kommen. Der Umstieg auf HISinOne (mit geplanter LDAP-Schnittstelle) wird in naher Zukunft nicht stattfinden. Bis dahin werden die Daten aus der Verwaltung wie zuvor durch Skripte eingepflegt. Eine weitere Informationsquelle soll in Zukunft ein Account-Service der OvGU Magdeburg sein. Dort werden Nutzer die Möglichkeit haben, eigene bestimmte Attribute zu ändern oder hinzuzufügen. Es wurde ein neues Konzept für alle externe Nutzer/Gäste entwickelt - ein Web-Portal mit einer kleinen DB zur temporären Datenspeicherung. Die Nutzer registrieren sich dort. Ein Mitarbeiter der Bibliothek oder im IT-Service-Point prüft die Nutzerdaten und schaltet den Account frei. Bei dem Verfahren müssen die Nutzer auch ins URZ kommen, aber die Eintragung der Daten im Vorfeld spart Zeit und die externen Bibliotheks- Projekt , OvGU Magdeburg / FH Harz

71 67 nutzer bleiben nicht mehr anonym. Die ursprüngliche Idee stammt von der TU Braunschweig [12]. Das Portal wird derzeit getestet. Als eine neue Quelle für Telefonnummern und Räume soll jetzt die Telefonanlage (TK) dienen. An der OvGU wird gerade eine neue VoIP-Anlage installiert, deren User- Management mit der zentralen Nutzerverwaltung synchronisiert werden soll. Das System benutzt ein proprietäres Verzeichnis, um die Nutzerdaten zu speichern. Dazu gehören: Name, Vorname, , Abteilung, Telefonnummer usw. Die Daten (außer Telefonnummern) sind Personendaten, die schon von der Uni-Verwaltung erfasst und in das URZ-LDAP-Verzeichnis provisioniert wurden. Zurzeit wird an einer Lösung gearbeitet, die folgendes gewährleisten soll: nach Bedarf die Nutzerdaten aus dem URZ-LDAP ins VoIP-LDAP holen (Synchronisationsschlüssel wird der Account) in der VoIP-Anlage werden die Daten mit den Telefonnummern erweitert. Diese neuen Datenelemente sollen dann zurück ins URZ-LDAP geschrieben werden. Die Änderungen, die beim Nutzer anfallen (Namenänderung, Abteilungswechsel, Ausscheitern) sollen zum VoIP-LDAP provisioniert werden Die Schwierigkeiten, die noch vorhanden sind, sind z. B. die korrekte Verarbeitung der Nutzer, die mehrere Arbeitsverhältnisse haben (mehrere Kostenstellen). Im URZ existiert pro Identität nur ein Account. In der Telefonanlage sollen mehrere Accounts für eine Identität mit mehreren Kostenstellen implementiert werden. An einer Lösung wird gearbeitet. Accountservice HIS TK IT-Service-Point/ Kontaktbüro MetaDir (LDAP) ADS endsys endsys Bild 4: Vereinfachte künftige Serverstruktur an OvGU Magdeburg 3 Umsetzung der Zielvorstellung Um die Projektarbeit zeitgemäß und effektiv zu gestalten, wurde zunächst eine Recherche über existierende Nutzerverwaltungen an unterschiedlichen Hochschulen durchgeführt. Projekt , OvGU Magdeburg / FH Harz

72 68 Bei der Analyse wurden Aspekte der Softwareverwendung und der jeweiligen Erfahrungen, der Varianten des Aufbaus des Verzeichnisbaumes (Directory Information Tree - DIT) und der Form der Rollen- und Rechtemodellierung im Verzeichnis berücksichtigt. 3.1 Softwareverwendung Die Hochschulen in Deutschland benutzen sehr unterschiedliche Programmpakete für Identity Management-Systeme, wobei ca. 80 % dedizierte Verzeichnisdienste gegenüber datenbankgestützten Lösungen nutzen. Ca. 20 % haben eigene Identity Management-Systeme auf Basis von kostenlosen Produkten (OpenLDAP, OpenDS, 389 DS und andere) entwickelt, statt auf kommerzielle Lösungen zurückzugreifen. Schon in der Vorhabenbeschreibung dieses Projektes wird explizit die Absicht erklärt, zum Aufbau eines neuen Nutzerverwaltungssystems einen LDAP-basierten Verzeichnisdienst einzusetzen. Der Vorteil gegenüber herkömmlichen Datenbanken besteht darin, dass LDAP einen Standard bietet, den viele Anwendungen von Haus aus unterstützen und der speziell für die schnelle Beantwortung von Anfragen konzipiert wurde. Die Nutzung proprietärer kommerzieller Systeme schied von vornherein aus, da diese Lösungen neben erheblichen Kosten nicht akzeptable Abhängigkeiten und Nachfolgeaufwendungen erzeugen. Die Erfolge selbst entwickelter Systeme auf OpenSource- Basis motivieren zum Einsatz solcher Systeme mit offenen unveränderten Standards. Nach Testinstallationen der drei OpenSource-Produkte OpenDS, OpenLDAP und CentOS DS fiel die Wahl an der HS Harz aufgrund der starken Unterstützung dynamischer Gruppen sowie des guten Supportes auf OpenDS, während an der OvGU Magdeburg aufgrund der weiten Verbreitung sowie dem jahrelangen Einsatz im eigenen Haus zugunsten von OpenLDAP entschieden wurde. Später erfolgte an der HS Harz ein Umstieg auf den OpenDS-Fork OpenDJ, da der Großteil der Entwickler das Projekt unter dem Dach von ForgeRock fortführen wollte. 3.2 Aufbau des Verzeichnisbaumes Informationen werden in LDAP in Form einer hierarchischen Baumstruktur (DIT) gespeichert. Der Aufbau des DITs hat Einfluss auf die Funktionalität des Verzeichnisses und ist von den jeweiligen Anforderungen und der Größe des Unternehmens abhängig. Beim Aufbau des Verzeichnisbaums sollte man sich weniger an der eigentlichen Organisationsstruktur, sondern mehr an den verschiedenen Objekttypen orientieren und Überlegungen zu späteren Referrals und Access-Control-Rules miteinbeziehen. Der allgemeine Konsens lautet, den DIT so flach wie möglich zu halten, da tiefe Verzweigungen keine wirklichen Vorteile bieten. Nach der Analyse des Vorgehens anderer Hochschulen und Empfehlungen aus [9][3][6][7][8] wurde entschieden, für Personen- und Gruppeneinträge sowie die Organisationsstruktur jeweils einen eigenen Teilbaum anzulegen, und die Objekte dort so flach wie möglich abzulegen. Projekt , OvGU Magdeburg / FH Harz

73 LDAP Schema Die Analyse der an anderen Hochschulen implementierten Schemata zeigt, dass meist auf standardisierte Objektklassen zurückgegriffen werden kann, wobei dort fehlende aber zwingend erforderliche Eigenschaften durch selbst geschaffene Schemaerweiterungen ergänzt werden. Daher gab es verschiedene Versuche, einen Standard für eine erweiterte Personenbeschreibung im Hochschulumfeld zu etablieren HIS GmbH mit hisperson, RSA mit naturalperson, Terena mit ScHAc und das DFN mit dfneduperson. Da hisperson mit dem ZKI-AK Verzeichnisdienste abgestimmt wurde und von den HIS-Anwendungen bedient wird, ist es als Quasi-Standard im deutschen HS-Bereich anzusehen. [4][5] Beim Entwurf eines eigenen Schemas wurde generell der Empfehlung von Herrn Gietz von DAASI International gefolgt, inetorgperson und eduperson als Grundlage zu verwenden und die Nachteile von eduperson durch Nutzung von hisperson auszugleichen. [4][5] Da festgestellt wurde, dass nicht alle gewünschten Informationen in hisperson gespeichert werden können, kommen hochschulspezifische Erweiterungen für verschiedene Passwort-Hashes und die Rechteabbildung zum Einsatz. Diesen Erweiterungen der ansonsten homogenen Struktur kommt allerdings nur für interne Zwecke Bedeutung zu, so daß nach außen hin eine einheitliche Struktur nutzbar ist (vgl. 4.1 Shibboleth). Diese erfüllt die Architekturempfehlung zur Zentralisierung der Namens- und Verzeichnisdienste des Ministerialblattes 34/2008, Anlage 2 zur IT-Strategie [10] in Bezug auf personenbeschreibende Attribute. Wo nötig, kann das Schema später um Objektklassen zur Beschreibung anderer strukturbildender Objekte oder Blattobjekte/Ressourcen erweitert werden. 3.4 Gruppen-, Rollen- und Rechtekonzept Da LDAP zur Abbildung einfacher Hierarchien und nicht starker relationaler Abhängigkeiten konzipiert wurde, kann die Abbildung eines komplexen Rollen- und Rechtesystems sehr aufwendig werden. Daher werden meistens nur einfache Rollen in Form von Gruppen oder Personenattributen genutzt. Die Empfehlung von Herrn Gietz/DAASI International lautet, im simpelsten Fall Rollen durch einfache Attributtypen zu modellieren. Falls weitergehende Informationen zu Rollen benötigt werden, wird die Verwendung von dynamischen Rollen (Verweis in Person auf Rollenobjekt) vorgeschlagen; erst bei Eingrenzungen von Rollen sollte auf einen Rolleninstantiierungsbaum zurückgegriffen werden.[4][5] Diese Empfehlung ist vergleichbar mit der Entwicklung des aktuellen IntegraTUM-Schemas der TU München in der Version 3, das sich aus einer ursprünglich hierarchisch aufgebauten Struktur entwickelt hat und nun alle eine Person betreffenden Rollendaten in der Person selbst hält. [3] Da das Rollenkonzept an beiden Hochschulen weder hierarchisch aufgebaut sein muss, noch weitergehende Informationen oder Einschränkungen zu Rollen benötigt Projekt , OvGU Magdeburg / FH Harz

74 70 werden, wird der Empfehlung von DAASI International gefolgt, einfache Rollen durch Attribute eines Personeneintrags darzustellen und so auf explizite Rollenobjekte zu verzichten. Eine direkte Rechtezuweisung findet nicht im Directory Server statt, sondern kann anhand der Rollen auf Anwendungsebene durchgeführt werden. Gruppenzugehörigkeiten sollen ebenso durch Attribute modelliert werden, um sich von den Nachteilen statischer Gruppen zu lösen. Dies führt zu einer Gleichwertigkeit und praktischen Austauschbarkeit von Gruppen und Rollen; sie verschmelzen quasi zu ein und demselben Objekt. An der OvGU Magdeburg stellt die eigenentwickelte Objektklasse mdperson zur Modellierung von Gruppen/Rollen das mehrwertige Attribut mdservices zur Verfügung, das sowohl allgemeine Rollen als auch Zugangsberechtigungen für einzelne Dienste und Server hält. Statische Gruppen sollen nur dort zum Einsatz kommen, wo Endsysteme nicht korrekt mit der attributbasierten Lösung arbeiten können (z.b. ACLs). Viele Gruppenzugehörigkeiten werden bereits durch allgemeingültige Attribute impliziert, so dass ein erhöhter Administrationsaufwand vermieden werden kann; weitere Gruppenzugehörigkeiten werden an der HS Harz im Attribut ou (organizationalunit) abgelegt. Damit Klienten Zugehörigkeiten nicht erst aus Attributen eruieren müssen, werden an der HS Harz dynamische Gruppen eingesetzt, welche die Zugehörigkeitskriterien an nur einer zentralen Stelle definieren und übersichtlich darstellen. Durch aufsetzende virtuelle statische Gruppen, welche den dynamischen Suchfilter serverseitig auflösen, bietet OpenDJ so auch älteren Klienten automatisch generierte, standardisierte Ansichten von Mitgliederlisten. Um Mitglieder ausschließen zu können, obwohl ihre allgemeingültigen Attribute der Gruppendefinition genügen, oder Mitglieder hinzufügen zu können, deren Attributwerte keine Mitgliedschaft begründen, kommt außerdem eine hochschulspezifische Schemaerweiterung hinzu, deren Attribute im dynamischen Suchfilter mit ausgewertet werden können, so dass Klienten von vornherein bereinigte Listen erhalten. Um direkte Suchen nach Attributswerten von Mitgliedern auf Gruppen oder boolsche Gruppenkombinationen einschränken zu können (group scoping), werden aus den Zugehörigkeiten zu statischen und dynamischen Gruppen automatisch forward references gebildet. 3.5 Zusammenfassung der Umsetzung Entsprechend der oben genannten Ausführungen ergibt sich folgender, für beide Hochschulen gleicher Aufbau: Die Basisklasse aller Personeneinträge ist hisperson. Personeneinträge können um weitere Klassen für technische Attribute erweitert werden. Alle Personen liegen flach im DIT-Teil ou=person. Projekt , OvGU Magdeburg / FH Harz

75 71 Alle Gruppen liegen flach im DIT-Teil ou=groups und referenzieren sich nicht gegenseitig. Gruppenzugehörigkeiten und Rollen werden durch Attribute eines Personeneintrages modelliert. Die eigentliche Rechtevergabe erfolgt, wo nötig, auf Anwendungsebene. Durch die verschiedenen Möglichkeiten der jeweils verwendeten Produkte gibt es leichte Unterschiede in der Anwendung des Gruppen/Rollen-Konzeptes: HS Harz: Die externe Darstellung von Gruppen und Rollen erfolgt durch dynamische Gruppen. Zur Kompatibilitätssicherung werden virtuelle statische Gruppen aufgesetzt. Nur wo zwingend notwendig, kommen echte statische Gruppen zum Einsatz. Forward references in Form von operationellen Attributen werden aktiviert. Ein Mechanismus zum expliziten member include/exclude wird implementiert. OvGU Magdeburg: Wo nötig, z.b. in ACLs, werden Gruppen und Rollen durch statische Gruppen realisiert. Als dritte Möglichkeit hat sich die Verwendung von Kind-Einträgen bewährt. 4 Anschluss weiterer Systeme Neben den untergeordneten LDAP-Servern bedürfen noch weitere Systeme des Anschlusses an das Metadirectory als Datenquelle; so z.b. ein System zur Unterstützung von Kooperationen und Föderationen, das Mail-System sowie die Bibliotheksverwaltung und ein Active-Directory-Server. 4.1 Shibboleth Kooperations- und Föderationspartner erhalten aus Sicherheits- und Datenschutzgründen keinen direkten Zugriff auf die internen LDAP-Strukturen. Um einen möglichst einfachen Austausch notwendiger Daten zu ermöglichen, wurde ein Shibboleth-Dienst nach Vorgabe des DFN-AAI implementiert. Dieser bezieht alle benötigten Attribute aus der homogenisierten LDAP-Struktur, ohne auf hochschuleigene Erweiterungen zurückgreifen zu müssen. Projekt , OvGU Magdeburg / FH Harz

76 72 Der Vorteil eines zentralen Identity Management-Systems auf LDAP-Basis, nämlich die einfache Anbindung von den Standard unterstützenden Anwendungen, die so ohne eigene Datenhaltung auskommen, kann hier voll ausgespielt werden Grundsätzliches Verfahren Shibboleth ist ein Verfahren zur verteilten Authentifizierung und Autorisierung für Webanwendungen und Webservices und funktioniert als "Single-Sign-On"-System (SSO). Die Shibboleth-Software besteht aus zwei Teilen, wobei optionale noch eine Dritte hinzukommen kann: Identity Provider (IdP) in der Heimateinrichtung, der die Verbindung zum Identity Management-System herstellt und Nutzer authentifiziert. Service Provider (SP) bei Diensteanbietern, der die Authentifizierungsbestätigung und falls nötig noch zusätzliche Attribute vom IdP bekommt und auf Grund dieser Information die Nutzer autorisiert. optionaler Lokalisierungsdienst, der Heimateinrichtungen fremder Nutzer lokalisieren kann ( WAYF = Where Are You From ) Die Anmeldung durch Shibboleth SSO besteht in der Regel aus folgenden Schritten: 1. Authentifizierung des Nutzers Bei Zugriff auf eine von Shibboleth geschützte Webanwendung wird der Browser zur Authentifikationsanfrage des konfigurierten IdP weitergeleitet. Sollen auch fremde Nutzer Dienste in Anspruch nehmen dürfen, erfolgt durch den Lokalisierungsdienst eine Weiterleitung an die Heimateinrichtung. Bei der Anmeldung mit "Nutzername und Passwort" wird die Authentifizierung durchgeführt. Hier kann LDAP Shibboleth als Authentifizierungsautorität dienen. Die geschützte Anwendung bekommt dann vom Identity Provider eine Zusicherung, dass es sich um diesen Nutzer handelt. Dabei wird keine Information über den Nutzer mitgeliefert, so dass er für die Anwendung anonym bleibt. 2. Generierung eines Browser-Tokens (Cookies) Der Webbrowser des Nutzers erhält einen Token, welcher erlaubt, ohne erneute Authentifizierung mit anderen Shibboleth-Anwendungen zu arbeiten. Der Token ist für einen bestimmten Zeitraum gültig. Wird der Browser geschlossen, endet auch die Gültigkeit des Tokens. 3. Autorisierung an bestimmten Anwendungen Nach der erfolgreichen Authentifizierung kann der Service Provider beim Identity Provider weitergehende Daten des Nutzers abfragen, die für eine Autorisierung benötigt werden. Auch hier kann LDAP als Attributspeicher für Shibboleth fungieren Föderationen Mit Hilfe von Shibboleth kann ein SSO-System nicht nur innerhalb einer Organisation realisiert werden. Die organisationsübergreifende Zusammenarbeit verschiedener Service Provider und Identity Provider begründet eine Föderation. Projekt , OvGU Magdeburg / FH Harz

77 73 Im Bereich des DFN-Vereins wurde eine deutschlandweite Föderation aufgebaut, die Hochschulen, Bibliotheken, Verlage, Verleger, Software-Anbieter, etc. miteinander verbindet und sich DFN-AAI (Authentifizierungs- und Autorisierungs-Infrastruktur) nennt [14]. Die Teilnahme an der DFN-AAI bringt Hochschulmitgliedern viele Vorteile, verlangt aber ein gut funktionierendes Identity Management-System. Es gibt heutzutage drei Klassen der Verlässlichkeit im DFN-AAI mit verschiedenen Anforderungen an das IDM [15]. Die Anbieter selbst entscheiden, welche Teilnehmer-Klasse Zugang zu Ihren Ressourcen erhalten sollen. Weiterhin sind in Deutschland auch landesweite Föderationen verbreitet, wie zum Beispiel NdS-AAI in Niedersachsen [16] oder ReDI in Baden- Württemberg [17]. Die HS Harz ist bereits Mitglied der DFN-AAI mit der höchsten Verlässlichkeitsklasse. Die OvGU Magdeburg hat inzwischen einen Shibboleth Identity Provider in Betrieb genommen, eine Teilnahme an der DFN-Test-Föderation ist bis zum Jahresende geplant. Schlussendlich soll eine vollwertige Teilnahme als Mitglied der höchsten Verlässlichkeitsklasse angestrebt werden. Ab diesem Zeitpunkt können die momentan IP-basierten Authentifizierungsverfahren auf Shibboleth umgestellt werden. E-Learning SP HS Harz Bibliothek Wiss. DB SP SP IdP WAYF E-Learning Bibliothek SP SP IdP Wiss. DB SP OvGU Bild 5: Schematische Darstellung der Nutzung von Angeboten verschiedener Anbieter Die Zusammenarbeit beider Hochschulen im Rahmen einer Föderation eröffnet für Studenten und Mitarbeiter neue Möglichkeiten der Inanspruchnahme von Diensten. Der Aufbau einer eigenen Föderation gegenüber der DFN-AAI zur Nutzung erweiterter Dienstleistungen könnte weitere Hochschulen aufnehmen und so als Grundstein einer Projekt , OvGU Magdeburg / FH Harz

78 74 bundeslandeigenen Föderation dienen. Allerdings existieren momentan keine Anwendungsfälle, die über festgelegte Kooperationsvorhaben innerhalb der DFN-AAI hinausgehen. 4.2 Bibliotheksverbund (HS Harz) Die Bibliothek der HS Harz nimmt an den Verbunddiensten des OCLC teil. Hierbei stellen in Sachsen-Anhalt die Bibliotheken in Magdeburg und Halle Zugang zu Software für Suche, Mahnungsdruck etc. für Hochschulen im Einzugsbereich bereit, während in Göttingen der zentrale Katalog und die Nutzerverwaltung für verschiedene Bundesländer hinterlegt sind. Dies hat zur Folge, dass bestimmte Nutzerdaten nach Göttingen übermittelt werden müssen. Aktuell wird durch ein Skript jede Nacht eine Datei mit Änderungsanweisungen generiert, diese nach Göttingen übertragen und dort ein Batch- Programm aufgerufen, das die Änderungen einpflegt. Diese Schnittstelle kann bisher leider nur mit Klarschriftpasswörtern umgehen; die Anforderung einer Übernahme gehaschter Passwörter liegt jedoch beim Softwarelieferanten vor. Da bei der Umstellung der Nutzerverwaltung auf ein Metadirectory möglichst auf Klarschriftpasswörter verzichtet werden soll, ist die bisherige Provisionierung der zentralen Nutzerverwaltung in Göttingen in der herkömmlichen Art nicht durchführbar. Alternativ lässt die Schnittstelle ein Anlegen von Nutzern ohne Passwort zu; je nach Konfiguration werden dann die ersten drei Buchstaben des Namens oder das Geburtsdatum als Passwort gesetzt. Nach dem ersten Einloggen können die Nutzer sich selbst ein neues Passwort für ihr OPAC-Konto vergeben. 4.3 Mailsystem An der OvGU musste das Mailsystem mit einer eigenen datenbankgestützten Nutzerverwaltung betrieben werden. Der Aufbau des Meta-Directories und der Wechsel zu einem anderen Mail-Backend-Interface haben uns die Möglichkeit gegeben, diese Situation zu ändern. Der Mail-Relay-Server wird in Zukunft die -Adressen-Prüfung gegen den LDAP-Server durchführen. Die Hauptadresse wird im mail-attribut gehalten, eventuelle Mail-Aliases im Attribut maillocaladdress und Weiterleitungsadressen im Attribut mailforwardingaddress. Die Umstellung auf das Meta-Directory löst viele Probleme, die bisher mit dem Betreiben einer eigenen Datenbank verbunden waren (Dateninkonsistenz, zeitliche Verzögerung bei Änderungen usw.). An der HS Harz ist das Mail-System von je her an einen LDAP-Server angeschlossen. 4.4 Active Directory Microsofts Active Directory leidet an der gleichen Schwäche wie Bibliothekschnittstelle, nur Klarschriftpasswörter verarbeiten zu können. Um heterogene Netzwerkumgebungen provisionieren zu können, ist eine Synchronisation der LDAP-Server mit Active Directory-Servern zwingend notwendig, standardmäßig aber leider nicht gegeben. Da- Projekt , OvGU Magdeburg / FH Harz

79 75 her werden zur Vermeidung von Produktbindungen und zur Kostenersparnis OpenSource-Tools benötigt, die diese Arbeit leisten können. Hier fiel die Wahl auf den - LDAP Synchronization Connector LSC [11], der vielversprechende Ansätze aufweist, aktiv weiterentwickelt wird und Synchronisationen zwischen Datenbanken, LDAP-Verzeichnissen und Dateien (csv) durchführen kann. Da das AD-Attribut unicodepwd nicht gelesen, sondern nur durch Übergabe eines Klarschriftpasswortes gesetzt werden kann, ist die Synchronisation auf die Richtung LDAP->AD beschränkt. Da das Metadirectory auf LDAP-Basis aber das führende System stellen soll, ist diese Richtung ausreichend. Aus Datenschutzgründen sollen Klarschriftpasswörter nur bis zur ersten erfolgreichen Synchronisierung im LDAP gehalten werden, wonach sie gelöscht werden können. Zur Synchronisation muss LSC zunächst einen einfachen Attributsvergleich zwischen Quell- und Zielsystemen durchführen, um Änderungsanweisungen zu generieren. Hierbei bleibt das Passwort zunächst unbeachtet, um unnötige Last zu vermeiden, da aufgrund der unterschiedlichen Formate keine Passwort-Übereinstimmung geprüft werden kann und bei jedem LSC-Durchlauf das Passwort aller Nutzer neu gesetzt werden würde. Im nächsten Schritt wird die Synchronisation des Passwortes von einem fehlgeschlagenen Bind des Nutzer-DN mit dem Klarschriftpasswort gegen AD abhängig gemacht, so dass nur geänderte Passwörter synchronisiert werden. Zum Löschen bereits synchronisierter Passwörter aus LDAP wird ein weiterer LSC-Konnektor nötig, da sich die Rollen nun vertauschen und AD als Quelle fungiert, während LDAP das Ziel der Änderungen darstellt. Aufgrund seiner Architektur ist LSC eher dazu gedacht, einen kompletten Datenbestand über Mittel wie z.b. cron-jobs intervallartig abzugleichen und verfügt über keine Konnektoren, die Quellsysteme permanent auf Änderungen hin überwachen und diese unmittelbar weitergeben würden. Ein LSC-Server, der Änderungen zeitnah mittels PULL einholt, war jedoch in Entwicklung und sollte in aktuellen Releases verfügbar sein. LSC kann das gesetzte Ziel einer Synchronisation zwischen LDAP und AD also grundsätzlich erfüllen, wenn man von den Einschränkungen, Klarschriftpasswörter temporär vorhalten zu müssen und dem Fehlen unmittelbarer replikationsähnlicher Synchronisationsmechanismen, absieht. Da eine direkte Provisionierung des AD durch PSV bevorzugt wird, um Klarschriftpasswörter gänzlich zu vermeiden, ist die erarbeitete LSC-Lösung als Notlösung anzusehen, falls PSV bei Einsatzbeginn weiterhin über keinen AD-Konnektor verfügt. 5 Nachteile der momentanen HISinOne-Version Bei der Verwendung von HISinOne ergeben sich momentan verschiedene Probleme. Alle angesprochenen Punkte sind seit dem , teilweise früher, bei HIS an- Projekt , OvGU Magdeburg / FH Harz

80 76 hängig und bedürfen weiterhin einer Lösung, damit HISinOne als führende Datenquelle betrachtet werden kann. So ist der in ein angeschlossenes LDAP-Verzeichnis exportierte Datensatz nicht allzu umfangreich. Grundsätzlich wird zwar ein Export in das Schema eduperson oder hisperson unterstützt, jedoch wird nur ein kleiner Teil der möglichen Attribute gefüllt. Von den nicht exportierten Attributen werden durch die HS Harz genutzt : description, telephonenumber, facsimiletelephonenumber, displayname, roomnumber, homepostaladdress, labeleduri. Weiterhin kommen aus der Objektklasse posixaccount die Attribute gidnumber und loginshell hinzu. Obwohl in den Standardschemata als auch im Quellcode von HISinOne Felder für bestimmte Attribute vorhanden sind, werden diese nicht ordnungsgemäß bedient. So kann man bei Telefonnummern zwar angeben, ob diese geschäftlich, privat, fax, festnetz oder mobil seien sollen, jedoch werden alle Werte in das LDAP-Feld person.telephonenumber übertragen. Dabei bietet organizationalperson mit facsimiletelephonenumber Platz für die Faxnummer, und inetorgperson mit homephone und mobile Platz für Privatnummern und Handynummern. Das gleiche Bild bietet sich bei den Adressdaten, die alle in organizationalperson.postaladdress abgelegt werden, obwohl inetorgperson mit homepostaladdress Platz für die privaten Adressen bietet. Diverse Anwendungen benötigen weitergehende Attribute, die so in HISinOne nicht existieren, aber aus bestehenden Daten abgeleitet werden können (Attributabhängigkeiten wie z.b. Gruppenzugehörigkeiten). Hierzu wäre allerdings ein Zugriff auf das interne H1-Event-System von HISinOne nötig, um bei Änderungen der Standardattribute in HISinOne weitergehende Änderungen im LDAP-Verzeichnis anstoßen zu können. Auf der HIS-PSV-Tagung am stellte sich heraus, daß die weiteren beteiligten Hochschulen die gleichen Anforderungen haben, weshalb HIS die benötigten Zugriffsarten auf das H1-Event-System eruieren und zur Verfügung stellen wollte. Dieser Punkt ist insofern besonders wichtig, als es zur Zeit keine HISinOne-Konnektoren gibt, die ein Active Directory provisionieren können. Weiterhin existiert kein Mechanismus, Personen- und Nutzerdaten bei Änderungen in HisInOne unmittelbar im Verzeichnis zu aktualisieren, obwohl dieses Verhalten schon seit 2009 propagiert wurde. [13] 6 Zusammenfassung Das Ziel des Projektes, die Entwicklung eines zentralen Metaverzeichnis mit entsprechenden Schnittstellen wurde erreicht. Die in beiden Hochschulen implementierten Prototyp-Verzeichnisse haben gute Ergebnisse geliefert. Die unterschiedlichen Schemata auf den bestehenden LDAP-Servern wurden in ein vereinheitlichtes Schema für das Meta-Directory zusammengeführt. Der Austausch von Verzeichnisdaten wird durch diese Vereinheitlichung und die Homogenisierung der verwendeten Produkte erleichtert und beschleunigt. Änderungen können durch die nun Projekt , OvGU Magdeburg / FH Harz

81 77 nutzbaren Möglichkeiten der Replikation in Echtzeit durch die gesamte LDAP-Server- Infrastruktur propagiert werden, was die Datenkonsistenz beträchtlich erhöht. An der OvGU Magdeburg läuft das System im produktiven Betrieb bereits parallel zur alten Struktur und wird diese demnächst ablösen, sobald die Testphase der automatischen Übernahme von Mitarbeiterdaten abgeschlossen wird. Da die OvGU Magdeburg noch über keine HISinOne-Installationen verfügt, werden die Synchronisationsmechanismen des alten Systems für die Datenübernahme aus der Verwaltung verwendet. Zur Zeit befindet sich das Meta-Directory der HS Harz aufgrund der Anbindungsprobleme von HISinOne nicht im Routinebetrieb. Sind diese überwunden, können die unterschiedlichen Systeme zur Verwaltung von Identitäten und Ressourcen durch eine für alle Institute und Einrichtungen zugängliche LDAP-Server-Infrastruktur, die an das zentrale Meta-Directory angeschlossen ist, ersetzt werden. Die föderative Nutzung ausgewählter Dienste wird bereits durch an beiden Hochschulen funktionierenden Shibboleth-Identity-Provider ermöglicht. Literatur [1] H. Stenzel: Verzeichnisdienste und Identity Management in Hochschulen ein Überblick, Praxis der Informationsverarbeitung und Kommunikation. Band 28, Heft 3, Seiten , 2005 [2] Swen Hasberg, Patrick Odenwald, Thomas Krause: Metadirectory-Lösungen an ausgesuchten Hochschulen. Stand: Juni 2009 [3] Arndt Bode, Rolf Borgeest (Hrsg.): Informationsmanagement in Hochschulen; Springer Verlag, ISBN-13: , Februar 2010 [4] Peter Gietz: Personenschema für das HIS-LDAP-Projekt (Vortragsfolien des Treffens des ZKI AK- Verzeichnisdienste vom ) [5] Peter Gietz: Standardbasierte LDAP- Schemata für Personen- und Organisationsdaten, [6] Netscape Directory Deployment Guide - Directory Tree Design, [ [7] LDAP-Server für X.509-Zertifikate, Markus Grieder,Stephan Zehnder, 19.Mai 2000 [8] IntegraTUM Teilprojekt-Dokumentation Verzeichnisdienste. Version 1072 [ 08_schema-integratum.pdf] [9] Identifiers, Authentication, and Directories: Best Practices for Higher Education Internet2 Middleware Initiative [10] Architekturempfehlung zur Zentralisierung der Namens- und Verzeichnisdienste des Ministerialblattes 34/2008, Anlage 2 zur IT-Strategie [11] [12] [13] His-Magazin 3/2009 : Seite 14, Spalte LDAP : [14] [ [15] [ [16] [ [17] [ Projekt , OvGU Magdeburg / FH Harz

82 78

83 79 Integrierte Forschungsplattform für den Forschungsschwerpunkt Decision Design Gestaltung ökonomischer Prozesse und Institutionen Ausführende Einrichtung(en): Otto-von-Guericke-Universität Magdeburg Projektleiter: Prof. Dr. Joachim Weimann, Otto-von-Guericke-Universität Magdeburg, Universitätsplatz 2, Magdeburg. Prof. Dr. Abdolkarim Sadrieh, Otto-von-Guericke-Universität Magdeburg, Universitätsplatz 2, Magdeburg. Juniorprof. Dr. Stephan Thomsen, Otto-von-Guericke-Universität Magdeburg, Universitätsplatz 2, Magdeburg. Förderung: Dieses Vorhaben wird mit Mitteln der Europäischen Kommission aus dem Europäischen Fonds für regionale Entwicklung (EFRE) im Rahmen der Maßnahme 11.03/41.03 gefördert (FKZ: ). Zusammenfassung Um in der heutigen Forschungslandschaft nicht den Informationsanschluss zu verlieren, sind tiefgreifende Veränderungen der Systeme erforderlich. In diesem Projekt geht es um diese Veränderungen. Es soll eine neue Basis geschaffen werden, mit der die Bereitstellung von experimentellen Daten und die Replizierbarkeit von Experimenten einfach und sicher möglich wird. Darüber hinaus soll erreicht werden, dass die wirtschaftswissenschaftliche experimentelle Forschung stärker vernetz wird und gemeinsames Arbeiten effizienter gestaltet werden kann. Projekt , Otto-von-Guericke-Universität Magdeburg

84 80 Inhaltsverzeichnis 1 Einleitung Die Bedeutung experimenteller Wirtschaftsforschung Die experimentelle Methode Grenzen der experimentellen Methode Kernaufgaben des Projekts Methodische Probleme, die das Projekt lösen soll Das Experimentallabor in Magdeburg, MaXLab Relevanz des MaXLabs Nutzungsmöglichkeiten des MaXLabs Zeitplan Überblick der Arbeitspakete Integrierte Forschungsdatenbank Grundaufbau der Integrierten Forschungsdatenbank Forschungsplattform Experimentalserver Forschungsserver Veröffentlichung der Dateicontainer Zugriff auf Dateicontainer Kooperationsmöglichkeiten Gesamtüberblick Kostenplan Projekt , Otto-von-Guericke-Universität Magdeburg

85 81 1 Einleitung 1.1 Die Bedeutung experimenteller Wirtschaftsforschung In der Ökonomie haben Laborexperimente eine etwa 50-jährige Geschichte und sind aus der ökonomischen Forschungslandschaft nicht mehr wegzudenken. Weltweit existieren Hunderte von Laboren, in Deutschland sind es allein über fünfundzwanzig. Zu den bedeutendsten Laboren der Wirtschaftsfakultäten zählen hierzulande München, Bonn, Mannheim und Magdeburg. Etablierte wissenschaftliche Organisationen repräsentieren die Stärke dieses wissenschaftlichen Forschungssektors. Dazu gehören die Economic Science Association (ESA) sowie die Gesellschaft für experimentelle Wirtschaftsforschung (GfeW), die weltweit älteste Vereinigung experimenteller Ökonomen, die unter anderem von Heinz Sauermann und dem deutschen Nobelpreisträger Reinhard Selten gegründet wurde. Die zunehmende Kooperation mit den Nachbardisziplinen wie der Neuroökonomie, den Psychologen und den Sozialpsychologen sind ein deutliches Zeichen für die Reife und die Bedeutung der experimentellen Wirtschaftsforschung. 1.2 Die experimentelle Methode Im Labor werden Experimente durchgeführt, bei denen die Versuchsteilnehmer unter kontrollierten Bedingungen einfache Entscheidungsprobleme lösen müssen. Mithilfe der Ergebnisse versucht man zu ermitteln, wie Menschen Entscheidungen treffen und wie man dieses Entscheidungsverhalten mit formalen Theorien beschreiben kann. Diese Methode ist universell einsetzbar und kann inhaltlich in drei Bereiche unterteilt werden (Roth, 1987): Speaking to theorists Formale mathematische, insbesondere spieltheoretische Modelle können mithilfe von Laborexperimenten überprüft werden, was mit anderer Empirie nur unzureichend erreicht werden kann. Somit ist es möglich, die Qualität von Theorien zu beurteilen und diese zu optimieren. Searching for facts Laborexperimente helfen bei der Erschließung beobachtbarer Phänomene, zu denen jedoch keine Theorie existiert oder zu der man eine Theorie hat, diese aber nicht das beschreibt, was in der Realität passiert. Weiterhin sind Experimente ein Instrument, um systematisch nach Regularitäten im Verhalten zu suchen, die dann in Theorien Anwendung finden. Whispering in the ears of princes Experimentelle Wirtschaftsforschung kann als nützliche Methode verwendet werden, um politische Entscheidungen zu unterstützen. Projekt , Otto-von-Guericke-Universität Magdeburg

86 Grenzen der experimentellen Methode Da jedes Experiment nur eine singuläre Beobachtung liefert, die nur unter bestimmten Bedingungen gilt, kann diese für sich noch keine Allgemeingültigkeit beanspruchen. Um mithilfe der experimentellen Forschung eine allgemeingültige Aussage treffen zu können, bedarf es einer großen Zahl von Experimenten. Gesucht sind Regularitäten bzw. stilisierte Fakten, für deren Ermittlung an verschiedenen Orten, zu verschiedenen Zeitpunkten und unter ähnlichen Bedingungen experimentell geforscht werden muss. Dies bedeutet, dass im Vergleich zur theoretischen Arbeit die experimentelle Forschung einer viel stärkeren Kooperation der wissenschaftlichen Gemeinschaft bedarf. Es werden zwingend aufeinander aufbauende Experimentserien benötigt, die miteinander im Einklang stehen, um letztlich allgemeingültige Aussagen zu treffen. Dies stellt bestimmte Anforderungen an die Wissenschaftsorganisation, sowohl auf lokaler als auch auf nationaler und internationaler Ebene. Das hier beschriebene Projekt verfolgt das Ziel, die Organisation der experimentellen Forschung signifikant zu verbessern. 1.4 Kernaufgaben des Projekts Um die Möglichkeiten der experimentellen Forschung zu erweitern, bilden folgende Aufgaben den Kern des Projekts: Verbesserung der Reproduzierbarkeit und Replizierbarkeit von Experimenten. Aufbau eines verlässlichen Standards für die Replikation. Aufbau einer Plattform für den Austausch und den Zugang zu Experimentaldaten. 1.5 Methodische Probleme, die das Projekt lösen soll Um die Möglichkeiten der experimentellen Forschung zu erweitern, werden folgende methodische Probleme durch das Projekt gelöst: Transparenz der experimentellen Daten Steigerung der Sicherheit hinsichtlich der wissenschaftlichen Befunde. Reproduzierbarkeit und Replizierbarkeit von Experimenten Aufbau eines verlässlichen Standards für die Replikation, die den Zugang zu den Instruktionen, Daten und der Programmierung ermöglicht. Zugriff auf experimentelle Dateien für Forschung und Lehre Aufbau einer Forschungsdatenbank. Kooperationen zwischen Forschern Verbesserung der Strukturen und Reduzierung des organisatorischen Aufwands. Projekt , Otto-von-Guericke-Universität Magdeburg

87 83 Kooperationen zwischen Laboren Verbesserung der Strukturen und der Koordination der Experimente. Koordination von Onlineexperimenten Aufbau einer Plattform zur laborübergreifenden Koordination von Experimenten und Teilnehmern. 2 Das Experimentallabor in Magdeburg, MaXLab Das MaXLab nimmt eine herausragende Stellung innerhalb der wirtschaftswissenschaftlichen Forschung an der Otto-von-Guericke-Universität Magdeburg ein. Auch im deutschen Vergleich der Labore besitzt das MaXLab eine starke Rolle und ist führend in den neuen Bundesländern. Durch die erfolgte Erneuerung der technischen Ausstattung ist das Labor für zukünftige Aufgaben gut gerüstet. Derzeit verfügt das MaXLab über 30 voneinander isolierte Arbeitsplätze, darunter 9 schalldichte Kabinen. Zusätzlich existiert ein Experimentserver (nicht zu verwechseln mit dem Experimentalserver), der lokal als Basis für alle Experimente fungiert. Im Zuge der Erneuerung der Hardware war es zusätzlich möglich, Software zu programmieren, mit deren Hilfe nun eine bessere und schnellere Steuerung des Labors möglich ist. Dadurch konnte die experimentelle Auslastung deutlich gesteigert werden. Der Erfolg dieser Software zeigt sich auch darin, dass mittlerweile drei weitere Labore diese erfolgreich einsetzen. 2.1 Relevanz des MaXLabs Der Aufbau und die zukünftige Pflege einer Integrierten Forschungsdatenbank machen Investitionen in die Erhaltung und kontinuierliche Anpassung des MaXLabs unabdingbar. Die Erzeugung von Forschungsdaten ist ein wesentlicher Bestandteil des vorliegenden Projekts und insbesondere der integrierte Experimentalserver fußt auf den bestehenden Kompetenzen des Labors. Das MaXLab ist die Grundlage für einen erfolgreichen Abschluss der geplanten Aufgaben. Aus diesem Grund nimmt das Labor auch eine Sonderstellung bei der Bearbeitung des Projekts ein. Es bildet die starke Basis für die nächsten Schritte. 2.2 Nutzungsmöglichkeiten des MaXLabs Im Vergleich deutscher Experimentallabore hat das MaXLab auch deshalb eine starke Position, weil es eine Fülle an Möglichkeiten für Experimente bietet. Neben den klassischen Computerexperimenten bestehen folgende weitere Optionen: Experimente mit Audio: Die Arbeitsplätze verfügen über Headsets Experimente in Großgruppen bis zu 80 Teilnehmern: Das Labor verfügt zusätzlich über 50 mobile Arbeitsplätze Experimente im Hörsaal mithilfe der mobilen Arbeitsplätze Projekt , Otto-von-Guericke-Universität Magdeburg

88 84 Experimente mit Video- und Audiokommunikation: Eine spezielle Aufnahmesoftware wurde eigens für das Labor entwickelt Experimente mit großen Teilnehmerzahlen: das MaXLab verfügt über eine der größten und fortschrittlichsten Teilnehmerdatenbanken deutschlandweit Experimente mit zusätzlichen Befragungen: Das Labor besitzt einen eigenen Onlinebefragungsserver 3 Zeitplan Bild 1: Zeitplan, Stand: Ende November 2011 Projekt , Otto-von-Guericke-Universität Magdeburg

89 85 Wie im genehmigten Zeitplan vorgesehen, befindet sich das Projekt am Anfang von AP4, dem Aufbau des integrierten Experimentalservers. Die Arbeitspakete 1 bis 3 wurden den Anforderungen entsprechend durchgeführt und erfolgreich abgeschlossen. Nach der Kündigung von Herrn Thiel, läuft die Suche nach einem Ersatz. Eine diesbezüglich endgültige Entscheidung steht noch aus. 3.1 Überblick der Arbeitspakete Bild 2: Überblick der Arbeitspakete Projekt , Otto-von-Guericke-Universität Magdeburg

90 86 4 Integrierte Forschungsdatenbank 4.1 Grundaufbau der Integrierten Forschungsdatenbank Bild 3: Grundaufbau der Integrierten Forschungsdatenbank Die integrierte Forschungsdatenbank gliedert sich grundlegend in die Bereiche Forschungsplattform, Experimentalserver und Forschungsserver. Alle drei Bereiche stehen miteinander in Verbindung und ergänzen sich gegenseitig. Eine isolierte Nutzung jedes einzelnen Bereichs ist ebenfalls möglich. Die Forschungsplattform erfüllt dabei folgende Grundaufgaben: Bildung von Kooperationen Arbeiten in virtuellen Gruppen Projektorientiertes Vorbereiten von Experimenten und gemeinsames Sichten und Auswerten der Experimentsdateien Die Ziele der Forschungsplattform sind: Verbesserung der gemeinsamen Forschungsarbeit Verbesserung der Verwaltung von Projekten und der Vorbereitung von Experimenten Der Experimentalserver erfüllt dabei folgende Grundaufgaben: Durchführung von Experimenten und Befragungen Nachhaltige Veröffentlichung der gesammelten Daten und der Experimentsdateien Das Ziel des Experimentalservers ist: Standardisierung und Modularisierung von (Online-)Experimenten und Befragungen Durchführung von überregionalen Experimenten Der Forschungsserver erfüllt dabei folgende Grundaufgaben: Sammelstelle für Experimentsdateien weltweit Zugriff auf diese Dateien Nutzung (im Idealfall) auf dem Experimentalserver Projekt , Otto-von-Guericke-Universität Magdeburg

91 87 Das Ziel des Forschungsservers ist: Sicherung der Reproduzierbarkeit von ökonomischen Experimenten Entwicklung neuer Kooperationen 4.2 Forschungsplattform Die Forschungsplattform ermöglicht es Wissenschaftlern, projektorientiert in Kommunikation zu treten, Experimente zu planen, Ideen und Daten auszutauschen, ihre Forschung zu verwalten und zu organisieren. Die Forschungsplattform bildet die Basis, um Experimente vorzubereiten, gesammelte experimentelle Daten zu sichten und auszuwerten. Zum Projektende besteht die Möglichkeit die Experimentsdateien zu veröffentlichen. Die projektorientierte Kommunikation beinhaltet unter anderem eine gemeinsame Termin- und Teamkoordination (Schnittstelle zu Microsoft Outlook ( und Googl ( Aufgabenplanung und den Austausch von Dokumenten (Schnittstelle zur Dropbox ( Schnittstelle zum Experimentalserver: Innerhalb eines Projekts ist es möglich, Experimente zu planen und vorzubereiten und nach dem Experiment die Auswertung zu beginnen. Schnittstelle zum Forschungsserver: Den Abschluss eines Projekts bildet die Veröffentlichung der Experimentsdateien, wodurch sowohl die Sicherung der Reproduzierbarkeit von ökonomischen Experimenten als auch der Zugriff auf diese Dateien gewährleistet wird. 4.3 Experimentalserver Der Experimentalserver teilt sich in zwei Unterkategorien: Zum einen in Durchführung von Experimenten und zum anderen in Durchführung von Befragungen. Die erste Unterkategorie beinhaltet Onlineexperimente sowie Experimente im Labor. Diese werden standardisiert und einheitlich über den Experimentalserver koordiniert und durchgeführt. Weiterhin ermöglicht eine globale Teilnehmerdatenbank die Durchführung überregionaler Experimente. Um den Anforderungen eines modernen Labors gerecht zu werden, benötigt ein Teilnehmerverwaltungssystem und ein Experiment-Koordinationssystem eine Fülle von Funktionen und Lösungen. Durch die jahrelange Erfahrung mit der Koordination von Experimenten sind wir hervorragend aufgestellt, um die Vielzahl der benötigten Funktionen zu integrieren und zugleich die möglichen Schwachstellen abzustellen. Zu den wichtigsten Funktionen gehören: Automatisierte Registrierung neuer Teilnehmer und Erfassung einer Vielzahl persönlicher Daten Unterbindung doppelter oder falscher Registrierungen Projekt , Otto-von-Guericke-Universität Magdeburg

92 88 Verwaltung der Teilnehmer und der Experimentatoren Sicherheit der Daten der Teilnehmer Reaktivierungsmechanismen, um die Aktualität des Teilnehmerdatenbestandes zu gewährleisten Koordination von Experimenten bzw. Sessions innerhalb von Experimenten Zuordnungsmechanismen der Teilnehmer zu möglichen Experimenten Terminkoordination eines Labors Koordination von Experimenten auf freie Termine in allen angeschlossenen Laboren anstatt nur auf lokaler Ebene Versendung von Einladungs- s an die Teilnehmer und Koordination der Teilnehmer auf die verfügbaren Experimente Nachbearbeitung von Experimenten Einbindung von unterschiedlichen Templates für die Registrierungsseite Entwicklung von Mechanismen zur Eindämmung krimineller Aktivitäten durch die Teilnehmer Das neue Teilnehmerverwaltungssystem und Experiment-Koordinationssystem soll ein bestehendes, in die Jahre gekommenes System ablösen. Das bestehende System ist bei weitem nicht mehr zeitgemäß und bremst die Forscher massiv aus. Es offenbart große Sicherheitslücken und verursacht regelmäßig hohe Wartungskosten. Ein neues System wird in der experimentellen Wissenschaft großen Zuspruch erfahren. Bei der zweiten Unterkategorie, der Durchführung von Befragungen, geht es im Wesentlichen um statistische Erhebungen mit einem universitätsweiten, einheitlichen Auftreten und um eine Standardisierung der Projekte. Dies ermöglicht den reibungslosen Export und Import aller Daten und somit die Reproduzierbarkeit. 4.4 Forschungsserver Der Forschungsserver unterteilt sich in die Veröffentlichung von experimentellen Dateien und den Zugriff auf diese Dateien Veröffentlichung der Dateicontainer Im Wesentlichen geht es um die Speicherung und Bereitstellung von Experimentsdateien (auch Dateien der Befragungen). Dazu gehören insbesondere solche, die für die Reproduzierbarkeit von Experimenten notwendig sind sowie alle Dateien, die während eines Experiments gesammelt werden. Zu den wichtigsten Dateien gehören: Instruktionen z-tree-programm (Fischbacher 1998) oder ähnliche Das programmierte Experiment Erhobene Daten als Stata/Spss/Xlsx/MRT-Files Projekt , Otto-von-Guericke-Universität Magdeburg

93 89 Stata/Spss: Do-Files Screenshots Working Paper Die genannten Dateien werden nachhaltig auf dem Forschungsserver abgelegt und veröffentlicht. Dabei erhält jede Veröffentlichung einen permanenten Link (z.b. zu den Dateien, um zu gewährleisten, dass veröffentlichte Links in Journalen auch noch nach Jahren aufgerufen werden können. Journale wiederum können ihre Glaubwürdigkeit dadurch erhöhen, indem sie die Veröffentlichung der Daten zur notwendigen Bedingung für eine Publikation machen. Weiterhin ermöglicht der Zugriff auf die Daten auch Gutachtern/Editoren einen besseren Einblick in die Forschungsergebnisse. Die Speicherung der experimentellen Dateicontainer auf dem Forschungsserver kann sowohl direkt über die Forschungsplattform aus dem Projekt heraus erfolgen als auch isoliert von den anderen Bereichen der Integrierten Forschungsdatenbank als Gast ohne Registrierung. Alle eingereichten Veröffentlichungen auf dem Forschungsserver durchlaufen automatisch eine Sicherheitskontrolle. Dabei werden die Inhalte aller Dateien auf gelistete Worte geprüft und gegebenenfalls automatisch vom Server gelöscht. Auf die automatische Kontrolle folgt eine manuelle Qualitätskontrolle aller neuen Einreichungen durch ausgewählte Gutachter Zugriff auf Dateicontainer Erfolgreich veröffentlichte experimentelle Dateien stehen sofort allen Nutzern zur Verfügung. Umfangreiche Suchmöglichkeiten ermöglichen ein leichtes Auffinden der Datenbankeinträge. Im Idealfall ist es möglich, die Experimentsdateien auf dem Experimentalserver zu nutzen und Experimente zu reproduzieren. Im Ausweichfall erfolgt die Reproduktion auf dem eigenen Computer oder in einem beliebigen Experimentallabor. Der unkomplizierte Zugriff auf die Experimentsdateien erleichtert mögliche neue Kooperationen, und die Schnittstelle zur Forschungsplattform stellt alle nötigen Funktionen bereit, um die Kooperation zu vertiefen. 4.5 Kooperationsmöglichkeiten Mögliche Kooperationsmöglichkeiten bestehen im Bereich der Forschungsplattform mit dem Forschungsportal Sachsen-Anhalt. Des Weiteren existiert eine Kooperationsanfrage seitens des Amts für Statistik in Sachsen-Anhalt bzgl. der Nutzung des Experimentalservers. Positives Interesse zum Forschungsserver besteht vom Center for Behavioral Brain Sciences (CBBS). Vorstellungen des Projekts in Kreisen der GfeW oder der ESA sind ebenfalls auf großes Interesse gestoßen und grundsätzlich bestehen Kooperationsmöglichkeiten zu allen Forschungseinrichtungen des Landes, um beispielsweise die Teilnehmerdatenbank zu erweitern oder anderen die Durchführung von Experimenten ohne lokales Labor zu ermöglichen. Projekt , Otto-von-Guericke-Universität Magdeburg

94 Gesamtüberblick Bild 4: Gesamtüberblick der Integrierten Forschungsdatenbank Projekt , Otto-von-Guericke-Universität Magdeburg

95 91 5 Kostenplan Änderungen am Kostenplan sind wie beantragt bewilligt worden. Alle Ausgaben wurden innerhalb des zur Verfügung stehenden Budgets durchgeführt. Eine Übersicht der Gesamtausgaben ist der Tabelle zu entnehmen. Jahr Personalkosten Sachmittel Gesamt Plan (geändert) , , , gezahlt , , ,00 Ist Ausgaben , , ,49 Plan (geändert) , , , gezahlt , , ,93 Ist Ausgaben , , ,31 Plan (geändert) , , ,00 Plan (geändert) einschl. Ausg.rest , , , gezahlt , , ,26 Restabforderung für , , ,40 Ist Ausgaben per , , , Plan , , , Plan , , ,00 Tabelle 1: Kostenplan, Stand Anträge auf Umwidmung von Personalmitteln für einen wissenschaftlichen Mitarbeiter in Personalmittel für wissenschaftliche Hilfskräfte in Höhe von 3.669,01 Euro (10-12/2011) und auf Übertragung nicht verausgabter Mittel in das Jahr 2012 wurden gestellt. Noch ohne Rückmeldung. Literatur [1] Roth, Alvin E. "Laboratory Experimentation in Economics," Advances in Economic Theory, Fifth World Congress, Truman Bewley, editor, Cambridge University Press, , (Preprinted in Economics and Philosophy, Vol. 2, , 1986.) [2] Fischbacher, Urs (1998): z-tree: Zurich Toolbox for Readymade Economic Experiments. Instruktionen für Experimentatoren, mimeo, University of Zurich. Projekt , Otto-von-Guericke-Universität Magdeburg

96 92

97 93 Aufbau eines Online-Supportnetzwerkes für Technologietransfer und öffentliche Verwaltung Ausführende Einrichtung(en): Otto-von-Guericke-Universität Magdeburg Projektleiter: Dr.-Ing. habil. Sylvia Springer, Technologie-Transfer-Zentrum, Otto-von-Guericke-Universität Magdeburg, Magdeburg). Förderung: Dieses Vorhaben wird mit Mitteln der Europäischen Kommission aus dem Europäischen Fonds für regionale Entwicklung (EFRE) im Rahmen der Maßnahme 11.03/41.03 gefördert (FKZ: ). Zusammenfassung Das Projekt hat die Zielstellung, die Möglichkeiten des online-supports zur Verbesserung des Technologietransfers zu analysieren und Erfahrungen abzuleiten, inwieweit solche Systeme zur Verbesserung der Kundenzufriedenheit eingesetzt werden können. 1 Vorgehensweise und erreichte Ziele im Projekt 1.1 Softwareanalyse Das Projekt wurde entsprechend Arbeitsplan abgewickelt. In der ersten Arbeitsphase bestand der Schwerpunkt in einer Analyse von online-support-software und dem Vergleich des bereits seit Projektbeginn vorhandenen Systems der Firma NTR Global. Hierbei wurden folgende Systeme untersucht und verglichen: AdobeConnectNow, ArtoLogik, BeamYourScreen, conference-tv, CSN, EcholoN, fastviewer, i-net Software, islonline, kayako, Liveperson, LogMeIn, ManageEngine ServiceDesk Plus, netviewer, Nilex, Novomind TrueTalk, ntr, Numara FootPrints, pcvisit EasySupport, Provide Support, Quadriga Informatik, Skymol, Topdesk, Webex, xsaltec, citricle, u.a.. Zu den meisten Systemen wurden Testzugänge beantragt oder online- Demonstrationen besucht. Diese Systeme können in 3 Rubriken geteilt werden: Ticket-Systeme Chat-Systeme Konferenz-Systeme Für den online-support, wie er für den Technologietransfer benötigt wird, sind Kombinationen aus Chat und Konferenzsystemen erforderlich. Ticket-Systeme bieten sich dann an, wenn eine Anfrage einen längeren Verwaltungsvorgang betrifft, an dem mehrere Entscheider beteiligt sind oder die sich über einen längeren Zeitraum hinzieht. Projekt , Otto-von-Guericke-Universität Magdeburg

98 94 Entscheidende Voraussetzung für den Technologietransfer ist die Chat-Komponente, die vom Nutzer gesteuert werden kann. Es gibt einen Kontaktbutton, den der Nutzer klickt, um eine Verbindung mit dem Supportteam zu bekommen. Es gibt nur wenige Systeme am Markt, die voll vom Nutzer gesteuert werden können. Hierzu gehören Liveperson, Provide Support, Skymol und Webex sowie die bereits im Einsatz befindliche Software NTR Support von der Firma NTR Global. Während der Testphase 2009 konnten keine neuen Leistungen der Konkurrenzprodukte ermittelt werden, die die NTR-Software nicht geboten hat. Darum wurde für das Jahr 2010 die Softwarenutzung von NTR fortgesetzt, zumal die Konkurrenzsoftware auch keine Preisvorteile bieten konnte. Die Marktbeobachtung wurde fortgesetzt. Da der Support auch nach der Projektphase aufrechterhalten werden sollte, kam für die Ablösung nur eine kostenlose Software infrage, die mit dem System LiveZilla gefunden wurde. Ende 2010 erfolgte die Umstellung des gesamten Supportnetzwerkes auf LiveZilla, das seit dem erfolgreich verwendet wird. 1.2 Aufbau des Beraternetzwerkes Den Kern des Beraternetzwerkes bilden die Mitarbeiter des TTZ. Hier gibt es 7 personenbezogene Accounts sowie einen Account, den sich Studenten teilen, die als Programmierer bei uns tätig sind. Im Jahr 2009 wurden 2 Accounts von Mitarbeitern des KAT-Netzwerkes benutzt, die sich jedoch 2010 entschieden haben, nur noch über einen Account zu arbeiten. Da die Mitarbeiter der Fachhochschulen durch die Transfertätigkeit weniger zusammenhängend online sind, waren die Zugriffe über den Supportchat geringer als an der Universität. Diesen Account teilen sich die 4 Fachhochschulen, die sich hier wechselseitig einloggen. In der Projektphase wurde daran gearbeitet, weitere Interessenten in den Test des Supportnetzwerkes einzubinden, um die Erfahrungen unterschiedlicher Nutzergruppen auswerten zu können. So waren 2 Accounts in anderen Bereichen der Universität eingebunden, einer im Audiovisuellen Medienzentrum und ein weiterer im Bereich der wissenschaftlichen Weiterbildung und Absolventenvermittlung. Darüber hinaus wurde eine Reihe von Gesprächen mit anderen Struktureinheiten geführt, um auch hier Berater zu gewinnen. Zu nennen sind hier u.a. die Fachschaftsräte, das Sportzentrum, das Akademische Auslandsamt, der Bereich Entrepreneurship, Dekanate der Fakultäten, die Schüleruni, das Studentenwerk, Behörden aus Sachsen-Anhalt, Sponsoren des Forschungsportals Sachsen-Anhalt, persönliche Kontakte über das Netzwerk XING sowie Nutzung von XING-Foren, wie das Forum Magdeburger Unternehmer machen sich stark. Auch außerhalb der Universität wurde das System auf verschiedenen Veranstaltungen, u.a. im Ministerium des Inneren und der Investitionsbank präsentiert. Projekt , Otto-von-Guericke-Universität Magdeburg

99 95 Die Bereitschaft zur Beteiligung war leider gering. Erfolgreich etabliert werden konnte ein Testaccount für den StudyPhone-Service der Fakultät Wirtschaftswissenschaft. Genannte Gründe für die Vorbehalte bei der Nutzung von Online-Support waren: Keine Zeit, sich mit der Lösung zu beschäftigen Keine regelmäßigen online-zeiten abgesichert Angst vor Störungen am Arbeitsplatz sowie Angst, dass bei offline-zeiten ein negativer Eindruck beim Kunden entsteht. Sehr erfolgreich war der Pretest in der Studienberatung. Hier wurde im Ergebnis ein online-chat installiert, aber eine andere Software ausgewählt, die wesentlich geringeren Anforderungen genügen muss. 1.3 Marketing Voraussetzung für die Nutzung des Supports ist die möglichst sichtbare Einbindung auf den unterschiedlichen Web-Seiten. So wurde der Kontaktbutton, den der interessierte Nutzer klicken muss, um mit einem Berater verbunden zu werden, auf allen dem TTZ zugänglichen Web-Seiten eingebunden. Hierzu zählen die Seiten zur Forschungsförderung und dem Technologietransfer der Uni-Homepage, den Web-Seiten des TTZ, den Seiten des Forschungsportals Sachsen-Anhalt, der Firmenkontaktmesse und den Seiten von Forschung für die Zukunft. Über die Projektpartner waren die Buttons im KAT-Netzwerk, auf den Seiten der Hochschulen, dem Audiovisuellen Medienzentrum und dem Bereich Wissenschaftliche Weiterbildung und Absolventenvermittlung eingebunden. Eine Erfahrung des Projektes zeigt, dass nur wirklich gut platzierte Buttons einen Sinn haben. Muss man erst auf der Seite scrollen oder auf Unterseiten gehen, dann ist die Chance, dass ein Benutzer mit einem Problem die Chat-Komponente aufruft, wesentlich geringer. Bewährt haben sich die Chat Button in der -Signatur. Bekommt der Nutzer eine Mail mit Kontaktbutton, kann er so direkt in die Chat-Funktion gehen und Fragen lassen sich schneller klären als durch das Hin und Her von Mails. Gegenüber einer Rückfrage am Telefon kann man gleich Dateien austauschen oder in einer Rechnerverbindung Probleme am eigenen PC bei der Bedienung einer Software veranschaulichen. Neben dem Marketing im Internet wurde das Supportnetz auf der Hannover Messe 2009 vorgestellt. Ein herausragendes Ergebnis für das Projekt war die Beteiligung am Europäischen e-gonvernment Award Die hohe Servicekompetenz des Forschungsportals mit integriertem online-support hat die Jury überzeugen können und das Projekt war eines der beiden deutschen Projekte, die es ins Finale der Preisverleihung geschafft haben. Von weit über 200 eingereichten Projekten haben nur 50 dieses Finale erreicht, davon nur 2 Projekte aus Deutschland, die sich in Malmö den europäischen Entscheidern aus Politik und Wirtschaft präsentiert haben. Projekt , Otto-von-Guericke-Universität Magdeburg

100 96 2 Erreichung der Ziele des Vorhabens und Zielveränderung 2.1 Zielerreichung Mit dem aufgebauten Supportnetzwerk und der Einbindung auf den verschiedenen Web-Seiten ist eine gute Grundlage geschaffen worden, ein solches Servicenetzwerk über eine Probezeit zu beobachten und die Nutzerakzeptanz zu analysieren. Hierfür bietet die Software der Firma NTR Global eine Reihe von Auswertungen an, mit der sich die online-zeiten der Berater und die geführten Gespräche im Detail nachverfolgen lassen. Bild 1 zeigt einen Ausschnitt aus einer solchen Auswertung: Bild 1: Übersicht über die Kundenberater, die Login-Zeiten und die durchgeführten Chat Alle Kundengespräche sind hinterlegt und können nachverfolgt werden. Bild 2 zeigt ein Beispiel eines Kundengesprächs, das von den Studenten der Wirtschaftswissenschaften im Rahmen des StudiCoach-Projekt geführt wurde: Bild 2: Beispiel eines Kundengespräches im Supportnetzwerk Projekt , Otto-von-Guericke-Universität Magdeburg

101 97 Die Zufriedenheit der Kunden mit dem Service ist sehr hoch. Damit ist ein wesentliches Ziel des Projektes erreicht worden, dieses neue Medium für kundenorientiertes Arbeiten im Internet und im Technologietransfer zu etablieren. 2.2 Zielveränderung und Projektverstetigung Das Ziel, Aufbau eines einrichtungsübergreifenden Supportnetzwerkes über die Projektphase hinaus, konnte leider nicht in vollem Umfang rreicht werden. Selbst die Etablierung des Services an der Otto-von-Guericke-Universität Magdeburg gestaltet sich über die Bereichsgrenzen hinaus als schwierig. Die im Punkt 1.2 genannten Vorbehalte sind gegenwärtig noch zu stark und müssen schrittweise abgebaut werden. Um den Support dennoch aufrecht zu halten hat das Technologie-Transfer-Zentrum entschieden, den Support aus eigenen Ressourcen über das Projekt hinaus fortzusetzen. Wir wollen durch einen schnellen und kundenorietieren Service überzeugen und weitere Akteure zum Mitmachen motivieren. Basis hierfür war die Einführung und Installation der kostenlosen Software LiveZilla. Alle auf den Web-Seiten vorhandenen Chat-Button wurde auf die neue Software umgestellt. Die Erreichbarkeit der Support-Mitarbeiter ist über folgende Web-Seiten möglich: Diverse Homepages der Otto-von-Guericke-Universität Magdeburg im Bereich Forschung, Wirtschaft und Technologietransfer Web-Seiten des Technologie-Transfer-Zentrums Forschungsportal Sachsen-Anhalt Messeportal Forschung für die Zukunft Portal der Firmenkontaktmesse Magdeburg Web-Seiten des Uni-Triatlons Web-Seiten der CIM-Akademie Magdeburg e.v: Bild 3 zeigt verschiedene Layouts der Kontaktbuttoneinbindung, die an die jeweiligen Web-Seiten angepasst sind. Nutzerbefragungen haben ergeben, dass rote Buttons, auch wenn sie zur Web-Seite passen, als Kontaktbutton ungeeignet sind. Rot signalisiert Stopp keine Verfügbarkeit. Deshalb wurden die meisten Button auf die Farbe Grün umgestellt, während die offline-button in einem dezenten Grau erscheinen. 2.3 Schnelle Hilfe in 2 Minuten Im Bild 4 ist ein Beispiel einer Chat-Anfrage über das System LiveZilla dargestellt. In weniger als 2 Minuten konnte das Problem zur vollen Zufriedenheit des Kunden gelöst werden. Vergleicht man die Situation mit einem Telefonat, so zeigen sich deutliche Vorteile im Support. Es können Links gesendet werden, es können Dateien direkt ausgetauscht werden. Die Anfrage kann an einen kompetenteren Berater weitergeleitet werden, wobei der komplette bisherige Chat-Verlauf mit übergeben wird. Projekt , Otto-von-Guericke-Universität Magdeburg

102 98 Einbindung OVGU-Seiten Einbindung Forschungsportal Einbindung TTZ-Homepage Bild 3: Einbindung der Kontaktbutton in verschiedenen Homepages Bild 4: Beispiel einer Problemlösung mit Supportchat in 2 Minuten Projekt , Otto-von-Guericke-Universität Magdeburg

103 Vergleich von kostenpflichtigen und kostenlosen Lösungen am Beispiel von NTR-Support und LiveZilla Im Projekt konnten beide Systeme ausgiebig getestet und verglichen werden. Eine kurze Einschätzung soll anhand folgender Punkte erfolgen: Implementierung Nutzerfreundlichkeit aus Besuchersicht Nutzerfreundlichkeit aus Betreibersicht und Auswertbarkeit der Supportarbeit Implementierung Obwohl eine professionelle Support-Software viele Dinge besser unterstützt als eine kostenlose Lösung, ist die Einrichtung durch die Komplexität recht aufwendig und nicht unbedingt einfacher. So muss man für die Einrichtung des NTR-Systems, die Erstellung der Benutzeraccounts, die Schaffung von Kontaktbuttons, die Einbindung in die einzelnen Web-Seiten mit einem Aufwand von 2-4 Wochen rechnen. Durch die im NTR-System gemachten Erfahrungen war die Umstellung auf das System LiveZilla etwa in der Hälfte der Zeit möglich Nutzerfreundlichkeit aus Besuchersicht Der Zugang zum Chat ist im NTR-System nutzerfreundlicher, da man ohne jede Eingabe sofort das Chat-Fenster erreicht. Im LiveZilla ist man sich anfangs nicht sicher, ob man wirklich in einem Chat ist, da das im Bild 5 beispielhaft dargestellte Fenster etwas an ein Mailformular erinnert. Bild 5: Beispiel einer Pre-Chat-Seite im System LiveZilla Projekt , Otto-von-Guericke-Universität Magdeburg

104 100 Es muss davon ausgegangen werden, dass ein solches Fenster viele Besucher abschreckt, dort etwas auszufüllen, denn wir hatten nach der Umstellung weniger Kontaktanfragen als im NTR-System. Dieses Pre-Chat-Fenster kann man leider nicht verändern, man hat nur die Möglichkeit, die Pflichtfelder festzulegen, wobei auch die anderen Felder weiter angezeigt werden (hier Firma). Der Vorteil dieses Pre-Chat-Fensters ist jedoch, dass ein sinnloses Klicken des Kontaktbuttons, ohne wirklich den Chat zu wollen oder eine Frage zu stellen, vermieden wird, eine Situation, die wir im NTR-System öfter zu verzeichnen hatten. Vorteil einer kommerziellen Lösung, wie NTR Support, ist der größere Leitungsumfang für den Benutzer. So sind mit wenigen Klicks auch Rechnerverbindungen möglich sowie die Möglichkeit, die Bedienung und Installation zu Unterstützen. Trotzdem ist es auch hier erforderlich, dass der Benutzer in der Lage ist, Verbindungsprogramme zu installieren, was auf Grund fehlender Berechtigungen nicht immer möglich ist Nutzerfreundlichkeit aus Betreibersicht Hier zeichnen sich die größten Unterschiede zwischen kostenlosen und Kaufsystemen ab. Professionelle Software bietet im Backend eine Menge Funktionen und Tools, um Auswertungen und Analysen vorzunehmen, den Support von verschiedenen Beratern zu vergleichen, die Einstiegsseiten zu analysieren bis hin zur Beobachtung der Benutzeraktionen auf der Web-Seite. Hier haben einfache und kostenlose Systeme erheblich weniger Möglichkeiten. Der Betreiber muss sich im Vorfeld die Frage stellen, mit welchem Ziel er den Support anbietet. Geht es in erster Linie um eine schnelle und unkomplizierte Hilfe für den Besucher oder ist die Lösung ein Marketingtool, das Nutzerverhalten überwacht, Kaufentscheidungen unterstützt und am Ende an einer Zielerreichung gemessen wird. So wird ein Shop oder eine Beratung nicht an kostenpflichtigen Tools vorbeikommen, für die solche Analysen die Basis der weiteren Web-Seiten- Gestaltung sein werden. Verwaltungen und Behörden, die nichtkommerzielle Dienste anbieten, in denen die Kundenzufriedenheit und das schnelle Reagieren im Vordergrund stehen, werden mit dem Leistungsumfang von LiveZilla genügend unterstützt. 3 Zusammenfassung Der Aufbau eines Online-Support-Netzwerkes für Technologietransfer und öffentliche Verwaltung hat sich als Bereicherung unserer Technologie-Transfer-Arbeit erwiesen. Die schnelle und unkomplizierte Erreichbarkeit unserer Mitarbeiter von außen, die große Kundenorientierung und der Servicecharakter unserer Arbeit haben das Ansehen des Transfers nachhaltig verbessert. Der feste Wille, die Projektergebnisse zu verstetigen und den Service auch ohne finanzielle Unterstützung aufrecht zu erhalten, spricht für den beispielgebenden Projekterfolg. Projekt , Otto-von-Guericke-Universität Magdeburg

105 101 Online-Serviceportal campus2go Ausführende Einrichtung(en): Hochschule Magdeburg-Stendal Projektleiter: Frank Richter, Kanzler der Hochschule Magdeburg-Stendal, Postfach 3655, D Magdeburg. Kornelia Hartmann, Zentrum für Kommunikation und Informationsverarbeitung (ZKI), Hochschule Magdeburg-Stendal, Postfach 3655, D Magdeburg. Christian Neumann, Zentrum für Kommunikation und Informationsverarbeitung (ZKI), Hochschule Magdeburg-Stendal, Postfach 3655, D Magdeburg.. Förderung: Dieses Vorhaben wird mit Mitteln der Europäischen Kommission aus dem Europäischen Fonds für regionale Entwicklung (EFRE) im Rahmen der Maßnahme 11.03/41.03 gefördert (FKZ: ). Zusammenfassung campus2go ist ein personalisiertes Webportal, das zusätzlich für den Zugriff via Smartphones auf online-services und Informationen der Hochschule optimiert ist. Es steht allen Angehörigen der Hochschule Magdeburg-Stendal als Arbeitsplattform zur Verfügung und ermöglicht die Erstellung von Web-Seiten, die auf persönliche Erfordernisse zugeschnitten werden können. Es geht in diesem Projekt nicht darum, klassische Webseiten der Hochschule für den Zugriff via Smartphones zu optimieren. Webseiten einer Hochschule enthalten ein Maximum an Informationen für alle Interessenten, auch für Dritte. Das Webportal hingegen richtet sich nur an HS-Angehörige. Weiter enthält ein klassischer Webauftritt in der Regel eine Vielzahl an Links zu weiteren Diensten und Servern, wie z. Bsp. e-learning Tools, Campusmanagementtools, groupware, Webmail oder auch dem Studentenwerk. Diese Dienste laufen auf autarken Servern. Insofern wäre die Überarbeitung des normalen Internetauftritts der Hochschule nur eine Teillösung. Ein Webportal mit einem eingebauten Parser stellt die universellere Lösung dar, da sich solche Anwendungen, Prozesse und Dienste integrieren lassen. Der sichere Zugriff auf das Webportal erfolgt via Single Sign-on mit dem zentralen Nutzeraccount der Hochschule. Das Projekt startete im September 2009 mit zwei Projektmitarbeitern. Die Laufzeit des Projektes musste verlängert werden, da ab 2010 nur noch eine Projektstelle weiter geführt werden konnte. Einige Kernkompetenzen konnten durch diese Stelle nicht ersetzt werden. Diese Kompetenzen wurden im Wesentlichen von den Mitarbeitern und Mitarbeiterinnen des ZKI ausgeglichen, so dass alle objektiv umsetzbaren Projektziele erreicht wurden. Alle im Zusammenhang mit der Umstellung auf ein neues Campusmanagementsystem (CM) stehende Aktivitäten konnten nur bedingt durchgeführt werden bzw. wurden durch adäquate Maßnahmen ersetzt. Die Einführung eines CM an der Hochschule Magdeburg-Stendal wurde verschoben. Projekt , Hochschule Magdeburg-Stendal

106 102 Das Portal konnte im Oktober 2011 mit Semesterbeginn in Betrieb genommen. Anfang Dezember 2011 hatte das Projekt schon mehr als 150 Nutzer und Nutzerinnen zu verzeichnen. Inhaltsverzeichnis 1 Systemumgebung Identitätsmanagement Single Sign-on Rechtemanagement Personalisierte Seiten Communities Einsatz des digitalen Personalausweis für das Identity-Management Mobile Version IT-Sicherheit Nachhaltigkeit 117 Literatur/Quellen 117 Projekt , Hochschule Magdeburg-Stendal

107 103 1 Systemumgebung Das Projekt umfasst das Portal campus2go und einen Authentifizierungsserver der Single Sign-on unterstützt. Die Systeme laufen dabei getrennt auf zwei virtuellen Hosts mit eigener Subdomain. So ist das Portal unter campus2go.hs-magdeburg.de zu erreichen, während der Authentifizierungsserver die URL cas.hs-magdeburg.de besitzt. Als Betriebssystem ist auf beiden Hosts ein 64-Bit fähiges Ubuntu LTS installiert. Softwareseitig wird das Portal campus2go auf Basis der Open-Source-Anwendung Liferay [1] betrieben. Diese Portal-Lösung wird seit dem Jahr 2000 ständig weiterentwickelt und gilt heutzutage als ausgereift für den produktiven Einsatz. Liferay ist in Java geschrieben und unterstützt eine Vielzahl an Datenbanksystemen, ist plattformunabhängig und bietet Schnittstellen für Single Sign-on Anwendungen an. Des Weiteren ist Liferay serviceorientiert. So können, durch verschiedene Java-Technologien wie Portlets, neue Anwendungen erstellt und im Portal hinzugefügt werden. Auch können verschiedene Darstellungsformen kreiert und schnell ausgetauscht werden, da Liferay eine strikte Trennung von Inhalt und Layout vornimmt. Wie alle webbasierten Java- Anwendungen benötigt auch Liferay einen Applikationsserver, welcher im Softwarepaket mit heruntergeladen werden kann. Das Portal campus2go nutzt das Bundle Liferay + Tomcat-Server. Als Datenbanksystem für das Web-Portal wurde PostgreSQL installiert. Unter den lizenzfreien Datenbanksystemen hat PostgreSQL gegenüber MySQL den Vorteil, dass die dazugehörige Skriptsprache mächtiger ist, besonders im Bezug auf sicherheitsbezogene Transaktionen. Außerdem ist die Zukunft von MySQL durch den Aufkauf von Oracle ungewiss. Für die Portal-Authentifizierung wird ein CAS-Server (Central Authentification Server) [2] verwendet. Der CAS-Server, mit all seinen CAS-Clients für die anzubindenden Anwendungen, wird von der Java Architecture Special Interest Group (JA-SIG) lizenzfrei angeboten und unterstützt neben Single Sign-on auch Single Sign-out. Dieses Feature der Mehrfachabmeldung wird nicht von allen SSO-Anwendungen unterstützt, beispielsweise von der ebenfalls zur Debatte gestandenen SSO-Lösung Shibboleth. Plattform: - Virtuelle Machine: Ubuntu Server, 64-Bit - Portal-Anwendung: Liferay EE Applikationsserver: Tomcat Hochsprache: Java 6 - Datenbanksystem: PostgreSQL Single Sign-on: CAS-Server Authentifizierung: zentraler LDAP-Server Für die Authentifizierung steht außerdem ein zentraler LDAP-Server bereit, welcher die Daten der Hochschulangehörigen enthält. Während der CAS-Server nur die Nutzerkennung überprüft, importieren die angebundenen Dienste, nach erfolgreicher Authentifizierung oftmals zusätzliche Nutzerdaten aus dem LDAP. Projekt , Hochschule Magdeburg-Stendal

108 104 Bild 1: Startseite von campus2go, als Gast angemeldet Bild 2: Startseite von campus2go, als Mitarbeiter angemeldet 2 Identitätsmanagement Ziel des Identitätsmanagement ist die individualisierte Bereitstellung von IT-Ressourcen. Die Nutzer/-innen sollen sich mit einer Anmeldung für alle Anwendungen registrieren können, die sie nutzen dürfen. Projekt , Hochschule Magdeburg-Stendal

109 105 In diesem Zusammenhang war ursprünglich angedacht, die unterschiedlichen Datenbanken der einzelnen HIS-Produkte zusammenzuführen und auch das Rollenmodell von HISinOne zu verwenden. Recherchen zum Einsatz eines Campusmanagementsystems an der Hochschule Magdeburg-Stendal laufen noch. Insofern mussten andere Wege gefunden werden. Mit CAS (Autorisierung via LDAP) als zentrales Authentifizierungssystem ist eine Zusammenführung und Konsolidierung der Daten nicht zwingend notwendig. Zudem ist HISinOne CAS-fähig und kann dadurch auch zu einem späteren Zeitpunkt in das zentrale Authentifizierungssystem mit eingebunden werden. 3 Single Sign-on Für die Authentifizierung wird ein Single Sign-on (SSO) namens CAS (Central Authentification Service) verwendet. Für CAS spricht, dass es sich verglichen mit beispielsweise Shibboleth um eine relativ einfach zu implementierende Lösung handelt. Und das ist bei sicherheitsrelevanten Anwendungen ein wichtiger Vorteil, weil es das Pannenpotential deutlich verringert. Im Gegensatz zu Shibboleth unterstützt CAS auch ein Single Log-out. Ein weiterer Vorteil von CAS ist, dass das Passwort nicht an die angebundenen Systeme weitergereicht wird und daher in diesen Anwendungen nicht kompromittiert werden kann. Der Nutzer meldet sich beim CAS-Server an und erhält ein Nutzer- und ein Anwendungsticket in Form von zeitlich begrenzten Session-ID, wobei das Anwendungsticket nur einmal eingelöst werden kann. Durch die SSL-Verschlüsselung und der Tatsache, dass die Session-ID im Cookie und nicht in der URL steht, ist es sehr unwahrscheinlich, dass ein Angreifer durch Mitschneiden des Netzverkehrs an eine Session-ID herankommt. Aus diesen Gründen bestehen keine grundsätzlichen sicherheitstechnischen Bedenken, CAS als Single Sign-on-System an der Hochschule einzusetzen. An den CAS-Server sind im produktiven System das Portal campus2go, egroupware, LSF und Moodle durch CAS-Clients angebunden. Befindet sich der/die Nutzer/-in auf dem Portal und möchte sich anmelden, wird er/sie auf die Anmeldemaske des CAS- Servers weitergeleitet. Hier gibt der/die Nutzer/-in seine Hochschulkennung ein und wird bei erfolgreicher Authentifizierung zurück aufs Portal geleitet, wo anschließend die Nutzungsbedingungen und die Einwilligungserklärung bestätigt werden müssen. Projekt , Hochschule Magdeburg-Stendal

110 106 Bild 3: SSO-Architektur der Hochschule Magdeburg-Stendal Ist der/die Nutzer/-in im CAS angemeldet, kann er/sie nun auf egroupware zugreifen ohne sich explizit einloggen zu müssen. Die Anmeldung erfolgt automatisch im Hintergrund. Eine Besonderheit stellt hochschulintern der Zugriff auf Moodle dar. Hier muss vor der Anmeldung eine Moodle-Benutzererklärung akzeptiert werden. Wer zustimmt, wird in einer Moodle-Datenbanktabelle geführt, die der CAS-Server bei der Authentifizierung neben dem LDAP ebenfalls abfragen muss. Beim Ausloggen meldet sich der/die Nutzer/-in beim CAS-Server und der jeweiligen Anwendung ab. Sollte der/die Nutzer/-in das Abmelden vergessen, verfällt das Nutzerticket nach 2 Stunden Inaktivität. Ursprünglich war auch angedacht den Webmailer an den CAS-Server anzubinden. Der Webmailer SkyrixGreen wurde allerdings in Objective C implementiert, wofür es derzeit keinen CAS-Client gibt. Ebenso ist eine Anbindung der Bibliotheksdatenbank an den CAS-Server technisch derzeit nicht möglich, da die OPAC-Bibliothek außerhalb der Hochschule betrieben wird und andere Accounts verwendet. Dieses Problem haben auch andere Hochschulen, wo ein Studierendenportal aufgebaut werden soll, bzw. schon im produktiven Einsatz ist. Die Universität Göttingen versucht daher eine Anwendung zu entwickeln, die dieses Problem lösen kann. 4 Rechtemanagement Für das Rechtemanagement wurden im Portal campus2go die Rollen Gast, Student/-in und Mitarbeiter/-in eingeführt. Als Gast gelten alle Nutzer/-innen, die nicht der Hochschule angehören oder die weder die Einwilligungserklärung noch die Nutzungsbedingungen akzeptiert haben und daher im Portal auch keine Rechte besitzen. Sie dürfen nur die öffentlichen Seiten besuchen, wo keine Anmeldung vorgesehen ist. Auf den öffentlichen Seiten erfahren die Nutzer/- Projekt , Hochschule Magdeburg-Stendal

111 107 innen allgemeine Hochschulnachrichten wie Studienangebote, RSS-Feeds der Hochschule und wichtig, das Impressum. Im Portal bekommen Hochschulangehörige ihren Status Student bzw. Mitarbeiter erst zugewiesen, wenn sie die Nutzungsbedingungen und die Einwilligungserklärung zum Datenschutz akzeptiert haben. Das Portal importiert dann automatisch die Benutzerdaten (Nutzerkennung, Name, Vorname, , Status) aus dem LDAP in die portaleigene Datenbank und ordnet dem/der Nutzer/-in die entsprechende Rechtegruppe zu. Jede/r Nutzer/in kann seine/ihre importierten Daten im Profil sehen aber nicht verändern. Offizielle Statuswechsel oder Namensänderungen erfährt das Portal durch einen täglichen Abgleich der Nutzerdaten mit dem LDAP. Für Hochschulangehörige ist das Portal zudem unterteilt in einen standardisierten Hochschulbereich und in einen persönlichen Bereich (Siehe Abschnitt: Personalisierte Seiten). Im Standardbereich werden die Dienste der Hochschule angeboten, wobei der Sichtbereich im Navigationsmenü abhängig vom Status ist. So werden Studierende nie Anwendungen der Zentralverwaltung zur Ansicht bekommen und Mitarbeiter/-innen keine spezifischen Informationen erhalten, die nur für Studierende relevant sind. Bild 4: Moodle im Studierendenportal Projekt , Hochschule Magdeburg-Stendal

112 108 In Tabelle 1 werden die Anwendungsberechtigungen im standardisiertem Bereich aufgelistet. Fachanwendungen der Zentralverwaltung wurden in dieser Phase noch nicht etabliert, da in dem Bereich größere Softwareumstellungen anstehen. Diese Anwendungen würden aber nur über VPN zu erreichen sein (Siehe Abschnitt: IT-Sicherheit). Anwendung/Rolle Student Mitarbeiter Gast LSF X X Moodle X X Bibliothek X X X X Groupware X Home-Verzeichnis X X Studienangebote X X X News X X X Communities X X Wartung X Schwarzes Brett X X Hardwarebörse X X Tabelle 1: Rechtemanagement im Studierendenportal 5 Personalisierte Seiten Die Einrichtung des individuellen Arbeitsplatzes durch personalisierte Seiten umfasst einen privaten und einen öffentlichen Bereich, der kontinuierlich erweitert werden kann. Anfangs, nach der Erstanmeldung, enthält der individuelle Arbeitsplatz nur eine Willkommensseite im privaten Bereich, auf der sich die Anleitung und einige Beispielanwendungen befinden. Anhand der Anleitung erfährt der/die Nutzer/-in, wie öffentliche Seiten erstellt und weitere private Seiten angelegt und gestaltet werden können. Der private Bereich ist im Portal nur für den/die Nutzer/-in sichtbar, während der öffentliche Bereich explizit definiert werden kann, welche Seiteninhalte für Studenten/-innen, Mitarbeiter/-innen und/oder Gäste sichtbar sein sollen. Der Funktionsumfang zum Einrichten des individuellen Arbeitsplatzes ist für Studenten/-innen und Mitarbeiter/-innen gleich. Für den privaten, als auch für den öffentlichen Bereich, kann der/die Nutzer/-in durch das Content Management System von Liferay per Drag and Drop ein Navigationsmenü erstellen und Seiten hinzufügen. Auf diesen Projekt , Hochschule Magdeburg-Stendal

113 109 Seiten dürfen nur Links eingefügt werden und Dateien (Bilder, Dokumente, Archive bis 3 MB) hochgeladen werden, die den Nutzungsbedingungen entsprechen. Bild 5: Willkommensseite im privaten Bereich Bild 6: Hinzufügen von Applikationen personalisierten Seiten Projekt , Hochschule Magdeburg-Stendal

114 110 Zusätzlich können Java-basierte Webanwendungen, die der Administrator freigegeben hat, verwendet werden. Zu den Applikationen zählen beispielsweise Blogs, RSS- Feeds, Kalender, Wikis u.v.m. Für die optische Gestaltung stehen dem/der Nutzer/-in eine Vielzahl an Themes zur Verfügung. Diese fertigen und einsatzbereiten Designvorlagen geben durch Verändern der Hintergrundfarbe an Schaltflächen und Symbolleisten selbst erstellten Seiten ein komplett anderes Aussehen. Damit trotz des Farbwechsels ein Bezug zur Hochschule vorhanden erkennbar ist, enthält jedes Theme eine Fußzeile mit dem Impressum der Hochschule. Bild 7: Auswahl an verschiedenen Themes Projekt , Hochschule Magdeburg-Stendal

115 111 Bild 8: Die Willkommensseite im Noir-Theme Jedes Themes ist außerdem auch wieder austauschbar. So kann der/die Nutzer/-in jederzeit wieder in die ursprüngliche Version wechseln oder auch die mobilen Themes ausprobieren. Die mobilen Themes passen automatisch so gut es geht, das Seitendesign plattformunabhängig an Smartphones an. In der Anleitung erhält der/die Nutzer/-in zudem Optimierungshinweise. Anstatt in drei Spalten Anwendungen zu platzieren, sollte eine mobile Seite beispielsweise nur eine Spalte enthalten. Wer externe Webseiten einbinden möchte, kann den für die Hochschule entwickelten HTML-Parser nutzen, um die relevanten Daten für sein Smartphone herauszufiltern. 6 Communities Eine erweiterte Form von personalisierten Seiten stellen die Communities dar. Hier können sich Nutzer zu einer Gruppe zusammenschließen und auf einer gemeinsamen Plattform miteinander kommunizieren. Der Community-Administrator kann die Seiten einer Community selbst erstellen und bestimmen, ob die Community nur ausgewählten Nutzer zugänglich sein soll oder jeder beitreten darf. Er kann die Community-Mitglieder weiterhin in selbst definierte Gruppen unterteilen. Jede Gruppe hat wieder eigene Rechte, so dass sich einrichten lässt, dass Themen im Community-Forum oder Dokumente in der Dokumentenbibliothek nur für bestimmte Gruppen zugänglich sind. Projekt , Hochschule Magdeburg-Stendal

116 112 Bild 9: Nur die Standard-Community ist derzeit aktiv Auf der öffentlichen Portalseite sind alle frei verfügbaren Communities aufgelistet in denen der/die Nutzer/-innen beitreten können. Private Communities sind in der Liste unsichtbar und nur durch Einladung des Administrators zugänglich. Dafür kann jeder/jede Nutzer/-in aber einsehen, in welcher Community er/sie bereits eingetreten ist und kann jede Community jederzeit wieder verlassen. 7 Einsatz des digitalen Personalausweis für das Identity- Management Für das Identity-Management war bei der Projektplanung auch das Einbinden des digitalen Personalausweises ein Thema. Beim Treffen des Arbeitskreises elearning des ZKI e.v. (Verein der Rechenzentrumsleiter im deutschsprachigen Raum) im Februar 2010 in Mannheim ging hervor, dass der digitale Personalausweis für ein Identity- Management an Hochschulen derzeit nicht optimal ist. Zu den Gründen: Für Nutzer nicht allgemeingültig Ausländische Studenten bekommen nicht den deutschen digitalen Personalausweis und werden daher ausgeschlossen. Für deutsche Bundesbürger besteht keine Pflicht, den Personalausweis auch als Onlineausweisfunktion (eid-funktion) zu nutzen. Die eid-funktion ist daher standardmäßig ausgeschaltet, kann aber durch eine Gebühr, in Höhe von 6 Euro, im Bürgerbüro nachträglich freigeschaltet werden. Dann benötigt der Nutzer noch eine Client-Software, eine fünfstellige PIN-Nummer und für die digitale Signatur, ein Singnaturzertifikat, dass er sich von der Bundesnetzagentur herunterladen kann. Die PIN-Nummer kann über den Rechner eingegeben werden, sicherer wäre aber ein PIN-Pad. Kosten und Aufwand für den Onlineanbieter Wer als Dienstleister Daten vom digitalen Personalausweis nutzen will, benötigt von der Vergabestelle für Berechtigungszertifikate (VfB) ein Berechtigungszertifikat. Jedes Projekt , Hochschule Magdeburg-Stendal

117 113 Berechtigungszertifikat ist aus Sicherheitsgründen (falls sich ein Anbieter als Abzocker herausstellt) nur 3 Tage gültig und muss daher regelmäßig neu beantragt werden. Das Berechtigungszertifikat ist nicht kostenlos und die Gebühr richtet sich nach der Anzahl der zu lesenden Daten. Wer mehr Daten haben will, muss auch mehr zahlen. Der Anbieter weist sich dann mit dem Berechtigungszertifikat beim Nutzer aus, muss dem Nutzer aber anzeigen, welche Daten angefordert werden. Der Nutzer gibt die Datenübertragung erst mit Eingabe der Pin frei. Sicherheitsbedenken Aus Anbietersicht bestehen keine Bedenken. Die auf dem Chip hinterlegten Daten sorgen im Zusammenspiel mit einer persönlichen PIN beispielsweise für einen Schutz vor Phishing, dem Abfangen von Zugangsdaten. Die Übermittlung aller Daten bei der Nutzung des neuen Personalausweises erfolgt ausschließlich verschlüsselt. Die verwendeten Verschlüsselungsverfahren werden durch das BSI festgelegt und sind international anerkannt und etabliert. Die Sicherheit des Ausweises wird durch eine nur Ihnen bekannte PIN erheblich erhöht. Per Post bekommen Sie eine fünfstellige PIN (Transport-PIN) zugesandt. Diese fünfstellige Transport-PIN müssen Sie vor der ersten Nutzung des neuen Personalausweises im Internet durch eine individuelle sechsstellige PIN ersetzen. Zur Bestätigung jeder Datenübermittlung des neuen Personalausweises müssen Sie dann Ihre selbst festgelegte PIN eingeben. Bei Verlust oder Diebstahl des neuen Personalausweises ist ein Missbrauch der Ausweisfunktion nur möglich, wenn der Täter die individuelle PIN kennt. Nach dreimaliger falscher PIN-Eingabe wird die Internet-Nutzung des Ausweises automatisch gesperrt. Bei Diebstahl oder Verlust des Ausweises sollten Sie umgehend die zuständigen Behörden informieren. [6] Aus Nutzersicht ist zu bedenken, dass der Chip im Ausweis per Funk im Nahbereich auslesbar wäre. Die Bundesregierung versichert, dass die Daten bestens geschützt seien: Wer Daten auslesen wolle, brauche eine Berechtigung in Form eines Zertifikats. Verbraucherschützer sehen die Sicherheitsfrage differenzierter. Zwar müsse sich ein Anbieter vom Staat ein Zertifikat besorgen, sagt Michael Bobrowski vom Verbraucherzentrale Bundesverband. Dieser prüfe jedoch nicht die Seriosität des Unternehmens. Abzocker könnten gewissermaßen staatlich zertifiziert agieren. Außerdem gebe es kein Kopplungsverbot: So könnte ein Anbieter für die Nutzung seiner Dienste die Freigabe aller im Ausweis hinterlegten Daten verlangen - und diese dann für andere Zwecke weiterverwenden. Das sei aus Sicht des Datenschutzes bedenklich und ein Schwachpunkt des Systems. [4] 8 Mobile Version Neben der Möglichkeit seine persönlichen Seiten für Smartphones anzupassen (siehe Abschnitt 5 Personalisierte Seiten ), sind auch die öffentlichen Hochschulseiten des Portals und die Authentifizierungsseiten des CAS-Servers für mobile Geräte geeignet. Eine Browserweiche erkennt, ob der Nutzer das Portal via PC oder Smartphone aufruft und schaltet bei Verwendung eines Smartphones auf die mobile Version um. Projekt , Hochschule Magdeburg-Stendal

118 114 Bild 10: Navigationsmenü im standardisierten Portalbereich auf dem iphone 3Gs Die öffentlichen Hochschulseiten wurden dabei mit den gleichen Werkzeugen erstellt, wie sie der/die Nutzer/-in für seine persönlichen Seiten verwenden kann. Für das mobile Design wurde das iphone-theme ausgewählt und für die hochschulinternen Links kam der eigens entwickelte HTML-Parser zum Einsatz. Durch Eingabe der URL und des zu selektierenden Abschnittes im Konfigurationsmenü entfernt der Parser umliegende Bilder und Navigationsleisten und liefert die Daten optimiert für Smartphones aus. Bild 11a: Die Semestertermine in campus2go Projekt , Hochschule Magdeburg-Stendal

119 115 Bild 11b: Die Semestertermine in der mobilen Version am Nokia 5800 Das Beispiel in Bild 11 zeigt, wie mit Hilfe des Parsers die Semestertermine aus dem Hochschulseitenlink herausgefiltert und in die die mobile Seite hineinkopiert worden sind. Bei eingebetteten Portlets (Mini-Anwendungen) wurden wiederum die enthaltenen CSS- Dateien, in der die Layout-Regeln definiert sind, mit mobilen CSS-Dateien ausgetauscht. So enthält das Portal die mobile Version eines SFTP-Client mit der/die Nutzer/-in via Smartphone ihr Home-Verzeichnis ansprechen und jederzeit Dokumente hoch- oder herunterladen können. Die Datenübertragung erfolgt auch in der mobilen Version SSL-verschlüsselt. Bild 12: Die mobile Version des SFTP-Client für das Home-Verzeichnis Projekt , Hochschule Magdeburg-Stendal