hrung einer Smartcard basierten Single S - Lehrstuhl Technische ...

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

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
II

Vorwort
Ziel der EFRE 2007-2013 Maßnahme 11.03/41.03 des Landes Sachsen-Anhalt war
laut dem entsprechenden Erlass vom 23.04.2008 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 2011. 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
III

Inhaltsverzeichnis
Projekt 41.03-08-01 1
Einführung einer Smartcard basierten Single Sign-On Lösung
Martin-Luther-Universität Halle-Wittenberg
Projekt 11.03-08-03 17
eCampus-Services & -Infrastrukturen für eine gesicherte
und verbindliche elektronische Hochschulverwaltung
Hochschule Harz, Hochschule Anhalt
Projekt 41.03-09-01 43
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 11.03-08-02 61
Homogene Verzeichnisdienste
Otto-von-Guericke-Universität Magdeburg, Hochschule Harz
Projekt 11.03-09-02 79
Integrierte Forschungsplattform für den Forschungsschwerpunkt
„Decision Design – Gestaltung ökonomischer Prozesse und Institutionen“
Otto-von-Guericke-Universität Magdeburg
Projekt 11.03-09-01 93
Aufbau eines Online-Supportnetzwerkes für
Technologietransfer und öffentliche Verwaltung
Otto-von-Guericke-Universität Magdeburg
Projekt 11.03-08-01 101
Online-Serviceportal „campus2go“
Hochschule Magdeburg-Stendal
IV

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-06099 Halle (Saale). E-Mail: paul.molitor@informatik.uni-halle.de
Dr. Sandro Wefel, Institut für Informatik, Martin-Luther-Universität Halle-Wittenberg,
D-06099 Halle (Saale). E-Mail: sandro.wefel@informatik.uni-halle.de
Förderung:
Dieses Vorhaben wird mit Mitteln der Europäischen Kommission aus dem Europäischen
Fonds für regionale Entwicklung (EFRE) 2007-2013 im Rahmen der Maßnahme
11.03/41.03 gefördert (FKZ: 41.03-08-01).
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 E-Mailverschlüsselung,
für die elektronische Signatur und für Zutrittskontrollsysteme.
Projekt 41.03-08-01,
Martin-Luther-Universität Halle-Wittenberg
1

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 41.03-08-01,
Martin-Luther-Universität Halle-Wittenberg
2

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 41.03-08-01,
Martin-Luther-Universität Halle-Wittenberg
3

in den Pools sind im Rahmen der Anschaffungskosten neuer Rechner eher gering, so dass
der finanzielle Aufwand überschaubar ist.
Da für die Authentifizierung die Smartcard mit
dem Rechner verbunden werden muss und die
Eingabe einer PIN1 erforderlich ist, stellt dies
einen zusätzlichen Aufwand gegenüber der Eingabe
eines Passwortes dar. Zur Kompensation
dieses Aufwandes wurde deshalb die PIN-
Eingabe auf einen Zeitpunkt während einer
Rechnersitzung reduziert, anschließend kann
die Karte für nachfolgende Authentifizierungen,
z.B. bei der Anmeldung an Diensten, ohne
weitere PIN-Eingabe, quasi im Hintergrund genutzt
werden. Dies erlaubt folgendes Szenario:
Ein Nutzer authentifiziert sich gegenüber einem
Rechner nicht mehr durch Eingabe von Nutzer-
Abbildung 1: Token in Form von USB-
Sticks und Smartcards
name und Passwort, sondern durch Einstecken der Smartcard und Eingabe der PIN. Anschließend
kann er die Webseiten der universitären Portale aufrufen oder E-Mail abrufen,
ohne erneut die PIN oder ein Passwort eingeben zu müssen.
Somit ermöglichen Smartcards den Einsatz für Single Sign-On (SSO) und können gleichzeitig
als Container für elektronische Schlüssel zur elektronischen Signatur oder Verschlüsselung
mit hohem Grad an Sicherheit verwendet werden. Um die Authentizität auch
über den Rahmen der Hochschule hinaus zu belegen, werden die Zertifikate von einer
übergeordneten Stelle, die landes- oder bundesweit agiert und als vertrauenswürdig angesehen
wird, ausgestellt.
Darüber hinaus können die Smartcards, mit ihrer Fähigkeit Informationen zu speichern
und intern unter Anwendung kryptographischer Verfahren zu verarbeiten, für andere Einsatzfelder
genutzt werden. So kann z.B. ein Türöffnungssystem mit einem biometrischen
Lesegerät gekoppelt werden und die sensible Information, das biometrische Muster, über
die Karte verarbeitet werden und muss nicht außerhalb der Karte gespeichert werden.
Derartige Einsatzfelder können die Nutzung der Token weiter befördern und somit helfen,
die Akzeptanzschwelle zu deren Einsatz zu überwinden.
Um nachzuweisen, dass sich dieses Prinzip im praktischen Einsatz bewährt, wurde eine
zertifikatsbasierte SSO-Authentifizierungslösung mit Studierenden aufgebaut und getestet.
Dabei wurde nicht nur die Authentifizierung geprüft, sondern auch der erforderliche
organisatorische Aufwand bei der Einführung und im Regelbetrieb ermittelt sowie weitere
Einsatzfelder für die Smartcards geprüft, um möglichst viele Facetten des Smartcard-
Einsatzes zu erfahren.
1 Die Authentifizierung gegenüber dem Token erfolgt meist durch die Eingabe einer PIN, welche bei Anwendung
durch mehrere Applikationen mehrmals einzugeben wäre. Alternativ kann die Authentifizierung auch
durch biometrische o.a. Verfahren erfolgen.
Projekt 41.03-08-01,
Martin-Luther-Universität Halle-Wittenberg
4

PKCS#11
Bibliothek
vom
Token
Hersteller
Hilfsprogramme SSO-System
Lokales System
Steuerung
des Agenten
PKCS#11-
Proxy
Agent
Applikationen
geschützte
Kommunikation
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 41.03-08-01,
Martin-Luther-Universität Halle-Wittenberg
5

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.
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 arbei-
Abbildung 3: Studierendenausweis mit
kontaktlosem Chip
ten. Die zusätzliche Belastung der Administratoren, Mitarbeiter und Mitarbeiterinnen innerhalb
der Verwaltung sollte möglichst gering sein.
Projekt 41.03-08-01,
Martin-Luther-Universität Halle-Wittenberg
6

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 41.03-08-01,
Martin-Luther-Universität Halle-Wittenberg
7

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 https://pkiserv.informatik.uni-halle.de/trac/sso/
Zur Anmeldung eine E-Mail an sandro.wefel@informatik.uni-halle.de senden
3 http://www.urz.uni-halle.de/zertifizierungsbetrieb/
4 https://www.pki.dfn.de/
5 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 41.03-08-01,
Martin-Luther-Universität Halle-Wittenberg
8

antrag ausgedruckt und muss von dem Antragsteller/der Antragstellerin unterschrieben
werden. Im Hintergrund beantragt die Software ü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 ausgehä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 bestätigen sowie den Antrag zur Unterschrift, den PIN-Brief
und die Smartcard ausgeben. Dies sollte dem Anspruch des geringen Zusatzaufwandes
bei der Einführung der zertifikatsbasierten Authentifizierung genügen.
Fü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 öffnen, ein Vorgang, der
nicht rückgängig gemacht werden kann. Dadurch wird
sichergestellt, dass RA-Mitarbeiter die PIN nicht lesen
können. Jeder Versuch, Zugriff auf die PIN zu erlangen,
kann anhand der Beschädigung der Sichtfeldabdeckung
vom Antragsteller erkannt werden.
Die Antragsteller erhalten insgesamt drei Zertifikate,
eines für die Benutzeranmeldung (SSO- Abbildung 4: Hydalam
Authentifizierung), eines zur elektronischen Signatur
(z.B. für den Nachweis der Authentizität einer E-Mail) und ein Zertifikat zur Verschlüsselung.
Bei einer verschlüsselten Nachricht an eine Person benötigt diese die Karte für deren
Entschlüsselung. Bei Verlust einer Karte können die Zertifikate als ungültig erklärt (Rückruf)
und neue Zertifikate zusammen mit einer neuen Karte ausgestellt werden. Dies gilt
jedoch nicht für das Verschlüsselungszertifikat, da andernfalls mit dem neuen Schlüssel
kein Zugriff auf alte verschlüsselte Daten besteht. Aus diesem Grund wurde ein Mechanismus
in das RA-Tool eingebaut, welcher die Verschlüsselungsschlüssel zum Zertifikat in
verschlüsselter Form für ein späteres Recovery speichert.
Der Zertifikatsrückruf wird ebenfalls durch das entwickelte RA-Tool abgedeckt und kann
auf Knopfdruck vom RA-Mitarbeiter ausgelöst werden. Für das Recovery des Verschlüsselungszertifikats,
welches ebenfalls über das RA-Tool möglich ist, wird etwas mehr Aufwand
benötigt. Dazu existiert eine weitere Smartcard, deren PIN nur zur Hälfte zwei unabhängigen
Personen, die nicht zur RA gehören, bekannt ist. Für ein Recovery müssen diese
beiden Personen vor Ort sein und ihren Teil der PIN eingeben, bevor das Zertifikat, genauer
der zugehörige Schlüssel aus der Datenbank zurück geholt, entschlüsselt und auf die
neue Karte geschrieben werden kann.
Nach Festlegung dieses Ablaufs wurde die Policy für den Zertifizierungsbetrieb der Uni-
6 http://www.koopmanndruck.de/p_hydalam.html
Projekt 41.03-08-01,
Martin-Luther-Universität Halle-Wittenberg
9

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 https://info.pca.dfn.de/uni-halle-chipcard-ca/index.html
Projekt 41.03-08-01,
Martin-Luther-Universität Halle-Wittenberg
10

(a) Vorderseite (b) Rückseite mit Cryptochip
Abbildung 6: Neuer Studierendenausweis mit kontaktlosem und mit Cryptochip
enthaltenen TRW-Streifens 8 mit den Validierungsterminals der Universität. Diese Terminals
hinterlegen auf dem TRW-Streifen in jedem Semester verschiedene Informationen,
z. B. zur Gü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 Kompatibilitätstest erforderlich.
Der Testbetrieb mit einer kleinen Anzahl an Testkandidaten startete im März 2011.
Wie bereits unter Punkt 1 erwähnt, erfolgt die Initialisierung der Smartcards mit persönlichen
Zertifikaten über eine eigens dafür entwickelte Software. Mittels dieser Software werden
für die Karteninhaber persönliche Zertifikate beantragt und auf der Karte ausgegeben.
Die notwendigen organisatorische Regelungen konnten rechtzeitig zur Kartenausgabe
umgesetzt werden.
3 + 4. Installation von Hardware (Smartcard-Reader) und Middleware
Die Computerpools der Informatik wurden zum größten Teil mit Smartcard-Readern ausgestattet.
Für die Universität wurde die Festlegung getroffen, neue Pools bei Beschaffung
mit Smartcard-Readern auszurüsten. Auf diese Art ist in der Zwischenzeit schon eine fast
flächendeckende Nutzung der Karten in Computerpools der Universität möglich.
Die Middleware (OpenSC) wurde erweitert und in eine installationsfertige Form gebracht.
Sie unterstützt die ausgewählten Crypto-Chips und steht aktuell unter den Betriebssystem
Linux zur Verfügung. Eine Windows-Version war Mitte des Jahres 2011 verfügbar und
wurde erweitert, um mit den an der MLU ausgegebenen Karten genutzt werden zu kö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. Für den Feldtest wurde sie
zusammen mit der Middleware in einem Pool des Instituts fü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 Löschen und Wiederbeschreiben des
Kartenaufdrucks ermöglicht.
Projekt 41.03-08-01,
Martin-Luther-Universität Halle-Wittenberg
11

ThinClient mit Reader
lokal?
Netzwerkverbindung
Video / Audio
Tastatur / Maus
ggf. USB
erforderlicher, aber nicht vorhandener Kanal
Server mit Applikationen
Abbildung 7: Anbindung ThinClients
Applikationen
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 E-Mail-Versand und -Empfang über die Universität. Diese Softwa-
Projekt 41.03-08-01,
Martin-Luther-Universität Halle-Wittenberg
12

e soll mit Verschlüsselung und Signatur kombiniert werden, um den Schutz der Inhalte zu
erhöhen und gleichzeitig E-Mail als Medium zur verbindlichen Anmeldung zu etablieren.
Der Grund, mit der Freischaltung zu warten, liegt in der ebenfalls geplanten Umstellung
des universitären E-Mail-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
zusätzliche Sicherheit, um
z.B. den Missbrauch einer
Abbildung 8: Stud.IP Login mit Smartcard
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 Be-
”
sitz des Inhabers“ 9 – dies sollte helfen, prinzipielle Bedenken gegen biometrische Authentifizierung
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 41.03-08-01,
Martin-Luther-Universität Halle-Wittenberg
13

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 E-Mail 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 2011.
Projekt 41.03-08-01,
Martin-Luther-Universität Halle-Wittenberg
14

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.
https://www.bsi.bund.de/cln_156/ContentBSI/Publikationen/
Lageberichte/bsi-lageberichte.html.
[2] Security Confirmation and Report T-Systems.02182.TE.11.2006.
[3] Gesetz über Rahmenbedingungen für elektronische Signaturen (Signaturgesetz - SigG).
[4] 25C3: Analyzing RFID Security. 2009.
http://events.ccc.de/congress/2008/Fahrplan/events/ 3032.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. 2008.
[6] Sparenberg, J. Einführung einer zertifikatsbasierten IEEE 802.1x
Infrastruktur an der Martin-Luther-Universität Halle-Wittenberg.
https://opac.bibliothek.uni-halle.de/DB=1/SET=12/TTL=8/ SHW?FRST=4.
Projekt 41.03-08-01,
Martin-Luther-Universität Halle-Wittenberg
15

[7] Wefel, S. Hardware-Crypto-Token gestütztes Single Sign-On für zertifikatsbasierte Authentifizierung.
2010.
[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. 2011
Projekt 41.03-08-01,
Martin-Luther-Universität Halle-Wittenberg
16

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. 57-59, D-38855 Wernigerode. E-Mail:
hstrack@hs-harz.de,
zusammen mit: Dr. Nico Brehm, nbrehm@hs-harz.de; Dipl.-Ing. (FH) Peter Kußmann,
pkussmann@hs-harz.de; Dipl.-Inf. (FH) Martin Henning, mhenning@hs-harz.de; M.Eng. Nico
Scheithauer, Dipl.-Inf. (FH) Hendrik Werner, hwerner@hs-harz.de
Prof. Dr. Volkmar Richter, Hochschule Anhalt, Lohmannstraße 23, D-06366 Köthen (Anhalt). E-
Mail: volkmar.richter@inf.hs-anhalt.de,
zusammen mit M. Sc. Hagen Weise, hagen.weise@inf.hs-anhalt.de
Förderung:
Dieses Vorhaben wird mit Mitteln der Europäischen Kommission aus dem Europäischen Fonds
für regionale Entwicklung (EFRE) 2007-2013 im Rahmen der Maßnahme 11.03/41.03 gefördert
(FKZ: 11.03-08-03).
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 11.03-08-03,
Hochschule Harz, Hochschule Anhalt
17

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
Projekt 11.03-08-03,
Hochschule Harz, Hochschule Anhalt
18
Prüfungsanmeldungen (Studierende) u.
elektron. Prüfungsbewertungen (Dozenten)
eZeugnis Zeugniskopien Elektronische Erstellung und Management
beglaubigter elektronischer Zeugniskopien
ePraxReg Vereinbarungen für Praxissemester
eBafögSch Leistungsscheine für
Bafög
eSchein Studentische Bescheinigungen
Tabelle 1: die ausgewählten Fachverfahren in eCampus
Elektronische Anmeldung und Vertragsabschlüsse
mit Praxissemesterbetrieben
Elektr. Bafög-Leistungsbescheinigung der
Hochschule für Studierende (f. Bafög-Amt)
Elektron. Studien-Bescheinigungen u. Be-
scheide der Hochschule für Studierende

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):
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)
Projekt 11.03-08-03,
Hochschule Harz, Hochschule Anhalt
19
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)).

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 11.03-08-03,
Hochschule Harz, Hochschule Anhalt
20

Hinsichtlich Umsetzungen von relevanten Sicherheitsaspekten stehen eGovernment-
und 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:
Funktionen
Ziele Si-
Vertraulichkeit
Projekt 11.03-08-03,
Hochschule Harz, Hochschule Anhalt
Integrität Authentizität
Nichtabstreitb
arkeit
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
21

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].
2.3.1 Prozessanalyse (bisherige Abläufe)
Folgende Abbildung veranschaulicht den bisherigen Vorgang der Prüfungsbewertung:
Projekt 11.03-08-03,
Hochschule Harz, Hochschule Anhalt
22

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 11.03-08-03,
Hochschule Harz, Hochschule Anhalt
23

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):
3.3.2 Ü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 11.03-08-03,
Hochschule Harz, Hochschule Anhalt
24

funktionen in eigenprogrammierte Anwendungen integriert werden (höherer Entwicklungs-Aufwand).
3 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 11.03-08-03,
Hochschule Harz, Hochschule Anhalt
25

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).
3.2 Übersicht: Realisierung der OSCI-Shell-HIS-Architektur (RZ)
Die in Kapitel 3.3.2 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 11.03-08-03,
Hochschule Harz, Hochschule Anhalt
26

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 11.03-08-03,
Hochschule Harz, Hochschule Anhalt
27

Nutzer
Dozent
Netzwerklabor
OSCI-Intermediär
(inkl. Telesignatur)
HTTPS
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.
3.4.1 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 11.03-08-03,
Hochschule Harz, Hochschule Anhalt
Webportal eVerfahren
eCampus-Server
Mediator
Rechenzentrum
FW
FW
HTTPS
HTTPS
HTTPS
OSHC-Mediator
Pull (eSchein)
Push (eExamReg)
FW
eCampus-Registry
HIS-Server
LSF - QISPOS
28

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).
3.4.2 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.
Remote-
File-System
OSCI-Server
OSCI-Shell-HIS Component (OSHC)
HIS Procedure
Archive
Projekt 11.03-08-03,
Hochschule Harz, Hochschule Anhalt
OSCI Message
Handler
Mediator
(exchange via file system)
Governikus
Communicator
(OSCI-Client)
HIS Procedure
Manager
HIS Procedure
Operator
HIS HTTP Client
Bild 2: Komponentenstruktur der OSCI-Shell-HIS-Komponente
3.4.3 Lösungsansatz eExamReg
In
HIS-Server
(HTTP)
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ü-
29

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.
Bild 3: OSCI-Shell-HIS: Schritte/Komponenten für automat. Notenzustellungen
Projekt 11.03-08-03,
Hochschule Harz, Hochschule Anhalt
30

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):
Projekt 11.03-08-03,
Hochschule Harz, Hochschule Anhalt
POS / HIS
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.
31

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.
Labor-PCs
Teilnehmerlisten
Projekt 11.03-08-03,
Hochschule Harz, Hochschule Anhalt
Dozent
Testat-Ergebnis-Liste
Datenbank
Prüfungsamt
Applikationsserver
Bild 5: Überblick Prozessanalyse Labortestate (bisherige Abläufe)
3.5.1 Ü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
32

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.
eTestate-Server
Testat-Verwaltung
Registrierungs-PC
Dozent
Bild 6: Überblick eProzess-Redesign eTestate (mit eGov-Komponenten wie nPA)
3.5.2 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 11.03-08-03,
Hochschule Harz, Hochschule Anhalt
OSCI-Intermediär
OSHC-Mediator
U-M-Konverter
Telesignatur-Server
Autom. Eintragung
HIS-Server
33
Prüfungsamt
(Prüfung bei Bedarf)

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.):
Authentisierungs-
Formular
https
Dozenten-Rechner
eID-Server
https
Testat-Verwaltung
Projekt 11.03-08-03,
Hochschule Harz, Hochschule Anhalt
SAML-Request/-Response Dateisystem
https
Web-Server
LDAP-Server
RZ-Automat inkl. U-M-Konverter
OSCI-HIS-Mediator
U-M-Konverter
Telesignatur-Server
Bild 7: Überblick Architektur und Realisierungen eTestate
3.5.3 Realisierungen eTestate
OSCI-Intermediär
Prüfungs-Amt
HIS-System
Datenbank
Der Mediator wurde um eine matrikelnr-orientierte eTestat-Schnittstelle für entsprechende
HIS-Einträge ergänzt.
34

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.
3.6 Realisierungsstand eBafögSch
3.6.1 Ü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).
Projekt 11.03-08-03,
Hochschule Harz, Hochschule Anhalt
Bild 8: Überblick Prozessanalyse (bisherige Abläufe)
35

3.6.2 Ü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.
Applikationsserver
(HIS)
Prüfungsamt
Anfrage
Student
Abruf/Bearbeitung
Zustellung
Projekt 11.03-08-03,
Hochschule Harz, Hochschule Anhalt
Formularserver
Bafög-Beauftragter
(Sammel-)Zustellung
Applikationsserver
Bafög-Amt
Adapter
Bild 9: Überblick eProzess-Redesign eBafögSch (mit eGov-Komponenten)
36

3.6.3 Ü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 11.03-08-03,
Hochschule Harz, Hochschule Anhalt
37

- 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:
Projekt 11.03-08-03,
Hochschule Harz, Hochschule Anhalt
trifft nicht
zu
trifft weniger
zu
trifft mittelmäßig
zu
trifft ziemlich
zu
Index Benutzeroberfläche 1 2 3 4 5
A1 Die Benutzeroberfläche kann intuitiv
bedient werden
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.
trifft zu
X
38

4.3 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 11.03-08-03,
Hochschule Harz, Hochschule Anhalt
39

4.6 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 11.03-08-03,
Hochschule Harz, Hochschule Anhalt
40

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
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: http://zef.bfinv.de/, Letzter Zugriff: 17.09.2010
[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: http://www.senatspressestelle. bremen.de/detail.php?id=11601, Letzter Zugriff:
28.09.2010
[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 11.03-08-03,
Hochschule Harz, Hochschule Anhalt
41

[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 www.sachsen-anhalt.de, 2007.
[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: www.his.de/publikation und
http://www.his.de/presse/material/it/HISinOne.pdf , Zugriff 28.11.2011
Projekt 11.03-08-03,
Hochschule Harz, Hochschule Anhalt
42

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-06099 Halle (Saale).
E-Mail: Martin.Kohlmann@verwaltung.uni-halle.de
Projektmitarbeiter:
Lars Deumer (Umsetzung Universität Halle),
E-mail: Lars.Deumer@verwaltung.uni-halle.de
Michael Spindler (Umsetzung Kunsthochschule Halle),
E-mail: spindler@burg-halle.de
Michael Hoffmann (Umsetzung Kunsthochschule Halle).
E-mail: michah@burg-halle.de
Elena Sazina (Umsetzung Hochschule Merseburg),
E-Mail: 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)
2007-2013 im Rahmen der Maßnahme 11.03/41.03 gefördert (FKZ: 41.03-09-01).
Zusammenfassung
Burg Giebichenstein
Kunsthochschule Halle
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 41.03-
09-01, 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.
43

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 41.03-09-01, Verbundprojekt
Martin-Luther-Universität Halle-Wittenberg
Burg Giebichenstein Kunsthochschule Halle
Hochschule Merseburg
44

Gliederung des Zwischenberichtes
Zusammenfassung ............................................................................................................................. 43
1 Projektphase „Analyse“.............................................................................................................. 46
1.1 Ziele und Vorgehensweise bei der Analyse ................................................................... 46
1.2 Darstellungsweise der Referenzprozesse ...................................................................... 46
1.3 Analyse der IST-Prozesse und Erstellung der Referenzprozesse.............................. 47
1.4 Evaluierung der Referenzprozesse ................................................................................. 49
1.5 Nutzen für andere Hochschulen ....................................................................................... 49
2 Projektphase „praktische Umsetzungen“ ................................................................................ 49
3 Ergebnisse 2010 / 2011 ............................................................................................................. 51
3.1 Ergebnisse der Analyse ..................................................................................................... 51
3.2 Ergebnisse der praktischen Umsetzungen ..................................................................... 52
3.2.1 Ergebnisse an der Martin-Luther-Universität Halle-Wittenberg ........................... 52
3.2.2 Ergebnisse an der Hochschule Merseburg ............................................................ 53
3.2.3 Ergebnisse an der Burg Giebichenstein Kunsthochschule Halle ........................ 56
3.3 Hochschulübergreifende Schulungen ............................................................................. 58
3.4 Zusammenarbeit mit anderen Projekten ......................................................................... 59
Literatur- und Quellenverzeichnis .................................................................................................... 59
Projekt 41.03-09-01, Verbundprojekt
Martin-Luther-Universität Halle-Wittenberg
Burg Giebichenstein Kunsthochschule Halle
Hochschule Merseburg
45

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 41.03-09-01, Verbundprojekt
Martin-Luther-Universität Halle-Wittenberg
Burg Giebichenstein Kunsthochschule Halle
Hochschule Merseburg
46

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 41.03-09-01, Verbundprojekt
Martin-Luther-Universität Halle-Wittenberg
Burg Giebichenstein Kunsthochschule Halle
Hochschule Merseburg
47

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 41.03-09-01, Verbundprojekt
Martin-Luther-Universität Halle-Wittenberg
Burg Giebichenstein Kunsthochschule Halle
Hochschule Merseburg
48

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 41.03-09-01, Verbundprojekt
Martin-Luther-Universität Halle-Wittenberg
Burg Giebichenstein Kunsthochschule Halle
Hochschule Merseburg
49

„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 41.03-09-01, Verbundprojekt
Martin-Luther-Universität Halle-Wittenberg
Burg Giebichenstein Kunsthochschule Halle
Hochschule Merseburg
50

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 / 2011
3.1 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 41.03-09-01, Verbundprojekt
Martin-Luther-Universität Halle-Wittenberg
Burg Giebichenstein Kunsthochschule Halle
Hochschule Merseburg
51

Die EFRE-Projektgruppe stellt im Internet auf den Seiten der Universität Halle
(http://verwaltung.uni-halle.de/abteilung_5/efre/) 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
3.2.1 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 E-Mail 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 41.03-09-01, Verbundprojekt
Martin-Luther-Universität Halle-Wittenberg
Burg Giebichenstein Kunsthochschule Halle
Hochschule Merseburg
52

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 E-mail. 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.
3.2.2 Ergebnisse an der Hochschule Merseburg
Projekt 41.03-09-01, Verbundprojekt
Martin-Luther-Universität Halle-Wittenberg
Burg Giebichenstein Kunsthochschule Halle
Hochschule Merseburg
53

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 10.04 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 41.03-09-01, Verbundprojekt
Martin-Luther-Universität Halle-Wittenberg
Burg Giebichenstein Kunsthochschule Halle
Hochschule Merseburg
54

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 41.03-09-01, Verbundprojekt
Martin-Luther-Universität Halle-Wittenberg
Burg Giebichenstein Kunsthochschule Halle
Hochschule Merseburg
55

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.
3.2.3 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 41.03-09-01, Verbundprojekt
Martin-Luther-Universität Halle-Wittenberg
Burg Giebichenstein Kunsthochschule Halle
Hochschule Merseburg
56

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 2011.
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 41.03-09-01, Verbundprojekt
Martin-Luther-Universität Halle-Wittenberg
Burg Giebichenstein Kunsthochschule Halle
Hochschule Merseburg
57

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 41.03-09-01, Verbundprojekt
Martin-Luther-Universität Halle-Wittenberg
Burg Giebichenstein Kunsthochschule Halle
Hochschule Merseburg
58

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, 2002.
[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, 2008.
[3] http://www.swimlane.info 2011 [abgerufen am 05.05.2011]
[4] Becker J., Kugeler M., Rosemann M., Prozessmanagement: Ein Leitfaden zur prozessorientierten
Organisationsgestaltung, 6. Auflage , Springer Verlag 2008.
Projekt 41.03-09-01, Verbundprojekt
Martin-Luther-Universität Halle-Wittenberg
Burg Giebichenstein Kunsthochschule Halle
Hochschule Merseburg
59

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,
39106 Magdeburg. E-Mail: rolf.knocke@OvGU.de
Friedemann Hass, Leiter des Rechenzentrums, Hochschule Harz (FH), 38855 Wernigerode.
E-Mail: fhass@hs-harz.de
Projektmitarbeiter:
Nataliya Kulyk, Mitarbeiterin des Universitätsrechenzentrums, Otto-von-Guericke Universität
Magdeburg. E-Mail: nataliya.kulyk@ovgu.de
Georges Gebara, Mitarbeiter des Rechenzentrums, Hochschule Harz (FH).
E-Mail: 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) 2007-2013 im Rahmen der Maßnahme 11.03/41.03 gefördert
(FKZ: 11.03-08-02).
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 11.03-08-02,
OvGU Magdeburg / FH Harz
61

Inhaltsverzeichnis
1 Ausgangssituation ................................................................................... 63
1.1 HS Harz .................................................................................... 63
1.2 OvGU Magdeburg ..................................................................... 64
2 Zielvorstellung ......................................................................................... 65
2.1 Soll-Zustand HS Harz ............................................................... 65
2.2 Soll-Zustand OvGU Magdeburg ................................................ 66
3 Umsetzung der Zielvorstellung ............................................................... 67
3.1 Softwareverwendung ................................................................ 68
3.2 Aufbau des Verzeichnisbaumes ................................................ 68
3.3 LDAP Schema ........................................................................... 69
3.4 Gruppen-, Rollen- und Rechtekonzept ...................................... 69
3.5 Zusammenfassung der Umsetzung .......................................... 70
4 Anschluss weiterer Systeme .................................................................. 71
4.1 Shibboleth ................................................................................. 71
4.1.1 Grundsätzliches Verfahren ........................................................ 72
4.1.2 Föderationen ............................................................................. 72
4.2 Bibliotheksverbund (HS Harz) ................................................... 74
4.3 Mailsystem ................................................................................ 74
4.4 Active Directory ......................................................................... 74
5 Nachteile der momentanen HISinOne-Version ...................................... 75
6 Zusammenfassung .................................................................................. 76
Literatur ........................................................................................................... 77
Projekt 11.03-08-02,
OvGU Magdeburg / FH Harz
62

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 11.03-08-02,
OvGU Magdeburg / FH Harz
63

1.2 OvGU Magdeburg
Projekt 11.03-08-02,
OvGU Magdeburg / FH Harz
Bild 1: Vereinfachte Ausgangsserverstruktur der HS Harz
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
sos sva
LDAP int LDAP ext
endsys endsys
meinAcc
LDAP
endsys
Oracle DB
endsys
Kontaktbüro
Bild 2: Vereinfachte Ausgangsserverstruktur der OvGU Magdeburg
64

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 11.03-08-02,
OvGU Magdeburg / FH Harz
65

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.
Projekt 11.03-08-02,
OvGU Magdeburg / FH Harz
HIS
MetaDir
ADS int LDAP
endsys
Bild 3: Vereinfachte künftige Serverstruktur an HS Harz
2.2 Soll-Zustand OvGU Magdeburg
Gäste
endsys meinAcc
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-
RZ
TK
66

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, Email, 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.
IT-Service-Point/
Kontaktbüro
Projekt 11.03-08-02,
OvGU Magdeburg / FH Harz
Account-
service
ADS
endsys
Bild 4: Vereinfachte künftige Serverstruktur an OvGU Magdeburg
3 Umsetzung der Zielvorstellung
MetaDir
(LDAP)
Um die Projektarbeit zeitgemäß und effektiv zu gestalten, wurde zunächst eine Recherche
über existierende Nutzerverwaltungen an unterschiedlichen Hochschulen
durchgeführt.
HIS
endsys
TK
…
67

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 11.03-08-02,
OvGU Magdeburg / FH Harz
68

3.3 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 11.03-08-02,
OvGU Magdeburg / FH Harz
69

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 11.03-08-02,
OvGU Magdeburg / FH Harz
70

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 11.03-08-02,
OvGU Magdeburg / FH Harz
71

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.
4.1.1 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.
4.1.2 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 11.03-08-02,
OvGU Magdeburg / FH Harz
72

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
Bibliothek
Wiss. DB
E-Learning
Bibliothek
Wiss. DB
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 11.03-08-02,
OvGU Magdeburg / FH Harz
SP
SP
SP
SP
SP
SP
HS Harz
OvGU
IdP
IdP
WAYF
73

undeslandeigenen 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 Email-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 11.03-08-02,
OvGU Magdeburg / FH Harz
74

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 13.05.2011, teilweise früher, bei HIS an-
Projekt 11.03-08-02,
OvGU Magdeburg / FH Harz
75

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 24.-25.11.2010 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 11.03-08-02,
OvGU Magdeburg / FH Harz
76

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 176–181, 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: 978-3642047190, Februar 2010
[4] Peter Gietz: Personenschema für das HIS-LDAP-Projekt (Vortragsfolien des Treffens des ZKI AK-
Verzeichnisdienste vom 28-29.06.2005)
[5] Peter Gietz: Standardbasierte LDAP- Schemata für Personen- und Organisationsdaten,
10.02.2006
[6] Netscape Directory Deployment Guide - Directory Tree Design,
[http://docsrv.sco.com/INT_DirectoryDeploy/dit.htm#1014759]
[7] LDAP-Server für X.509-Zertifikate, Markus Grieder ,Stephan Zehnder, 19.Mai 2000
[8] IntegraTUM Teilprojekt-Dokumentation Verzeichnisdienste. Version 1072
[https://www.zki.de/fileadmin/zki/Arbeitskreise/VD/Protokolle/2006-05-08/beitrag_vd-ak_2006-05-
08_schema-integratum.pdf]
[9] Identifiers, Authentication, and Directories: Best Practices for Higher Education. 2000. Internet2
Middleware Initiative
[10] „Architekturempfehlung zur Zentralisierung der Namens- und Verzeichnisdienste“ des Ministerialblattes
34/2008, Anlage 2 zur IT-Strategie
[11] http://lsc-project.org/wiki/start
[12] http://www.biblio.tu-bs.de/anmeldung2/doc/
[13] His-Magazin 3/2009 : Seite 14, Spalte „LDAP“ : http://www.his.de/pdf/pub_mag/mag-200903.pdf
[14] [https://www.aai.dfn.de/]
[15] [https://www.aai.dfn.de/der-dienst/verlaesslichkeitsklassen/]
[16] [http://www.daasi.de/projects/ndsaai.html]
[17] [http://www-fr.redi-bw.de/]
Projekt 11.03-08-02,
OvGU Magdeburg / FH Harz
77

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,
39106 Magdeburg. E-Mail: joachim.weimann@ovgu.de
Prof. Dr. Abdolkarim Sadrieh, Otto-von-Guericke-Universität Magdeburg, Universitätsplatz 2,
39106 Magdeburg. E-Mail: sadrieh@ovgu.de
Juniorprof. Dr. Stephan Thomsen, Otto-von-Guericke-Universität Magdeburg, Universitätsplatz
2, 39106 Magdeburg . E-Mail: stephan.thomsen@ovgu.de
Förderung:
Dieses Vorhaben wird mit Mitteln der Europäischen Kommission aus dem Europäischen Fonds
für regionale Entwicklung (EFRE) 2007-2013 im Rahmen der Maßnahme 11.03/41.03 gefördert
(FKZ: 11.03-09-02).
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 11.03-09-02,
Otto-von-Guericke-Universität Magdeburg
79

Inhaltsverzeichnis
1 Einleitung .................................................................................................. 81
1.1 Die Bedeutung experimenteller Wirtschaftsforschung ............... 81
1.2 Die experimentelle Methode...................................................... 81
1.3 Grenzen der experimentellen Methode ..................................... 82
1.4 Kernaufgaben des Projekts ....................................................... 82
1.5 Methodische Probleme, die das Projekt lösen soll .................... 82
2 Das Experimentallabor in Magdeburg, MaXLab .................................... 83
2.1 Relevanz des MaXLabs ............................................................ 83
2.2 Nutzungsmöglichkeiten des MaXLabs ...................................... 83
3 Zeitplan ..................................................................................................... 84
3.1 Überblick der Arbeitspakete ...................................................... 85
4 Integrierte Forschungsdatenbank .......................................................... 86
4.1 Grundaufbau der Integrierten Forschungsdatenbank ................ 86
4.2 Forschungsplattform ................................................................. 87
4.3 Experimentalserver ................................................................... 87
4.4 Forschungsserver ..................................................................... 88
4.4.1 Veröffentlichung der Dateicontainer .......................................... 88
4.4.2 Zugriff auf Dateicontainer .......................................................... 89
4.5 Kooperationsmöglichkeiten ....................................................... 89
4.6 Gesamtüberblick ....................................................................... 90
5 Kostenplan ............................................................................................... 91
Projekt 11.03-09-02,
Otto-von-Guericke-Universität Magdeburg
80

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 11.03-09-02,
Otto-von-Guericke-Universität Magdeburg
81

1.3 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 11.03-09-02,
Otto-von-Guericke-Universität Magdeburg
82

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 11.03-09-02,
Otto-von-Guericke-Universität Magdeburg
83

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
Projekt 11.03-09-02,
Otto-von-Guericke-Universität Magdeburg
Bild 1: Zeitplan, Stand: Ende November 2011
84

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
Projekt 11.03-09-02,
Otto-von-Guericke-Universität Magdeburg
Bild 2: Überblick der Arbeitspakete
85

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 11.03-09-02,
Otto-von-Guericke-Universität Magdeburg
86

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 (http://www.microsoft.com/Outlook)
und GoogleMail (http://mail.google.com)), Aufgabenplanung und den
Austausch von Dokumenten (Schnittstelle zur Dropbox (https://www.dropbox.com)).
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 11.03-09-02,
Otto-von-Guericke-Universität Magdeburg
87

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-E-Mails 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.
4.4.1 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 11.03-09-02,
Otto-von-Guericke-Universität Magdeburg
88

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.
www.xresearch.de/publication/h8jf3d) 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.
4.4.2 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 11.03-09-02,
Otto-von-Guericke-Universität Magdeburg
89

4.6 Gesamtüberblick
Bild 4: Gesamtüberblick der Integrierten Forschungsdatenbank
Projekt 11.03-09-02,
Otto-von-Guericke-Universität Magdeburg
90

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) 17.967,16 € 8.755,33 € 26.722,49 €
2009
gezahlt 31.522,00 € 8.935,00 € 40.457,00 €
Ist Ausgaben 17.967,16 € 8.755,33 € 26.722,49 €
Plan (geändert) 89.204,84 € 13.689,67 € 102.894,51 €
2010
gezahlt 57.210,93 € 13.510,00 € 70.720,93 €
Ist Ausgaben 72.201,36 € 13.387,95 € 85.589,31 €
Plan (geändert) 75.650,00 € 6.559,00 € 82.209,00 €
Plan (geändert) einschl. Ausg.rest 94.089,07 € 6.559,00 € 100.648,07 €
2011
gezahlt 38.372,43 € 3.017,83 € 41.390,26 €
Restabforderung für 2011 51.569,23 € 3.541,17 € 55.110,40 €
Ist Ausgaben per 30.09.2011 55.581,21 € 5.078,20 € 60.659,41 €
2012 Plan 75.650,00 € 4.329,00 € 79.979,00 €
2013 Plan 25.216,00 € 1.580,00 € 26.796,00 €
Projekt 11.03-09-02,
Otto-von-Guericke-Universität Magdeburg
Tabelle 1: Kostenplan, Stand 17.10.2011
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, 269-299, 1987. (Preprinted
in Economics and Philosophy, Vol. 2, 245-273, 1986.)
[2] Fischbacher, Urs (1998): ”z-Tree: Zurich Toolbox for Readymade Economic Experiments. Instruktionen
für Experimentatoren”, mimeo, University of Zurich.
91

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, 39106 Magdeburg). E-Mail: springer@ovgu.de
Förderung:
Dieses Vorhaben wird mit Mitteln der Europäischen Kommission aus dem Europäischen Fonds
für regionale Entwicklung (EFRE) 2007-2013 im Rahmen der Maßnahme 11.03/41.03 gefördert
(FKZ: 11.03-09-01).
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 11.03-09-01,
Otto-von-Guericke-Universität Magdeburg
93

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 11.03-09-01,
Otto-von-Guericke-Universität Magdeburg
94

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 E-Mail-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 2009. 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 11.03-09-01,
Otto-von-Guericke-Universität Magdeburg
95

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 11.03-09-01,
Otto-von-Guericke-Universität Magdeburg
96

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 11.03-09-01,
Otto-von-Guericke-Universität Magdeburg
97

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

2.4 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
2.4.1 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.
2.4.2 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.
Projekt 11.03-09-01,
Otto-von-Guericke-Universität Magdeburg
Bild 5: Beispiel einer Pre-Chat-Seite im System LiveZilla
99

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.
2.4.3 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 11.03-09-01,
Otto-von-Guericke-Universität Magdeburg
100

Online-Serviceportal „campus2go“
Ausführende Einrichtung(en):
Hochschule Magdeburg-Stendal
Projektleiter:
Frank Richter, Kanzler der Hochschule Magdeburg-Stendal, Postfach 3655, D-39011 Magdeburg.
E-Mail: kanzler@hs-magdeburg.de
Kornelia Hartmann, Zentrum für Kommunikation und Informationsverarbeitung (ZKI), Hochschule
Magdeburg-Stendal, Postfach 3655, D-39011 Magdeburg.
E-Mail: kornelia.hartmann@hs-magdeburg.de
Christian Neumann, Zentrum für Kommunikation und Informationsverarbeitung (ZKI), Hochschule
Magdeburg-Stendal, Postfach 3655, D-39011 Magdeburg.. E-Mail: christian.neumann@hs-magdeburg.de
Förderung:
Dieses Vorhaben wird mit Mitteln der Europäischen Kommission aus dem Europäischen Fonds
für regionale Entwicklung (EFRE) 2007-2013 im Rahmen der Maßnahme 11.03/41.03 gefördert
(FKZ: 11.03-08-01).
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 11.03-08-01,
Hochschule Magdeburg-Stendal
101

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 103
2 Identitätsmanagement 104
3 Single Sign-on 105
4 Rechtemanagement 106
5 Personalisierte Seiten 108
6 Communities 111
7 Einsatz des digitalen Personalausweis für das Identity-Management 112
8 Mobile Version 113
9 IT-Sicherheit 116
10 Nachhaltigkeit 117
Literatur/Quellen 117
Projekt 11.03-08-01,
Hochschule Magdeburg-Stendal
102

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 6.0.5
- Applikationsserver: Tomcat 6.0.26
- Hochsprache: Java 6
- Datenbanksystem: PostgreSQL 8.4
- Single Sign-on: CAS-Server 3.4.5
- 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 11.03-08-01,
Hochschule Magdeburg-Stendal
103

Projekt 11.03-08-01,
Hochschule Magdeburg-Stendal
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.
104

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 11.03-08-01,
Hochschule Magdeburg-Stendal
105

Projekt 11.03-08-01,
Hochschule Magdeburg-Stendal
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/-
106

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, E-Mail, 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.
Projekt 11.03-08-01,
Hochschule Magdeburg-Stendal
Bild 4: Moodle im Studierendenportal
107

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
E-Mail 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
5 Personalisierte Seiten
Projekt 11.03-08-01,
Hochschule Magdeburg-Stendal
Tabelle 1: Rechtemanagement im Studierendenportal
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
108

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

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.
Projekt 11.03-08-01,
Hochschule Magdeburg-Stendal
Bild 7: Auswahl an verschiedenen Themes
110

Projekt 11.03-08-01,
Hochschule Magdeburg-Stendal
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.
111

Projekt 11.03-08-01,
Hochschule Magdeburg-Stendal
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
112

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 11.03-08-01,
Hochschule Magdeburg-Stendal
113

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.
Projekt 11.03-08-01,
Hochschule Magdeburg-Stendal
Bild 11a: Die Semestertermine in campus2go
114

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 11.03-08-01,
Hochschule Magdeburg-Stendal
115

Da die Palette an mobilen Geräten groß und vielseitig ist, wurden Testgeräte ausgesucht,
deren Betriebssysteme am weitesten verbreitetet sind. Das waren im November
2009 Symbian, Windows Mobile und iPhone OS. Mittlerweile ist auch Googles Betriebssystem
Android im Kommen, wovon aber noch kein Testgerät erworben wurde.
Neben der Geräteerkennung gilt es beim Testen auch auf das Layout zu achten, da
durch unterschiedliche Designlösungen die Bildschirmauflösung verschieden ist. Das
Portal wurde für die folgenden Geräte getestet:
Gerät Betriebssystem Auflösung
PDA Windows Mobile 2003 240 x 320
iPhone 3Gs iPhone OS 320 x 480
iPad iPhone OS 1024 x 768
Nokia 5800 Symbian 60 360 x 640
HTC Windows Phone 7 800 x 480
9 IT-Sicherheit
Das Portal wird durch verschiedene Einstellungen und Maßnahmen vor Datenverlust,
Lauschangriffen oder unbefugten Zugriffen gesichert. So sind die Authentifizierung und
die Dienste, die der Liferay-Server anbietet, SSL verschlüsselt. Außerdem wird bei der
Authentifizierung das Benutzerpasswortes nicht in der Portaldatenbank gespeichert.
Der CAS-Server gleicht den Account nur mit dem LDAP ab. War die Anmeldung erfolgreich,
erhält der/die Nutzer/-in ein User-Ticket. Bei Inaktivität verfällt das User-Ticket
voreingestellt nach 2 Stunden und der/die Nutzer/-in muss sich beim CAS-Server neu
anmelden.
Der Zugriff auf das Portal war in der Entwicklungsphase nur im Hochschulnetz oder
über VPN möglich. Seitdem der CAS-Server und das Portal in die DMZ verschoben
wurden und sich im produktiven Einsatz befinden, sind die Dienste weltweit über die
Webports ansprechbar. Ausnahmen sind die im Portal eingebetteten HIS-Dienste für
Studenten/-innen und Mitarbeiter/-innen, deren Maschinen sich weiterhin im Hochschulnetz
befinden und von außerhalb nur über VPN zu erreichen sind. Mit
Smartphones ist die Einwahl ins VPN nur bei iPhones und Android-Geräten möglich,
wobei für Android-Geräte erst eine Server-seitige Lizenz von Cisco erworben werden
musste. Für Windows Phone 7 existiert derzeit kein VPN-Client.
Des Weiteren ist für das Portal wichtig, dass die Portaldatenbank auch bei fehlgeschlagenen
Zugriffsoperationen in einem konsistenten Zustand bleibt. Daher wurde als
Datenbanksystem PostgreSQL verwendet. In PostgreSQL wird standardmäßig jeder
SQL-Befehl in einer eigenen Transaktion durchgeführt und diese Transaktion wird am
Ende des Befehls automatisch abgeschlossen, wenn sie erfolgreich war. Ansonsten
wird die Transaktion zurück gerollt [3].
Projekt 11.03-08-01,
Hochschule Magdeburg-Stendal
116

Für das serverseitige Backup befindet sich auf dem Portal ein TSM-Client (Tivoli Storage
Manager) der täglich die zu sichernden Daten automatisch zum TSM-Server sendet.
Der TSM-Server archiviert die Daten dann in seinen SAN (Storage Area Network).
Die Datensicherung des Home-Verzeichnisses erfolgt automatisch über das zentrale
Backup-System der Hochschule. Der Nutzer ist verantwortlich dafür, dass alle zu sichernden
Dateien auf dem Fileserver der Hochschule abgelegt werden.
Damit die sensiblen Daten nicht nur Server-seitig, sondern auch Client-seitig vor Dritten
geschützt sind, befindet sich auf dem Portal für die Nutzer/-innen eine Sicherheitsrichtlinie
für mobile Geräte. In ihr werden Vorbeugemaßnahmen für Diebstahlschutz
und Schadsoftware beschrieben, woran man eine sichere Verbindung erkennt und das
Bluetooth- oder WLAN-Verbindungen bei Nichtgebrauch wieder zu schließen sind.
Weiterhin hat das Bundesamt für Sicherheit in der Informationstechnik [7] umfassend
zum Thema mobile Endgeräte und mobile Applikationen und zu Gefährdungen und
Schutzmaßnahmen berichtet, deren Kernpunkte in den Sicherheitsrichtlinien des Portals
nachzulesen sind. Umfassendere Untersuchungen erschienen uns auf Grund der
Komplexität der Veröffentlichungen beim BSI nicht notwendig.
10 Nachhaltigkeit
In die Projektarbeit waren jeder Zeit und themenspezifisch Mitarbeiterinnen und Mitarbeiter
des ZKI involviert, so dass neben der Projektdokumentation grundsätzliche Informationen
zu den Arbeitsinhalten und verwendeten Technologien vorhanden sind.
Alle Abstimmungen und Projektschritte sind im ZKI-Team erfolgt.
Zur weiteren systemtechnischen Betreuung und zur Sicherung des Betriebs des Web-
Portals wird das Projekt an das WEB-Team des ZKI übergeben.
Gemeinsam mit dem ZIM, das Medienzentrum der Hochschule Magdeburg- Stendal,
ist im Nachgang zu Projekt campus2go die Erstellung von multimedialen Lerneinheiten
zur Handhabung des Webportals geplant. Entsprechende Maßnahmen sind bereits
eingeleitet.
Literatur/Quellen
[1] Liferay, Open-Source-Portal, http://www.liferay.com, 2010
[2] CAS, Central Authentification Server, http://www.jasig.org/cas, 2010
[3] PostgreSQL, Das offizielle Handbuch, 2010
http://www.postgresql.org/files/documentation/books/pghandbuch/html/sql-begin.html
[4] DPA (Deutsche Presseagentur), Der elektronische Bürger, 2010
http://www.news.de/technik/855079179/der-elektronische-buerger/1/
[5] Herbert Reichl, Alexander Roßnagel, Günter Müller; Digitaler Personalausweis: eine Machbarkeitsstudie,
2010
http://books.google.de/books?id=9uFUlg1D8UIC&pg=PA269&lpg=PA269&dq=Zertifikat+digitale
r+Personalausweis&source
Projekt 11.03-08-01,
Hochschule Magdeburg-Stendal
117

[6] BSI (Bundesamt für Sicherheit und Informationstechnik), Der neue Personalausweis, 2010
https://www.bsi-fuerbuerger.de/BSIFB/DE/SicherheitImNetz/Personalausweis/Personalausweis_node.html
[7] BSI (Bundesamt für Sicherheit und Informationstechnik), Mobile Endgeräte und mobile Applikationen:
Sicherheitsgefährdungen und Schutzmaßnahmen, 2011
https://www.bsi.bund.de/ContentBSI/Publikationen/Broschueren/mobile/index_htm.html,2011
[8] Webportal, http://de.wikipedia.org/wiki/Portal_(Informatik)
[9] Webseiten, http://de.wikipedia.org/wiki/Webseite
[10] Webanwendungen , http://de.wikipedia.org/wiki/Webanwendung#Abgrenzung
Projekt 11.03-08-01,
Hochschule Magdeburg-Stendal
118