Ja, vielen Dank. Meine sehr geehrten Damen und Herren
. Ich freue mich, dass ihr jetzt hier
ein bisschen was über das Thema Identity Management berichten darf.
Bei uns in München ist das Ganze eine inhärent hochschulübergreifende Angelegenheit,
was aber nicht nur daran liegt,
dass wir mit dem LAZ in München jetzt eben einen gemeinsamen zentralen IT-Dienstleister für mehrere Hochschuleinrichtungen haben,
sondern da steckt schon noch ein bisschen mehr dahinter.
Darauf möchte ich als erstes kurz eingehen.
Danach werden wir uns zwei fundamental verschiedene Ansätze anschauen,
wie man solche Identity Management-Projekte angehen kann.
Einmal fängt man auf der grünen Wiese an.
Einmal ist es eher eine Evolution. Das eine geht aus
dem Projektintegratum hervor. Das wurde ja letztes Jahr hier schon
mal vorgestellt andere Variante ist eben direkt beim LAZ intern,
wie dort die Benutzer- und Berechtigungsverwaltung gemacht wird.
Und obwohl diese beiden Ansätze gemeinsam eine Basis bilden für ein gemeinsames Ziel,
gibt es dann noch einen dritten Ansatz,
der das Ganze wieder etwas revolutioniert hat,
nämlich die Variante über Föderationen, also der Einsatz von Chipodez,
zum Beispiel im Rahmen der DFN-AI.
Und auch darauf, welche Strategien wir hier verfolgen im
Münchner Raum, möchte ich ein bisschen näher eingehen.
Sie haben sie ja vorher beim Herrn Apostolesco schon gehört.
Wir sind eben der zentrale Dienstleister für die Münchner Hochschulen,
insbesondere die beiden Münchner Universitäten
Und allein dadurch, dass die eben sehr viele Studenten und Mitarbeiter haben,
kommen wir im Münchner Raum schon auf über 100.000 Benutzer,
die wir entsprechend im Identity Management abbilden und unterstützen müssen.
Wichtig ist auch, dass wir zwar der zentrale technische IT-Dienstleister sind,
dass die beiden Universitäten aber eigene Verwaltungs-IT-Zentren haben,
insbesondere werden also auch die Campus-Management-Systeme mit Studenten und Personalverwaltung von den Universitäten selbst betrieben.
Wir haben also nicht unbedingt den ganz direkten Zugriff auf die Daten,
wie man es für ein Identity Management benötigt.
Das sind aber nicht die einzigen Benutzer, die wir bei uns haben,
sondern klarerweise sind wir eben noch eines der drei nationalen höchsten Das heißt,
uns Rechenzentren im technisch- wissenschaftlichen Bereich,
wir haben die große Maschine bei uns stehen,
die hat der Herr Apostelesco vorher auch schon vorgestellt,
die uns vor gewisse Stromversorgungsprobleme stellt oder zumindest die nächste Generation dann.
Da läuft es so, die ist zur Hälfte vom Bund und vom Land finanziert. Das heißt,
es gibt ein deutschlandweites Gutachtergremium, desto darüber entscheidet,
wer auf dieser Maschine,
wie viel rechnen darf und entsprechend bekommen wir auch Wissenschaftler nicht nur aus dem Münchner Raum,
sondern eben aus ganz Deutschland, auf dieser Maschine drauf,
mit bestimmten Berechtigungen, die wir auch wieder intern abbilden müssen.
Und wir sind seit einigen Jahren auch an diversen europäischen und internationalen Projekten beteiligt,
sogenannte Grid-Projekte, also Verbünde von Hochleistungsrechenzentren,
wo die Rechenkapazitäten und Ressourcen nochmals gebündelt werden,
um die wirklichen Grand-Challenges in der Informatik auch lösen zu können.
Und da ist es so, jeder,
jedes dieser Grid-Projekte hat wieder eine eigene Benutzerverwaltung,
ein eigenes Identity-Management umgesetzt, dass wir entsprechend aufgreifen müssen,
anbauen müssen, anzapfen müssen,
um hier die Benutzer auch bei uns in den Datenbestand reinzubekommen.
Im Endeffekt sieht das Ganze dann so aus,
dass eben aus verschiedenen anderen Einrichtungen die Benutzerdaten bei uns am LAZ zusammenfließen.
Und es ist eben nicht nur so,
dass jede dieser anderen Einrichtungen, egal ob die reale Einrichtungen sind,
also eine Universität oder ob es eine virtuelle Einrichtung ist,
wie ein Grid-Projekt, eine eigene Benutzerverwaltung hat,
sondern die Benutzermengen überlappen sich auch noch,
was ein klassisches Problem im Identity-Management ist.
Das kennt jede Hochotschule bei sich intern. Man hat Studierende, die gleichzeitig auch Mitarbeiter sind,
möchte die aber nur einmal und nicht mehrfach als digitale Identität erfassen.
Und wir haben das Problem eben noch dadurch verstärkt,
dass dieselben Personen auch noch aus verschiedenen Einrichtungen zu uns kommen.
Wir haben also klassischerweise zum Beispiel gemeinsame Studiengänge der Biden München- und Universitäten,
wie Bioinformatik oder auch Medizin, wo die Studenten an beiden Hochowen matrikuliert sind,
aber es gibt natürlich auch eine ganze, digitale Reient, die ment, die deckert e, eassoccen, e d, was auch eas eason, minngrat. Und das mös de em,
e em, d, misent, ment, prodeln,
e e, seent, e t, se ot t,
e e d, t, ment, e t,
t, e t t, e t,
e ement, se ment e, e,
e t t t t, e, t,
e t e. Et t t e, e set t e e,
e e t t t em e e e,
t e, e Erstmal ein eigenes lokales,
autarkes Identi-Management hat, dass dann die Basis dafür bildet,
dass man gemeinsame Konzepte darauf aufbauen kann und im engeren Münchner Raum sieht es so aus,
dass zum Beispiel die LMU eine der ersten Hochschulen in ganz Deutschland war,
die sich auch mit dem Thema Identity-Management befasst hat,
insbesondere die Kombination aus einem hochschulweiten Portal,
mit Identity-Management.
Das läuft dann unter Campus-LMU,
das ist zum Beispiel der Herr Degenhardt mit aufgebaut hat,
an der TU München ist das Thema Identity-Management so wichtig,
dass es eigentlich zwei Projekte gab, die sich damit befasst haben.
Zum einen eben das Integratumprojekt,
dass eher die technische Infrastruktur aufgebaut hat anderen, das Tom-Online-Projekt,
das sich auch mit der Einführung eines neuen Campus-Management-Systems befasst,
wo es eher um die organisatorischen Prozesse dahinter geht.
Und am LAZ machen wir das Ganze natürlich nicht nur für das Rechenzentrum selbst,
sondern auch für die bayerische Akademie der Wissenschaften, zu der wir gehören.
Und da wollen wir jetzt mal auf einige Beispiele ein bisschen näher eingehen.
Zunächst mal das Projektintegratum. Das wurde Ihnen ja letztes Jahr
hier bei dieser Veranstaltung schon vom Herrn Borges vorgestellt,
der hat das Projekt geneigtet hat.
Das Projekt ist also vor einigen Monaten zu Ende gegangen.
Und wie Sie hier sehen, es gab insgesamt neun Teilprojekte.
Später kam noch ein zehntes mit dazu,
IT-Service-Management für die TU München befasst hat und die drei gelb hinterlegten in der Grafik sind,
die Projekte, die das LAZ durchgeführt hat,
in enger Kooperation mit der TU.
Und ganz in der Mitte als zentrales technisches Teilprojekt
haben wir eben den Reich Verzeichnisdienst, Identity-Management.
Und dass wir eben auch eine Dienstleistung des LAZ,
dass wir eine solche technische Identity-Management-Infrastruktur aufbauen für einen unserer Kunden, nämlich die TU.
Und wie wir das in den vorherigen Vorträgen schon öfter gesehen haben,
es kommt im Wesentlichen darauf an,
dass man eine klare Schnittstelle definiert,
wo die Daten zu fließen haben und wie die Dienste
aufeinander aufbauen sollen
Und der Vorteil für uns bei Integratom war jetzt,
dass die Daten aus einem zentralen System geliefert worden sind, nämlich aus dem Tom-Online-System.
Das ist insbesondere also die Personalverwaltung und die Studentenverwaltung,
die früher auch auf Hist-Software basiert hat, inzwischen eben direkt in Tom-Online abgebildet wird, zusammenfasst.
Und wir bekommen dann in unser zentrales Meta-Derektorit bereits konsolidierte Daten geliefert, müssen uns also nicht selber darum kümmern, dass wir Studenten und Mitarbeiterdaten zusammenführen. Und eine andere Besonderheit,
die wir hier gerne im LAZ verfolgen, ist,
dass wir vor einer gewissen Komplexität nicht zurückscheuen,
wenn sich dadurch die Kanierbarkeit verbessert,
Und im Unterschied zu vielen anderen Projekten haben wir das Ganze so gemacht,
dass wir nicht nur einen Verzeichnisdienst haben, ein zentrales Meta Directory,
sondern dass wir die Daten verteilen auf insgesamt vier Verzeichnisdienste,
die jeweils einen leicht anderen Anwendungszweck haben,
entsprechend auch andere Daten in leicht unterschiedlichen Formaten vorhalten,
was auch so ein bisschen in Richtung Datenschutz in Sicherheit geht,
weil wir eben immer nur genau die Daten vorhalten müssen,
die von den Darin angeschlossenen Systemen auch wirklich benötigt werden.
Beispielsweise haben wir also einen Applikationsverzeichnisdienst, der das zentrale E-Learning-System,
das passiert an der Tür in München
auch auf Klicks von IMC
Mit Daten versorgt, die ganzen Bibliotheksysteme können darüber mit Daten versorgt werden.
Zum anderen haben wir einen auf die Systemadministration ausgelegten Verzeichnisdienst,
an denen sind zum einen die ganzen Fakultäten angebunden.
Der Theo München, die also beispielsweise eigene Open-Ail-Lup-Server betreiben oder auch eigene Active Directorist betreiben,
um hier Windows-Rechner-Pools oder auch Linux, Studentenpuls zu betreiben.
Und zum anderen werden darüber aber auch die zentralen LLZ-Dienste mit Daten versorgt,
beispielsweise eben Exchange als Gruppe-Lösung in unserer zentralen Fileserver auf Basis von NetUp-Acliences,
die wir hier auch im Rahmen vollen Integratoren für die Theo München aufgebaut haben.
Und ein ganz wichtiger, aus technischer Sicht sehr wichtiger,
Verzeichnisdienst ist der für die Authentifizierung und Autorisierung.
Daran können sich nämlich beliebige, dezentrale Dienste anschließen.
Auf diesen Zug sind wir es aufschauen,
über 50 noch dezentral betriebene Dienste aufgesprungen, damit wir also umsetzen können,
dass man für jeden Dienst nur noch dasselbe,
denselben Benutzernamen und dasselbe Passwort benötigt und sich nicht mehr getrennt registrieren muss.
Und zum anderen bildet das dann auch die Basis für den Anschluss an,
die deutschlandweite DFN-Föderation,
die Authentifizierung sind Authentifizierungs- und Autorisierungs- und Authentifizierungsinfrastruktur vom DFN-Verein,
wo unser schibuläres Authentity-Provider mit dranhängt
Was bringt uns das Ganze außer einer gewissen Basiskomplexität?
Es ist sehr erweiterbar. Wir haben den Vorteil bei Integratum,
dass eben die Daten schon korreliert zur Verfügung gestellt werden.
Wir als eine sehr gute Grunddatenqualität erreichen können. Und mit
der Einführung von Tom Online hat sich auch die Veränderung ergeben,
dass sich sämtliche Studenten und auch die Mitarbeiter bereits online bewerben.
Sie bekommen bereits bei dieser Online-Anmeldung ihre Kennung zugeteilt.
Die hat am Anfang natürlich nur sehr eingeschränkte Berechtigungen,
nämlich dieses Bewerbungssystem zu verwenden,
kann dann aber stichtagsgemäß freigeschaltet werden,
zum Beispiel am ersten Vorlesungstag
Mit den entsprechenden Berechtigungen ausgestattet werden. Und damit euch sparen wir es uns eben,
dass wir den Leuten per Post irgendwelche Initialbriefe mit Staatkennung und Staat Passwort zuschicken müssen.
Und ein weiterer Vorteil, den uns Tom Online hier bietet,
ist, dass wir Self-Services anbieten, Map basiert,
die aber eben auch einen Schreibzugriff haben und nicht nur eine reine Selbstauskunft sind.
Das heißt, wenn ein Student in München umzieht, was ja häufiger vorkommt,
weil es da recht lange Wartelisten gibt für die Studentenwohnheime,
dann kann er seine Adressänderung direkt in dem System eintragen und sie wird innerhalb weniger Sekunden weiter propagiert an alle anderen Systeme.
Es läuft also nicht mehr wie früher,
dass man sich ein Formular bei der Verwaltung als PDF runterladen kann,
das aber trotzdem ausdrucken muss, ausfüllen muss, abgeben muss,
dann wird es wieder abgetippt und zieht sich ein paar Tage lang hin,
sondern hier geht es wirklich innerhalb weniger Sekunden dann sofort.
Das war jetzt die Variante, wo man also für die
TU München von Grund auf ein neues Identity-Management-System aufgebaut haben.
Jetzt als Gegenbeispiel dazu, wie sich das Ganze am LAZ selbst entwickelt hat. Und da ist es so,
dass es sich verlagert hat von einer eigentlich rein manuellen Datenerfassung,
die so umfangreich war,
dass wir sie delegieren mussten an Administratoren bei unseren Kunden,
die sogenannten Master-User, wurden Ihnen ja auch schon vorgestellt,
hin zu einer wirklich völlig automatischen Datenübernahme aus verschiedenen autoritativen Datenquellen,
wie eben beispielsweise den Campus-Management-Systemen, die wir jetzt an den Universitäten in München haben.
Und das Ganze sah oder es sieht immer noch so aus,
dass es für verschiedene Zielgruppen eine zentrale, große Web-Anwendung gibt,
unser sogenanntes Athentity-Management-Portal. Und das benutzen beispielsweise unsere sogenannten LAZ-Betreuer,
die sind also bei uns im Haus für die Benutzer- und Berechtigungsverwaltung zuständig,
spezialisieren sich aber darauf,
unsere Kunden und die Verträge mit diesen Kunden zu erfassen,
aber darüber prinzipiell die Möglichkeit,
wirklich den kompletten Datenbestand zu bearbeiten und zu verändern.
Demgegenüber haben wir pro Kunde, der mit uns einen Projektvertrag abgeschlossen hat,
mindestens einen technischen Ansprechpartner, den sogenannten Master-User.
Der bekommt also einen Pool von Kennungen zugewiesen,
zum Beispiel 20 Kennungen für einen Lehrstuhl und kann diese dann selber delegiert administrieren,
indem er beispielsweise für neue Mitarbeiter neue Kennungen einrichtet,
denen bestimmte Berechtigungen gibt.
Er kann das Passwort zurücksetzen, wenn es mal vergessen worden ist.
Er kann die E-Mail-Grund von Konfiguration und Ähnliches
mehr machen
Ist aber in diesem Fall, wenn es über Handarbeit funktioniert,
eben eine Mehrfacherfassung der Person. Einmal an der Heimathochschule und
einmal eben für den LAZ-Datenbestand. Dann jenen gibt es die Self-Services,
damit können die Benutzer selber ihre E-Mail-Adresse ändern,
ein Passwort ändern und ähnliches mehr. Und auch für unseren Service-Desk,
wenn also jemand an der Theke steht bei uns oder wir einen Kunden am Telefon haben,
dass man sich mal schnell anschauen kann,
welche Kennungen hat er denn,
welche Berechtigungen hat er,
wo können wir potenziell Probleme auftreten,
dann können hier auch entsprechende Recherchefunktionen
genutzt werden können
Das ist eben mit sehr viel Handarbeit verbunden und das wollen wir
dadurch ändern und haben so viele Bereiche auch schon dadurch geändert,
dass wir Daten eben automatisch übernehmen.
Sieht dann so aus, dass eben jede dieser Einrichtungen,
wie die LMU in München,
die Theo in München und ein Grid-Projekt wie Daisa,
eigene Identity-Management-Systeme haben und wir die Daten aus diesen Systemen auslesen können,
bei uns aggregieren können und auch korrelieren können.
Und für diese drei Beispiele verfolgen wir jetzt auch immer noch
einen klassischen Meta-Direktor-Ansatz. Das heißt, die Daten werden über
eine Verzeichnisdienstsynchronisation
zu uns übernommen
In einem vorher vereinbarten Umfang und werden dann bei uns
eingebracht in den anderen Datenbestand, den wir schon haben,
der eben insbesondere auch aus diesem Webfrontend gespeist wird,
dass damit hoffentlich langfristig an Bedeutung verliert oder andere Aufgaben wahrnehmen kann.
Und wo wir eben beispielsweise auch unsere eigenen Personalverwaltungsdaten mit einkippen.
Und diese Daten werden dann natürlich wie an den Universitäten auch
den zentralen Diensten zur Verfügung gestellt, wo es eben zwei Möglichkeiten gibt.
Entweder greifen die Dienste direkt über LAP auf diesen Datenbestand zu
oder werden im Sinne eines Previsioning-Systems mit diesen ganzen Informationen versorgt
Das heißt, wir haben in beiden Fällen,
entweder wir fangen auf der grünen Wiese an,
oder es gibt eine gewisse Evolution der Methoden,
trotzdem dasselbe Ziel, dass der Datenbestand hier hochschulübergreifend genutzt werden kann.
Und diese Verzeichnisdienstsynchronisation war vor einigen Jahren eben noch die einzige
technische Möglichkeit, die wir dafür hatten.
Inzwischen gibt es ja glücklicherweise Federleitete Identity Management,
auch vom DFN eben deutschlandweit angeboten.
Und das hat gewissermaßen auch die Diensterbringung bei uns an den
Münchner Hochschulen revolutioniert. Und da möchte ich jetzt eben auch noch
ein bisschen näher drauf eingehen
Am LAZ unterstützen wir das Verfahren deshalb so gerne,
weil es eben viele proprietäre Ansätze,
die wir früher getrennt unterstützen mussten, ablösen kann.
Das heißt, egal ob wir es im Bereich der Bibliotheken haben,
mit dem Zugang zu elektronischen Medien,
ob wir es im Grid Computing haben, mit der Scientific Visualisation,
oder auch ob wir es im Bereich E-Learning haben.
Da gibt es zum Beispiel die virtuelle Hochschule Bayern,
die Studenten von einer Universität in Bayern an Eloning Kurse,
an anderen Universitäten vermittelt.
Alle diese Verfahren wurden bislang über proprietäre Protokolle abgewickelt
und können jetzt hier auf Basis von Scheboles
eben einheitlich unterstützt werden
Und da haben wir auch gesagt,
wir verwenden wirklich die Standard-Software dafür, nämlich Schibbelness,
einfach weil es kein offizieller Standard ist,
aber halt von den meisten verwendet wird und weil es dafür auch einen sehr guten Support gibt,
sowohl von den Entwicklern und auch von der Community her her,
als auch vom DFN über die DFN-RAI-Hotline und ein anderer Vorteil ist,
dass uns diese Software auch den Zugang,
den parallelen Zugang zu mehreren Föderationen ermöglicht.
Wir sind ja nicht nur an der DFN-AI beteiligt hier in Deutschland,
sondern zum Beispiel auch an der Dizer-Föderation eben europaweit integriert.
Und das wäre mit vielen anderen Softwarepaketen,
die vielleicht ein bisschen einfacher zu administrieren oder auch zu installieren wären,
nicht so möglich, wie es uns hier eben Chevules bietet.
Das ist aber eben die Betreibersicht aus Rechenzentrumssicht.
Es macht vieles für uns einfacher im Betrieb. Die Hochschulen,
also unsere Kunden sehen das Ganze aber ein bisschen anders.
Für die reduziert es in erster Linie eben die Hürde,
die immer vorhanden ist, wenn man externe Dienste nutzen möchte,
weil man sich bislang eben von Hand registrieren musste,
beim jeweiligen externen Dienstanbieter, geeignet nachweisen musste,
dass man wirklich von einer berechtigten Hochschule kommt und einen entsprechenden Status hat,
sei es durch eine Überprüfung der E-Mail-Adresse oder sogar durch das portalische Einstecken von immaterial Traditionsbestätigungen und Ähnlichem.
Und dieses über Schibudes und die DFNAI abzuwickeln,
ist eine Sache von einigen Sekunden bis wenigen Minuten und eben nicht mehr mit der Verzögerung verbunden,
die wir mit den bisherigen Verfahren hatten.
Und zum anderen ermöglicht die DFN-AAI oder Schibudes allgemein ja auch ein Single sein On,
zumindest mal für Webbasierte Dienste oder auch für Web-Services,
was wieder im Good-Computing-Umfeld wichtig ist.
Und das hört man dann als Anlass dazu genommen, zu sagen,
wir wollen ja eigentlich auch Hochschulintern ein Single sein On haben.
Und auch da hat man dann gesagt,
wir nehmen als Softwarebasis Schibudes dafür her.
Hat einen
relativ einfachen Grund
Zum einen ist es eben so, wenn wir verschiedene Webportale haben,
sei es ein Vorlesungsverzeichnis und ein davon gekrenntes E-Learning-System.
Und die sind aber einheitlich gestaltet,
gestaltet im Sinne einer Corporate Identity,
eines einheitlichen Designs und dann noch über ein technischer Single-Sign-On-Miteinander verbunden,
dann wirkt es aus Benutzersicht eben wie ein sehr stark integriertes System,
die merken zum Teil dann gar nicht mehr den Unterschied oder wissen nicht,
dass da ganz unterschiedliche Administratoren oder zentrale Einrichtungen an der Hochschule dahinter stecken,
die das Ganze dann betreiben.
Zum anderen ist es
ein gewisser Vorteil aus Sicherheitsperspektive
Denn wir haben es ja geschafft, mit Einerkennung und einem Passwort
alle Dienste nutzbar zu machen oder fast alle Dienste nutzbar zu machen,
die es an den Hochschuhen gibt.
Was aber dazu führt, dass man als Benutzer
sein Passwort auch an zig verschiedenen Stellen eingeben muss,
was immer mit einem gewissen Sicherheitsrisiko verbunden ist.
Zum Beispiel, wenn der Dienst bösartig ist oder auch nur kompromittiert ist,
könnte er ja die entsprechenden Passwörter im Klartext abfangen. Dadurch,
dass wir das auf ein Single sein On-Verfahren umstellen,
wo man sein Passwort immer nur an einer einzigen zentralen Stelle
einen vertrauenswürdigen Webdienst eingibt und alle anderen Dienste verlassen sich darauf,
dass der Benutzer authentifiziert ist,
können wir hier
diese Sicherheitseigenschaften verbessern
Und warum gerade auch Schipponess für das Hochschulinterne Single Sign-On,
ganz einfach, es gibt eine ganze Reihe von Diensten,
die wir eben auch externen Benutzern anbieten möchten.
Zum Beispiel eben im Rahmen der virtuellen Hochschule Bayern,
die Nutzung der E-Learning-Systeme und der ganzen Kurse, die drüber laufen.
Und wenn man das System sowieso schon an Schipponess anpassen muss,
damit es von Externe genutzt werden kann,
dann ist es sehr viel einfacher,
wenn die über dasselbe Verfahren auch das Hochschulinterne Single Sign-On durchgeführt
werden kann und man da nicht zwei verschiedene Varianten unterstützen muss.
Und ganz klar, die treibende Kraft führt den Einsatz von
Schipponess oder auch für den Aufbau von Föderationen,
eben nicht nur Umfeld,
ist das E-Learning
Es ist anders als an vielen anderen Hochschulen in Deutschland,
wo das Ganze eher aus der Ecke der Bibliotheken kommt,
mit dem Zugang zu Verlagsangeboten und Datenbankangeboten,
die von entsprechenden kommerziellen Dienstleistern hier betrieben werden.
Da ist es auch so, dass die TU München
zum Beispiel die Firma IMC dafür bezahlt hat,
dass Klicks angepasst wird an das DFN-A-I-E-Learning-Profil.
Und das war dann auch eine der ersten kommerziellen Learning-Management-System-Plattformen,
die entsprechend auch dieses DFN-Profil unterstützt hat.
An der TU ist es sehr einheitlich gehalten, nur mit Klicks im Einsatz.
An der LMU ist die ganze Sache ein bisschen heterogener, einfach ein Grund,
dass gerade die Mediziner eher fallbasierte E-Learnings-Systeme brauchen, wie beispielsweise eben Chasos.
Dort sind aber andere Open-Source-Klassiker wie Mudel und Olad auch noch sehr stark im Betrieb.
Und die LMU ist ja auch eine der deutschen Hochschulen,
die von Apple des iTunes You University-Angebot nutzt,
um also über iTunes Vorlesungsmitschnitte anbieten zu können und auch iTunes You ist Schibules-fähig.
Die sind momentan nur in der amerikanischen Föderation drin,
wollen es aber auch in die DFN-AI eintreten. Und da ist dann auch wieder der Vorteil,
dass man den Zugang zu bestimmten Materialien,
zum Beispiel gerade im Bereich Medizin, ist es erforderlich,
in den Vorlesungsunterlagen, zum Beispiel Patientenfotos gibt,
die nicht allen zugänglich gemacht werden dürfen, dass man sagt,
diese Unterlagen sind auch wirklich nur für Medizinstudenten oder eben für den eingeschränkten Benutzerkreis zugänglich.
Und das Ganze wird auch schon produktiv eingesetzt.
Natürlich einerseits im Rahmen dieser gemeinsamen Studiengänge im Münchner Raum,
aber auch deutlich über den Münchner Raum hinaus.
Zum Beispiel hat die LMU eine sehr enge Kooperation mit den Spätzern,
mit der Uni Zürich,
wo dann auch beispielsweise Eloning Kurse für Porthologie und Dermatologie,
die in Zürich mit einem Urlaubssystem angeboten werden,
von LMU-Studenten über Shippodeus genutzt werden können
Und wo es da hingeht,
sind eben einerseits mal wirklich die Abwicklung aller Eloning Kurse,
die jetzt zum Beispiel im Rahmen der virtuellen Hochschule Bayern angeboten werden,
über dieses Verfahren.
Dann muss natürlich auch die VHB in Bayern noch dran arbeiten,
nicht nur die jeweiligen Hochschulen.
Und zum anderen wollen wir auch eine direkte Verlinkung der E-Learning-Angebote
raus aus den zentralen Campus-Management-Systemen schaffen.
Das heißt, man schaut sich die Vorlesungsübersicht an,
klickt dann auf eine Link und ist direkt beim elektronischen Angebot zu dieser Vorlesung.
Das wäre bislang ohne Single
sein On eben auch nicht möglich gewesen
So, wenn wir das Ganze nochmal zusammenfassen,
die Ausgangsbasis im München-Raum ist wirklich, dass jede Einrichtung erstmal ihr eigenes Aidentity-Management-System betreibt.
Das ist also fundamental anders, als es zum Beispiel hier
in Hamburg gemacht wird und funktioniert im Münchner Raum mit diesen Anforderungen auch sehr gut.
Die Synchronisation, der Verzeichnisdienste sorgt dafür eine sehr enge Verzahnung der Systeme,
die wir haben und ist aber natürlich mit einem gewissen Implementierungsaufwand verbunden,
der dann jeweils von beiden Seiten erbracht werden muss. Deshalb sehen wir da auch,
dass es einfach bei der Nutzung der Föderationsdienste einen ganz massiven Aufwachs geht,
was dann eben auch damit genutzt wird,
dass man hochschulintern ebenfalls diese Technologie einsetzt und wo es eben hingehen wird,
ist, dass wir LAZ-seitig mehr und mehr auf Automatismen setzen,
dass wir Benutzerdaten automatisch übernehmen können, dass wir auch automatisch Berechtigungen,
je nach Herkunft und Rolle der Benutzer vergeben und dass eben auch die Scheboles passierte Dienstnutzung noch weiter, noch stärker ausgebaut werden wird.
Gut, dann danke ich für Ihre Aufmerksamkeit und wenn es noch Fragen gibt,
stehe ich natürlich jetzt oder auch heute Abend noch gerne zur Verfügung.