RRZE – Projekte & Prozesse (P&P)

Hintergrund

Im November 2006 startete das Projekt zum Aufbau einer zentralen Identity Management-Infrastruktur mit der Zielsetzung, eine Grundlage für die effiziente Nutzung der universitären IT-Dienste bereitzustellen (siehe Projektleitdokument vom 20.12.2006). Die damals festgelegten strategischen Ziele haben bis heute Bestand:

• Bewältigung der steigenden Verwaltungsanforderungen
• Vermeidung duplizierter Datenbestände
• Erhöhung der Benutzerfreundlichkeit
• Entlastung der Sachbearbeiter und Administratoren
• Erhöhung der Datenqualität und Validität
• Erhöhung der Datensicherheit

Hinzu kam im Laufe des Projekts der Aspekt der Systemintegration, der durch ein IdMS nicht nur gefördert, sondern erst grundlegen ermöglicht wird.

Am 8. Oktober 2008 gingen erste Teile “hinter den Kulissen” in den produktiven Betrieb. Seitdem wurden auf dieser Basis eine Vielzahl von Erweiterungen entwickelt, welche das heutige IdMS letztendlich ausmachen. Das Grundkonzept blieb im Kern erhalten.

Alle folgenden Ausführungen beziehen sich auf den aktuellen Stand des Systems.

Quellsysteme

Als Quellsysteme werden Systeme bezeichnet, aus welchem das IdMS Daten liest. Die Quellsysteme des IdMS können grob in folgende Kategorien unterteilt werden:

• Personenverwaltungssysteme
• Strukturverwaltungssysteme
• Sonstige Systeme

Aktuell sind folgende Personenverwaltungssysteme angebunden:

• Stammdatensystem für Studierende HIS SOS
• Personalverwaltungssystem VIVA
• Indirekt über das IdM-nahe Personenverwaltungssystem für “Sonstige” (Yet Another AFFiliation, kurz yaaff) als Qualitätssicherungsschicht:
  • Informationssystem UnivIS
  • Promovierendenverwaltung docDaten
  • Personenverwaltungssystem FAU Busan
  • Sonstigenverwaltung RRZE

Der einzige Vertreter der Kategorie Strukturverwaltungssysteme ist die zentrale Anwendung zur Pflege der Organisationsstruktur FAU.ORG.

Vertreter der Kategorie “Sonstige Systeme” sind u.a. Systeme welche die Datenhoheit für mindestens ein Attribut besitzen. Zum Beispiel werden die offiziellen Mailadressen nicht im IdMS erzeugt bzw. festgelegt, sondern aus dem System zur Reservierung von Mailadressen abgefragt.

Kern

Der Kern des IdMS besteht aus einer Vielzahl von einzelnen Modulen. Während ein Teil der Module die korrekte Zusammenführung von Personeneinträgen aus unterschiedlichen Quellsystemen übernimmt, berechnet ein anderer Teil die ableitbaren Dienstleistungen. Allen gemein ist das zugrundeliegende Meta-Directory, also die IdMS gespeicherten Daten.

Änderungen in Quellsystemen sollen möglichst zeitnah aufbereitet und in alle betroffenen Systeme synchronisiert werden. Darunter fallen auch Aktionen der Anwender in den Web-Anwendungen; allen voran das Setzen eines neuen Passworts. Die Auswirkungen reichen von einfachen Wertänderungen in einem Attribut bis hin zur kompletten Neuanlage oder Löschung eines Kontos.

Zielsysteme

Als Zielsysteme werden Systeme bezeichnet, in welche das IdMS Daten schreibt. Aktuell sind folgende Zielsysteme angebunden:

• Zentraler Anmeldedienst der Universität Erlangen-Nürnberg (Single Sign-On)
• Studierendenverwaltung HIS SOS
• mein campus
• Promovierendenverwaltung docDaten
• Mail-Adressen-Reservierungssystem der FAU
• Mail-Relay-System der FAU
• Mailinglistenverwaltung Mailman
• FAUmail (Dovecot)
• Windows Exchange
• Novell Groupwise
• WLAN eduroam
• Windows Active Directory (AD)
• Novell Directory Services (NDS)
• Versionskontrollsysteme via gvcsadmin
• Web-Anwendung FAU.ORG
• Kartenproduktionssystem der FAUcard
• Bibliothekssystem SISIS
• “Alte” RRZE-Benutzerverwaltung
• Zutrittskontrollsystem Siport (im Aufbau)
• Forschungsdatenbank (im Aufbau)

Frontends

Als Frontends werden Systeme bezeichnet die beispielsweise im Rahmen einer Webanwendung Zugriff auf bestimmte Daten und Funktionen des IdMS bieten.

IdM-Portal

Das IdM-Portal gliedert sich derzeit in die Bereiche “Self Service” und “Anfragen/Aufgaben”.

Der Self Service ermöglicht den im IdMS verwalteten Person die Einsicht von gespeicherten persönlichen Daten zum Zwecke der Datenschutzselbstauskunft. Desweiteren kann der Benutzer den Status der verfügbaren Dienstleistungen einsehen und Aktionen zur Konto- und Diensteverwaltung durchführen.

Der Bereich Anfragen/Aufgaben ermöglicht es, u.a. auch langlaufende Prozesse mit mehreren Beteiligten Personen einfach zu verwalten.

Administration

Die Administrationsfunktion im IdMS bietet Mitarbeitern des RRZE und der FAU mit Aufgaben im IdM-Umfeld erweiterten Zugriff auf die zur Durchführung nötigen Daten.

Dazu gehören z.B. die Mitarbeiter der Service-Theken, die so Benutzern bei Problemen mit ihrem IdM-Zugang oder einzelnen Dienstleistungen auf Anfrage Hilfestellung geben können. Die häufigsten Fälle sind das Wiederherstellen vergessener Passwörter und die Hilfe bei der Konfiguration einzelner Dienstleistungen.

Identitiy Management at the FAU – Background and Current State (Part 3)

Background

In November 2006 the project started to develop a central Identity Management Infrastructure with the aim to provide a basis for the efficient usage of university based IT services (see further  Projektleitdokument from 20.12.2006). The then defined strategic aims are still existing today:

• Management of increasing administrative demands
• To avoid duplicated data storage
• Improvement of user friendliness
• Relief for employees and administrators
• Improvement of data quality and validity
• Improvement of data security

During the course of the project the aspect of system integration was added which can not only be advanced through an IdMS, but be enabled through it in the first place.

On 8. October 2008 first parts “behind the scenes” went into the productive area. Since then multiple enhancements were developed on this base, which in the end make today’s IdMS. The basis concept remains unchanged.

All the following implementations are related to the current state of the system.

Source System

Systems are called source systems which are reading data from the IdMS. The source systems of the IdMS can roughly be separated in the following categories:

• Personal administration systems
• Structural administration systems
• Other systems

At the moment the following personal administration systems are included:

• Master data systems for students HIS SOS
• Personal administration system VIVA
• Indirectly via the near IdM personal administration system for “others” (Yet Another AFFiliation, short yaaff) as a layer for quality management:
  • Information system UnivIS
  • PhD-students administration docDaten
  • Personal administration system FAU Busan
  • Other management RRZE

The only representative of the category structural administration system is the central application to maintain the organizational structure FAU.ORG.

Representatives of the category “other systems” are for example systems which have data sovereignty for at least one attribute. For example official mail addresses are not created or defined in the IdMS but are questioned from the system for the reservation of mail addresses.

Core

The core of the IdMS consists of a multitude of single modules. Whereas a part of the modules takes the correct compilation of personal entries from different source systems, another part computes deducible services. They all have the underlying meta directory in common, thus the in IdMS saved data.

Changes in the source systems should be quickly prepared and synchronized with all the affected systems. These include actions of the users in web applications; especially the setting of a new password. The consequences range from simple value changes in one attribute to the complete new generation or deletion of an account.

Target systems

Systems are called target systems in which the IdMS writes its data. At the moment the following target systems are included:

• Central Sign-ON Service of the University Erlangen-Nuremberg (Single Sign-On)
• Student management HIS SOS
• mein campus
• PhD-student management docDaten
• Mail Addresses Reservation System of the FAU
• Mail Relay System of the FAU
• Mailing list managment Mailman
• FAUmail (Dovecot)
• Windows Exchange
• Novell Groupwise
• WLAN eduroam
• Windows Active Directory (AD)
• Novell Directory Services (NDS)
• Version control system via gvcsadmin
• Web Application FAU.ORG
• Card production system of the FAUcard
• Library system SISIS
• “Old” RRZE user management
• Access control system Siport (in development)
• Researchdatabase (in development)

Front end

Systems are called front end in the frame of a web application which provides access to certain data and function of the IdMS.

IdM-Portal

At the moment the IdM-Portal is structured in the areas “Self Service” and “Requests/Tasks”.

The Self Service offers the persons who are managed in the IdMS to see the saved personal data in order of data privacy self information. Furthermore the user can see the status of the available services and can perform actions for account and service management.

The area requests/tasks offers, among others, to easily manage even long-term processes with multiple participants.

Administration

The administration function in the IdMS offers the RRZE and FAU employees with tasks within the IdM environment an extended access to the data which are needed for the implementation.

It includes e.g. the employees of the service counters who can therefore help users with problems according to their IdM account or individual services on demand. The most frequent cases are the restoration of forgotten passwords and the help with the configuration of individual services.

English Version

Bei der Verwaltung von Grails Plugins in einem zentralen Repository gestaltet sich die lokale Weiterentwicklung der Plugins ggf. schwierig.

Mit dem folgenden Code-Block in der BuildConfig.groovy kann mittels des Kommandozeilenparameters -Dlive=... eines, oder mit
Komma getrennt, mehrere Plugins lokal geladen werden.

Wichtig ist dabei, dass neben dem Hauptprojekt auch alle Plugins mit diesem Code Block ausgestattet werden. So werden auch transitive Abhängigkeiten wie gewünscht mittels relativem Pfad oder aus dem Repository aufgelöst.

/*
* PPSA PLUGIN CONFIGURATION
*/
def runtimePlugins = [
    ":ppsa-menu:latest.release",
    ":ppsa-layout:latest.release",
]

/* ----- BEGIN: no changes past here ----- */
def live = System.getProperty("live")?System.getProperty("live").split(','):[]
def filteredLivePlugins = []
if (live) {
    filteredLivePlugins = live.inject([]) { list, lib ->
        runtimePlugins.grep { it.contains(lib) } ? list << lib : list
    }
    if (filteredLivePlugins) {
        println "[YOUR_PROJECT_NAME_HERE] Loading some plugins from relative paths in the workspace: " + filteredLive
        filteredLivePlugins.each { pluginName -> grails.plugin.location."${pluginName}" = "../${pluginName}" }
    }
}
/* ----- END: no changes past here ----- */

grails.project.dependency.resolution = {
    plugins {
        def filteredRuntimePlugins = runtimePlugins.inject([]) { list, lib ->
            filteredLivePlugins.grep { lib.contains(it) } ? list : list << lib
        }
        if (filteredRuntimePlugins) {
            println "[YOUR_PROJECT_NAME_HERE] Loading plugins from release repository: " + filteredRuntimePlugins
            filteredRuntimePlugins.each { pluginDef -> runtime "${pluginDef}" }
        }
    }
}

Beispiel, wie man zur live Umgebung für das Plugin ppsa-layout wechseln kann:

grails clean -Dlive=ppsa-layout
grails run-app -Dlive=ppsa-layout

Grails Plugins – local and global

With the management of Grails Plugins in a central repository the local further development of plugins could become quite difficult.

With the following Code Block in the  BuildConfig.groovy one or more plugins — sepearted via commas — can be loaded locally instead of from the repository with the help of the command line parameter  -Dlive=....

In order to also resolve transitive dependencies in this way it is important that beside the main project all plugins are also provided with this code block. This way also transitive dependencies can be loaded from a relative path or from the repository.

/*
* PPSA PLUGIN CONFIGURATION
*/
def runtimePlugins = [
    ":ppsa-menu:latest.release",
    ":ppsa-layout:latest.release",
]

/* ----- BEGIN: no changes past here ----- */
def live = System.getProperty("live")?System.getProperty("live").split(','):[]
def filteredLivePlugins = []
if (live) {
    filteredLivePlugins = live.inject([]) { list, lib ->
        runtimePlugins.grep { it.contains(lib) } ? list << lib : list
    }
    if (filteredLivePlugins) {
        println "[YOUR_PROJECT_NAME_HERE] Loading some plugins from relative paths in the workspace: " + filteredLive
        filteredLivePlugins.each { pluginName -> grails.plugin.location."${pluginName}" = "../${pluginName}" }
    }
}
/* ----- END: no changes past here ----- */

grails.project.dependency.resolution = {
    plugins {
        def filteredRuntimePlugins = runtimePlugins.inject([]) { list, lib ->
            filteredLivePlugins.grep { lib.contains(it) } ? list : list << lib
        }
        if (filteredRuntimePlugins) {
            println "[YOUR_PROJECT_NAME_HERE] Loading plugins from release repository: " + filteredRuntimePlugins
            filteredRuntimePlugins.each { pluginDef -> runtime "${pluginDef}" }
        }
    }
}

Example on how to switch to the live environment for the plugin ppsa-layout:

grails clean -Dlive=ppsa-layout
grails run-app -Dlive=ppsa-layout

English Version

In diesem Beitrag zeige ich kurz wie man Grails 2 Plugins als Releases in einem eigenen Maven Repository wie Archiva oder Artifactory verwalten kann. Dafür sind grundsätzlich zwei seperate Konfigurationen für Upload und Download vom Repository nötig.

Upload

Für das Releasen neuer Versionen in das eigene Repository bietet Grails 2 das Release Plugin, das man allerdings erst selbst nachinstallieren muss:

grails install-plugin release

Die nötige Konfiguration dazu wird in die ~/.grails/settings.groovy ausgelagert. Einträge in dieser Datei gelten für alle Grails Projekte und sind äquivalent zu Einträgen in der BuildConfig.groovy.

Hier ein Beispiel zur Einrichtung von Archiva als Release Repository:

/*
* THIS IS FOR UPLOADING TO THE REPO (via release plugin)
* To use this do:
* grails2 install-plugin release
*/
grails.project.repos.default = "rrzeArchiva"

grails.project.repos.rrzeArchiva.url = "http://REPOSITORY:PORT/archiva/repository/internal/"
grails.project.repos.rrzeArchiva.username = "USERNAME"
grails.project.repos.rrzeArchiva.password = "PASSWORD"

// disable nagging about not having committed all changes...
grails.release.scm.enabled = false

Das Beispiel Konfiguriert das rrzeArcchiva Repository als Default für Uploads und deaktiviert die SVN Überprüfung für nicht eingecheckte Änderungen.

Fertig.

Neue Releases können dann mit folgenden Build Targets ins Repository geladen bzw. in den lokalen Maven Cache installiert werden.

grails maven-deploy
grails maven-install

Download

Für den automatischen Download von Plugins aus dem Repository sind folgende Einträge in der BuildConfig.groovy des Projektes nötig.

grails.project.dependency.resolution = {
repositories {
mavenLocal()
mavenRepo name:"rrzeArchiva", root:"http://REPOSITORY:PORT/archiva/repository/internal"
}
plugins {
runtime ":ppsa-menu:latest.release"
}
}

Der Repositories Abschnitt Konfiguriert den lokalen Maven Cache und das Archiva Repository als zu durchsuchende Quellen für Plugin Abhängigkeiten.
Die Plugin Abhängigkeiten selbst werden im eigenen Abschnitt Plugins verwaltet. Der Beispieleintrag lädt immer die aktuellste Version des Plugins ppsa-menu.

Eigentlich würde das nun schon reichen, um Plugins auf dem Repository zu installieren.

Die allermeisten internen Repositories werden jedoch noch zusätzlich eine Authentifizierung erfordern. Hierfür muss noch der folgende Eintrag zur ~/.grails/settings.groovy hinzugefügt werden.

/*
* THIS IS FOR DOWNLOADING FROM THE REPO
* To use this add this to your BuildConfig.groovy:
* mavenRepo name:"rrzeArchiva", root:"http://REPOSITORY:PORT/archiva/repository/internal"
*/
grails.project.ivy.authentication = {
credentials {
realm = "Repository Archiva Managed internal Repository"
host = "REPOSITORY(ohne Port!)"
username = "USERNAME"
password = "PASSWORD"
}
}

—- WICHTIG —-

Für Archiva muss der Realm wie angegeben konfiguriert werden. Sonst geht nix!

Außerdem muss der Host hier ohne Port angegeben werden. Wenn das Archiva also z.B. auf Port 8080 läuft ist diese Angabe hier wegzulassen.
—- WICHTIG —-

In this post I will briefly show how to manage Grails 2 Plugins as releases in an own Maven Repository such as Archiva or Artifactory. Therefore basically two separate configurations for Upload and Download from the repository are needed.

Upload

To release new versions in the own repository Graisl 2 offers the Release Plugin, which though must be installed additionally by yourself:

grails install-plugin release

The necessary configuration for this is stored in the  ~/.grails/settings.groovy. Entries in this data are valid for all Grails projects and equivalent entries in the BuildConfig.groovy.

Here is an example of installing Archiva as release repository:

/*
* THIS IS FOR UPLOADING TO THE REPO (via release plugin)
* To use this do:
* grails2 install-plugin release
*/
grails.project.repos.default = "rrzeArchiva"

grails.project.repos.rrzeArchiva.url = "http://REPOSITORY:PORT/archiva/repository/internal/"
grails.project.repos.rrzeArchiva.username = "USERNAME"
grails.project.repos.rrzeArchiva.password = "PASSWORD"

// disable nagging about not having committed all changes...
grails.release.scm.enabled = false

The example configures the rrzeArcchiva repository as Default for Uploads and deactivates the SVN proof for not-checked-in changes.

Done.

New releases can be loaded with the following Build Target in the Repository, respectively installed the local Maven Cache.

grails maven-deploy
grails maven-install

Download

For the automatic download of plugins from the repository the following entries in the  BuildConfig.groovy of the project are needed.

grails.project.dependency.resolution = {
repositories {
mavenLocal()
mavenRepo name:"rrzeArchiva", root:"http://REPOSITORY:PORT/archiva/repository/internal"
}
plugins {
runtime ":ppsa-menu:latest.release"
}
}

The repository paragraph configures the local Maven Cache and the Archiva Repository as sources for plugin dependencies which have to be browsed.
The plugin dependencies themselves are managed in the own paragraph plugins. The example entry is always loading the most current version of the plugin ppsa-menu.

Actually this would be enough to install plugins on the repository.

Most of all intern repositories will though need further authentication. Therefore the following entry has to be added ~/.grails/settings.groovy.

/*
* THIS IS FOR DOWNLOADING FROM THE REPO
* To use this add this to your BuildConfig.groovy:
* mavenRepo name:"rrzeArchiva", root:"http://REPOSITORY:PORT/archiva/repository/internal"
*/
grails.project.ivy.authentication = {
credentials {
realm = "Repository Archiva Managed internal Repository"
host = "REPOSITORY(ohne Port!)"
username = "USERNAME"
password = "PASSWORD"
}
}

—- IMPORTANT —-

For Archiva the realm must be configured as shown. Or nothing will work!

Also, the Host must be stated here without Port. If the Archiva is also running e.g. on Port 8080 these information can be omitted here.
—- IMPORTANT —-

Quellsysteme

Wenn im Identity Management (IdM) Bereich von Quellsystemen die Rede ist, denkt man häufig sofort an Personenverwaltungen. Die Bereitstellung von Informationen zu Personen ist sicherlich die bedeutendste und außenwirksamste Variante. Quellsysteme eines IdMS können jedoch ganz unterschiedlicher Natur sein. U.a. gehören auch die Lieferung von Daten zur Organisationsstruktur, Mailadressen oder Funktionen in die Kategorie der Quellsysteme. Allen gemeinsam ist, dass sie Informationen bereitstellen, die von anderen, meist mehreren, Systemen genutzt werden.

HIS SOS

Eines der ersten angebundenen Systeme des IdMS an der FAU war die Studierendenverwaltung vertreten durch HIS-SOS. Die Bereitstellung der Daten besteht im Wesentlichen aus zwei Datenbank-Views:

 • idm student
 • idm stg

idm student enthält alle erforderlichen Informationen zur Person der Studierenden. Analog enthält idm stg alle erforderlichen Informationen zum Studium. Verbunden sind beide Views durch die Matrikelnummer, welche gleichzeitig in beiden Fällen den Primärschlüssel für die IdM-Anbindung darstellt.

Zum Auslesen der beiden Views kommt der JDBC-Treiber von Novells Identity Manager zum Einsatz. Um den Aufwand auf Seiten der Betreiber der Studierendenverwaltung gering zu halten, kommt keine Triggertabelle zum Einsatz. Der Vorteil einer Triggertabelle wäre die direkte Bereitstellung aller Änderungen. Der Treiber kann durch ein Lesen dieser Tabelle erkennen, ob Änderungen vorliegen. Falls ja kann er je nach Art der Triggertabelle alle Informationen zur vorliegenden Änderung direkt auslesen, oder nur die betroffenen Datensätze aus den Views holen. Ohne Triggertabelle muss der Treiber die Änderungen durch einen Vergleich mit seiner internen Kopie der Daten selbst erkennen. Liegen keine Änderungen vor, wäre in der Triggertabelle kein Eintrag und die Arbeit des Treibers wäre erledigt; ohne Triggertabelle müssen immer alle Einträge überprüft werden. Aktuell benötigt der Treiber für diese Aufgabe etwas unter 5 Minuten (inkl. SELECT) für beide Views mit je über 60.000 Einträgen. Bei einem Polling-Intervall von aktuell 5 Minuten ist der Treiber in der aktuellen Konfiguration daher am Limit.
Die Synchronisierung der beiden Views in Richtung IdMS wird in den folgenden Abschnitten näher erläutert. Dabei werden grundlegende Kenntnisse des Treiber-Konzeptes von Novell Identity Manager vorausgesetzt. Eine schematische Übersicht liefert Abbildung 3.1.

Abbildung 3.1: Treiber Sos

View idm student

Tabelle 3.3 zeigt das Schema-Mapping und die Filter-Einstellung zwischen dem View idm student und der Objektklasse User (aka inetOrgPerson) im Meta-Directory (MD). In der ”Input Transformation Policy“ wird das Attribut Geschlecht (geschl) anhand der in Tabelle 3.1 aufgeführten Abbildung umgesetzt. Wie in Tabelle 3.3 ersichtlich wird im MD das Attribut schacGender des SCHema for ACademia 2 (SCHAC) verwendet, welches den Standard ISO 5218 einsetzt. Demzufolge werden die Werte wie in Tabelle 3.2 dargestellt interpretiert.

Die ”Matching Policy“ besteht im Wesentlichen aus zwei Teilen. Grundsätzlich wird versucht einen bereits im MD existierenden Personeneintrag zu finden und mit dem neuen Eintrag aus SOS zu verbinden. Ist ein Matching erfolgreich, werden die darauffolgenden Versuche unterlassen; die Reihenfolge ist also entscheidend.
Den ersten Versuch könnte man als ”Standard-Matching“ bezeichnen. Ein bereits aus SOS synchronisierter Eintrag soll damit wiedergefunden werden. Wurde der Eintrag in SOS entfernt und wieder mit der gleichen Matrikelnummer angelegt oder hat der Treiber aus anderen Gründen seine Assoziation (DirXML-Association) verloren, soll diese wiederhergestellt werden. Um dies zu gewährleisten wird ein Matching auf Basis des Primärschlüssels der Anbindung, in diesem Fall also die Matrikelnummer, durchgeführt. Hier wird die Matrikelnummer der Reihe nach in folgenden Attributen gesucht:
1. Attribut fauStudPK

2. Attribut fauStudPKOld

HIS SOS

Die Suche im Attribut fauStudPK stellt sicher, dass keine zwei Einträge mit der gleichen Matrikelnummer im MD existieren bzw. erzeugt werden. Die Suche im Attribut fauStudPKOld soll bereits exmatrikulierte Studierendeneinträge finden. Werden Einträge im View idm student gelöscht oder exmatrikuliert, wird die Matrikelnummer aus dem Attribut fauStudPK in das Attribut fauStudPKOld verschoben. Dieser Fall findet also z.B. Wiedereinschreiber.
Das zweite Matching versucht den neuen Studierendeneintrag anhand der Attribute Vorname, Nachname, Geburtsdatum und Geburtsort beliebigen Personeneinträgen im MD (normalerweise aus anderen Quellsystemen) zuzuordnen. Hierbei kommt das eigens erstellte Framework Data Linkage (DaLi) zum Einsatz. Eine komplette Beschreibung von DaLi würde den Rahmen dieses  Artikels sprengen, weshalb hier nur die für die Einbettung in die Treiber-Logik notwendigen Teile erlaütert werden. Die grundlegende Funktionsweise einer frühen Version des Frameworks können den Folien des Vortrags von Krasimir Zhelev beim ZKI-Arbeitskreis für Verzeichnisdienste vom 06.Oktober 2009 3 entnommen werden.
Zum Zeitpunkt der Anbindung sollte das Matching-Modul möglichst ohne Abhängigkeit zu einem externen Dienst in die Treiber-Landschaft von Novell eingebettet werden. Zu diesem Zweck wurde aus DaLi ein einfaches Jar-Archiv entwickelt, welches nach Eingabe einer Person und möglicher Matching-Kandidaten die besten Treffer mit den Wahrscheinlichkeitswerten ausgibt. Die Einbindung des sog. ”Matching Processor“ erfolgt über eine Namespace- Definition der Matching Policy. Wie in Abbildung 3.2 ersichltlich wird die Java-Klasse de.rrze.idmone.utils.matching.MatchingProcessor an den Namespace matchingProcessor gebunden.

Abbildung 3.2: Matching Policy Namespace Definition

Die eigentliche Verwendung zeigt Abbildung 3.3. In der ersten Zeile wird der Matching Processor instanziert. Dabei werden die Attribute des neuen Personeneintrags übergeben. In der einfachen vereinfachten Version müssen alle möglichen Kandidaten im MD gesucht werden und mittels der Methode addNodeSet übergeben werden. Dabei kann die Methode mehrfach aufgerufen werden um weitere Suchergebnisse hinzuzufügen. Der Methodenaufruf nodeSetMatching startet die Auswertung. In der aktuellen Version vergleicht DaLi über 10000 Kandidaten innerhalb einer Zehntelsekunde. Die Beschränkung liegt hier eindeutig bei den LDAP-Suchen im MD. Nach der Auswertung können die Trefferwahrscheinlichkeiten abgefragt werden. Die Entscheidung ob der neue Eintrag mit einem existierenden Eintrag zusammengeführt wird bleibt so im Treiber bestehen.
Wird kein vorhandener Personeneintrag gematcht folgt die ”Creation Policy“. Hier findet die Überprüfung der zwingend erforderlichen Attribute statt. Fehlt eines dieser Attribute wird die Anlage verweigert. Sind alle erforderlichen Attribute vorhanden wird in der “Placement Policy” der DN des neuen Personeneintrags festgelegt. Dieser wird aus dem Personencontainer, einem eindeutigen Treiber-Prefix und der Matrikelnummer gebildet. Im Anschluss werden einige Attribute für einen neuen Personeneintrag gesetzt. Darunter fallen z.B. die initiale Gruppenmitgliedschaft und ein Anfangspasswort.

Abbildung 3.3: Verwendung des Matching Processor

In der ”Command Policy“ werden weitere Aktionen sowohl bei der Neuanlage als auch bei Aktualisierungen durchgeführt. So werden z.B. Löschungen in SOS in die bereits erwähnte Verschiebung der Matrikelnummer in das Attribut fauStudPKOld umgewandelt. Weiterhin findet eine Verlinkung mit dem evtl. bereits synchronisierten Informationen zum Studium statt, oder die Entscheidung ob eine vorhandene Kontaktadresse überschrieben werden soll.

Identity Management at the FAU – Student Management (Part 2)

Source Systems

If within the Identity Management (IdM) area the topic source system appears you might immediately think about personnel management. The provision of information about persons is surely the most important variety and most affective to the outside.   Source systems however can be of very different kind. Among others the delivery of data for the organizational structure, mail addresses or functions belong to the category source systems. They all have in common that they provide information which is usually used of several systems.

HIS SOS

One of the first connected systems of the IdMS at the FAU was the student management, represented by HIS SOS. The provision of data basically consists of two database views:

 • idm student
 • idm stg

idm student consists every needed information about the person of the student. Analogously idm stg  contains every needed information about the studies. Both views are connected with the matriculation number which is at the same point the primary key for the IdM connection.

To readout both of the views Novells Identity Manager is used. To keep the effort for the user of the student management at a minimum, no trigger tables are used. The benefit of a trigger table would be the direct provision of all the changes. The driver can only notice changes through reading this table. If yes, it can, depending on the kind of trigger table, directly readout all the information about the existing changes, or can only get the affected data sets of the views. Without trigger tables the driver has to find the changes by itself via a comparison with its intern data copy. If there are no changes there would be no entry in the trigger table and the work of the driver would be done; without trigger tables all the entries have to be proven every time. At the moment the driver needs not more than 5 minutes (incl. SELECT) for both views with 60000 entries each. With a Polling Interval of currently 5 minutes the driver is at its limit with the current configurations.
The synchronization of both views in direction IdMS will be discussed in details in the following chapters. Therefore basic knowledge of the driver concept of Novell’s Identity Management is required. Illustration 3.1. gives a schematic overview.

Illlustration 3.1: Driver Sos

View idm student

Table 3.3 shows the schema mapping and filter adjustments between the view idm student and the object class user (aka inetOrg Person) in the Meta-Directory (MD). In the ”Input Transformation Policy“ the attribute gender (geschl) is implemented according to the in table 3.1. shown illustration. As in table 3.3 shown the attribute schacGender of the SCHema for ACademia 2 (SCHAC) is used which inserts the ISO 5218 standard. Therefore the data are interpreted as shown in table 3.2.

The ”Matching Policy“ basically consists of two parts. Generally it is tried to find an already existing person entry in the MD and to connect it with the new SOS entry. If the matching is successfully, the following tries are omitted; so the order is important.
The first try could be called “Standard-Matching”. An already from SOS synchronized entry should be recovered with it. If the entry has been deleted in SOS and was again created with the same matriculation number or the driver lost its associations because of other reasons (DirXML-Association), it should be recovered. To guarantee this a matching base on the primary key of the connection, in this case the matriculation number, is made. Here it is searched for the matriculation number in the following attributes:
1. Attribut fauStudPK

2. Attribut fauStudPKOld

HIS SOS

The search in the attribute fauStudPK makes sure that there aren’t two entries with the same matriculation number existing or created in the MD. The search in the attribute fauStudPKOld is supposed to find already ex-matriculated student entries. If entries in the View idm student are deleted or ex-matriculated, the matriculation number is moved from the attribute fauStudPK to the attribute fauStudPKOld. So this case finds e.g. again matriculated students.
The second matching tries to assign the new student entry according to the attribute given name, last name, date of birth and place of birth, to any personal entry in the MD (usually from different source systems). Therefore the self created Framework Data Linkage (DaLi) is used. A complete description of DaLi would go beyond the scope of this article and that is the reason why only the embedding of the driver logic are explained. The fundamental operation mode of an earlier version of the framework can be found in the slides of a presentation by Krasimir Zhelev of the ZKI-Workinggroup for account services on 6th October 2009 3.
At the moment of the connection, the matching module should be embedded into the driver-landscape of Novell preferably without any dependency to an external service. For this reason DaLi was developed from a simple Jar-Archive which displays the best matches with the highest rates on possibility after the insertion of a person and possible matching candidates. The embedding of so called “Matching Processor” results from a namespace definition of the matching policy. As shown in illustration 3.2 the Java-class de.rrze.idmone.utils.matching. MatchingProcessor is bound to the namespace matchingProcessor.

Illustration 3.2: Matching Policy Namespace Definition

The actual use is shown in illustration 3.3. In the first line the matching processor is instanced. Therefore the attributes of the new personal entry are committed. In the easiest simplified version ever candidate has to be find in the MD and be delivered with the addNodeSet method. Therefore the method can be multiply selected to add further search results. The method request nodeSetMatching starts the analysis. In the current version DaLi compares over 10000 candidates within the tenth of a second. The limitation here lies definitely in the LDAP-search in the MD. After the analysis the possibility of a hit can be requested. The decision if a new entry should be combined with an already existing entry will stay within the driver.
If there is no existing personal entry matched, the “Creation Policy” follows. Here the testing of the obligatory attributes happen. If one of the attributes is missing the construction is denied. If every necessary attribute is available, a new person entry is defined  in the “Placement Policy” of the DN in the new person entry. This is build from the person container, a definite driver prefix and the matriculation number. Subsequently some attributes are set for a new person entry. Within these are e.g. the initial group membership and an initial password.

Illustration 3.3: Use of the Matching Processor

In the ”Command Policy“ further actions are performed as well with a new entry as with updates. So e.g. deletion in SOS are converted in the already mentioned movement of the matriculation number into the fauStudPKOld attribute. Furthermore a linkage between the possibly  already synchronized information according to the studies takes place, or the decision if an already existing contact address should be overwritten.

English Version
Dieser und die darauf folgenden Beiträge sollen einen Einblick in die Konzepte und Techniken des Identity Mangement Systems der FAU geben. Um die Serie etwas interessanter zu gestalten, werden die einzelnen Beiträge nicht streng logisch erscheinen. Die ersten zehn Beiträge behandeln also nicht das Konzept des Kerns. Vielmehr wird direkt im Anschluss an dieser zugegebenermaßen recht kurzen Übersicht die erste Anbindung eines Quellsystems beschrieben. Danach folgt ein Beitrag über die Anbindung eines Zielsystems, gefolgt von den grundlegenden Konzepten des Kerns, ein weiteres Quellsystem, …

Trotz dieser Sprünge wird versucht ohne große Wiederholungen und Vorwärtsverweise auszukommen. Mit etwas “Hintergrundwissen” sollten alle Beiträge eigenständig lesbar sein. Rückmeldungen sind natürlich willkommen!

Und jetzt viel Spaß beim Lesen.

Übersicht

IdM Lebenszyklus

Eine der Hauptgründe für die Einführung eines Identity Management Systems (IdMS) ist die zentrale Provisionierung und Deprovisionierung von Konten unterschiedlicher Dienste für Personen einer Organisation. Tritt eine neue Person in die Organisation ein, sollen möglichst sofort alle benötigten Ressourcen, welche zur Erledigung der zugedachten Aufgaben nötig sind, bereitstehen. Ändert sich das Aufgabengebiet einer Person, soll die Bereitstellung der Ressourcen angepasst werden. Verlässt eine Person schließlich die Organisation, sollen alle zugeteilten Ressourcen möglichst sofort entzogen werden.

Neben diesen grundlegenden Änderungen, besteht jedoch auch der Wunsch nach einer dauerhaften Aktualisierung von provisionierten Attributen. Das wohl bekannteste Beispiel eines solchen Attributs ist das Passwort. Aber auch Änderungen persönlicher Daten, wie z.B. Titel oder Kontaktadresse, sollen zeitnah in alle angeschlossenen Systeme, welche das entsprechende Attribut verwenden, aktualisiert werden.

Um diese Aufgaben erfüllen zu können, sind jedoch einige Vorarbeiten nötig. Die
genannten Vorgänge

• neue Person tritt in die Organisation ein
• Aufgabengebiet einer Person ändert sich
• Attribute einer Person ändern sich
• Person verlässt die Organisation

müssen erkannt und entsprechend verarbeitet werden. Besitzt die Organisation nur ein System zur Verwaltung von Angehörigen, kann diese Erkennung durch eine lesende Anbindung erledigt werden.

IdM Übersicht

Kommen zwei oder mehrere Systeme zum Einsatz, kommt eine weitere Aufgabe für das IdMS dazu: die Zusammenführung von Einträgen aus verschiedenen Systemen, welche zur gleichen realen Person gehören. Im vorhandenen Fall einer Universität, können als ein Beispiel die Verwaltungssysteme von Mitarbeitern und Studierenden herangezogen werden. Studierende können während ihres Studiums als wissenschaftliche Hilfskräfte tätig sein oder nach dem Abschluss, teilweise mit einer zeitlichen Lücke, als Mitarbeiter anfangen.

Dennoch beginnt alles mit dem Auslesen dieser Systeme, den sogenannten Quellsystemen. Die Konsolidierung der ausgelesenen Daten und darauf aufbauend die Berechnung von zuzuweisenden Dienstleistungen ist der nächste Schritt. Die so ermittelten Dienstleistungen müssen schließlich noch als Konten in die entsprechenden Systeme, den sogenannten Zielsystemen, provisioniert werden. Die Abbildung stellt die einzelnen Schritten schematisch dar.

Identity Management at the FAU – Overview (Part 1)

This and the following post should give an insight to the concept and techniques of the identity management system of the FAU .

To make this series more interesting, the indivudual posts will not appear strictly logical. The first ten posts will therefore not cover the core of the concept. Rather there will be following directly to this, admittedly quite short overview the first connection of a source system displayed. Afterwards a post about the connection of a target system will continue the series, followed by essential concept of the core, another source system, …

Despite of these jumps there should be no repetitions or any forward references. With a little “background knowledge” it should be possible to read the posts individually. Feedback is of course welcomed!

And now: have fun reading.

Overview

One of the main reasons for the introduction of an identity management system (IdMS) is the central provisioning and deprovisioning of accounts of different services for persons of an organisation. If a person joins the organisation, then there should be preferably every resources, which are needed for the intended task, directly available. If the field of action changes for a person, the provision of resources has to be adjusted. If a Person leaves the organisation, every assigned resource has to be taken back immediately.

Beside these fundamental changes, there is also the wish for a lasting update of provisioned attributes. The best known example of such an attribute is the password. But also changes of personal data, such as title or contact address, should be updated immediately in every connected system.

To complete these tasks however some preliminary work is needed. The said actions

• new person enters the organisation
• field of action of a person changes
• attribute of a person changes
• person leaves organisation

need to be identified and be used accordingly. If the organisation only has a system for the administration of members, this cognition can be completed with a reading connection.

If there are two or more systems used, there will be another task for IdMS: the connection of entries from different systems which belong zu the same real person. In the existing case of a university, the adminstration systems of employees and students can be used as an example. Students can be working as student assistants during their studies or after that, sometimes with a short time gap, start to work as an employee.

However, everything starts with the reading of these systems, the so called source system. The consolidation of the read data and on this data build calculations of referable services is the next step. Eventually the so determined services have to be provisioned into an according system. The illustration shows schematically the individual steps.

Achtung bei folgender Konstellation:

CREATE TABLE source
(
id serial NOT NULL,
"text" character varying(255),
CONSTRAINT id_pkeyPRIMARY KEY (id)
)

mit Regel:

CREATE RULE "insert_rule" AS
ON INSERT TO source DO  INSERT INTO dest (sourceid)
VALUES (NEW.id);

Serial und Bigserial sind in Postgres intern so konzipiert, dass der Wert für das Feld durch einen Aufruf von

nextval('source_id_seq')

erzeugt wird. Entgegen der Erwartung wird nach Ausführen der Regel aber nicht source.id in die Tabelle dest eingetragen, sondern source.id +1. Bug oder einfach so gewolltes Verhalten von Postgres? In der Postgres-Dokumentation zu Regeln findet sich zumindest ein entsprechender Kommentar:
“Beware that CREATE RULE insert_foo AS ON INSERT TO foos DO ALSO INSERT INTO bar (foo_id) VALUES (NEW.id); won’t work if foo.id is a serial (and foo_id REFERENCES foos ofcourse) because nextval() is evaluated twice.”

Sauberste Lösung: Hier keine Regel, sondern einen Trigger verwenden.

Postgres, Serials and Rules: Caution!

Caution with the following constellations:

CREATE TABLE source
(
id serial NOT NULL,
"text" character varying(255),
CONSTRAINT id_pkeyPRIMARY KEY (id)
)

with rule:

CREATE RULE "insert_rule" AS
ON INSERT TO source DO  INSERT INTO dest (sourceid)
VALUES (NEW.id);

Serial and Bigserial are so in Postgres internally designed that the data for the field can be generated with the request of

nextval('source_id_seq')

Against all expectations after carrying out the rule it is not source.id which is filled into the table dest but source.id +1. Bug or simply unwanted behavior of Postgres? In the Postgres-Documentation the rules can be found at least in on depending commentary:
“Beware that CREATE RULE insert_foo AS ON INSERT TO foos DO ALSO INSERT INTO bar (foo_id) VALUES (NEW.id); won’t work if foo.id is a serial (and foo_id REFERENCES foos ofcourse) because nextval() is evaluated twice.”

Cleanest solution: Do not use a rule here but a trigger.

English Version

Wochenlang Funkstille und dann solche News?
Nein, wir haben uns nicht vom RRZE abgespalten, noch wurden wir rausgeworfen.

Vielmehr sind auch wir von der Fassadenrenovierung betroffen. Um dem akuten Raummangel abzuhelfen, hat die FAU daher einige Container gekauft und im Süd-Gelände unweit des RRZE aufgestellt.

Zur Orientierung finden Sie eine Google Map unter http://g.co/maps/tdsu4

Wer uns mit Hilfe eines Navigationssystems finden will, steuere die “Haberstr. 5, 91058 Erlangen” an.
Unsere offizielle Adresse lautet aber weiterhin auf “Martensstr. 1, 91058 Erlangen”.

Und bezüglich der Funkstille gelobe ich spätestens als Neujahrs-Vorsatz auch Besserung.

We moved!

Weeks have gone without any sign of life and now news like this?
No, we did not split from the  RRZE and no, we haven’t been kicked out.

In fact we are also affected from the  facade renovation. To do something against the acute lack of space, the FAU bought a few containers which have been placed in the southern space, not far from the RRZE.

For orientation you can find a Google Map under  http://g.co/maps/tdsu4

If there is somebody who wants to find us with the help of a navigation system should head for “Haberstr. 5, 91058 Erlangen”.
Our official address remains “Martensstr. 1, 91058 Erlangen”.

And because of the silence: I promise improvement at least as a new year’s resolution .

Heute wurde die Version 2.0.2 der Promovierendenverwaltung online gestellt. Die Verbesserungen sind vor allem für die Mitarbeiter der Promotionsbüros relevant. So können E-Mails, mit denen Dokumente von den Promovierenden angefordert werden, nun individuell ergänzt werden.
Sichtbar für alle Nutzer der Registrierung ist die neu gestaltete kontextbezogene Hilfe.

DocDaten 2.0.2 online

Today the version 2.0.2 of the PhD-student management went online. The improvements are especially relevant for the PhD offices. E-mails, with which documents can be requested from the PhD-students can now be individually adjusted.

Visible for every user of the registration is the new designed context based help.

Bei der Deklaration einer Domänen-Klasse in Groovy wird auf die Bean-Notation für Variablen (Variable deklariert als private, zusätzlich Getter und Setter) verzichtet. Stattdessen werden sogenannte Properties definiert, die durch Groovy intern in Java-Beans umgewandelt werden.

class MyTest {
Long id
String val1, val2
}

Oftmals ist es nötig, die Liste der Properties auszulesen, etwa um ein Objekt in ein anderes zu mappen. Hierfür bietet Groovy die Methode getProperties():

def x = new MyTest()
x.properties.each { key, value ->
println "Property ${key}. ${value}"
}

Hier tauchen aber plötzlich Properties auf, die in MyType gar nicht definiert wurden, wie version, class, metaClass, constraints! Grails Magic, hier wurden durch das Grails-Framework weitere Properties hinzugefügt!

Wie kommt man nun an die Liste nur der selbst definierten Properties? Die Antwort liegt bei den persistentProperties, die in der Klasse liegen. Diese erreicht man über die DefaultGrailsDomainClass.

def persistentProps = new DefaultGrailsDomainClass(MyTest.class).persistentProperties
persistentProps.each {
println "${it.name}"
}

Et Voila: Die Liste der persistenten Properties, in aller Regel der selbstdefinierten.

Read Properties of a Grails Domain Class

With the declaration of a domain class in  Groovy it is done without a Bean-Notation for variables (variable declared as  private, furthermore Getter and Setter). Instead so called properties are defined which are changed internally into Java-Beans by Groovy

class MyTest {
Long id
String val1, val2
}

It is often necessary to read out the list, for example to map an object into another. Therefore Groovy offers the methode getProperties():

def x = new MyTest()
x.properties.each { key, value ->
println "Property ${key}. ${value}"
}

At this points properties suddenly appear which haven’t been defined like version, class, metaClass, constraints! Grails Magic, further properties have been added by the Grails-Framework!

So how do you get the list of the self defined properties only? The answer lies within the persistentProperties, which are within the class. You can reach it via DefaultGrailsDomainClass.

def persistentProps = new DefaultGrailsDomainClass(MyTest.class).persistentProperties
persistentProps.each {
println "${it.name}"
}

Et Voila: The list of persistent properties, usually the self defined.

Seit Donnerstag, 28.07.2011 um 16:00 Uhr ist die Version 2.0.1 der Promovierendenverwaltung online geschaltet. Die wesentlichen Neuerungen zur Version 2.0 sind:

• Betreuersuche auch per Nachname
  Einzutragende Betreuer konnten bisher nur über ihren Lehrstuhl bzw. Professur ausfindig gemacht werden. Dies führte bei Promotionsbetreuungsberechtigten, die direkt an einer Fakultät oder einem Department aufgehängt waren, dazu dass sie nicht über die GUI gefunden wurden und manuell einzutragen waren. Da die Promotionsbetreuungsberechtigten jetzt auch per Nachnamensuche gefunden werden, verringert sich die manuelle Nacharbeit.
• Vorhandene Betreuungsbestätigung bei aktiven Promovenden
  Die in Version 2.0 bereitgestellte Dokumentenprüfung hatte noch nicht realisiert, dass bei aktiven Promovenden das Dokument “Betreuungsbestätigung” immer vorhanden ist. Diese Voreinstellung ist jetzt implementiert. Durch den Freischalteprozess ist sichergestellt, dass die vom Betreuer unterschriebene Betreuungsbestätigung eingegangen ist.
• Möglichkeit, englische Dokumenten- und Schrittnamen zu verwenden
  Nun werden in der Oberfläche und den automatischen E-Mails bei englischen Texten auch englische Dokumenten- und Schrittbezeichnungen verwendet, sofern sie in der Datenbank hinterlegt sind.
• Verbesserte Telefonnummern der Betreuer
  Die vom Funktionenmanagement (FM) gelieferten Telefonnummern von Promotionsbetreuungsberechtigten waren teilweise durch Hash-Zeichen voneinander getrennt als eine lange Zeichenkette hinterlegt. Man einigte sich darauf, nur die erste erscheinende Telefonnummer zu übernehmen. Alte Telefonnummern in docDaten wurden dementsprechend per SQL-Skript verbessert und neu hinzukommende werden nur bis zum ersten Hash berücksichtigt.
• Verbesserte E-Mail-Texte
  Die automatisch versendeten E-Mails enthalten nun einen Hinweis auf die automatische Generierung.
• Gendergerechte Formulierungen
  Wo nötig wurde in der Oberfläche “Promotionsbetreuer/in” geschrieben.
• Promovenden-Daten-Exporte für Fachanwendungen
  Einige Fakultäten verwalten noch selbst Promovenden mittels Excel-Sheets. Es wurde die Möglichkeit geschaffen, einzelne Promovenden per Knopfdruck in die jeweiligen Excel-Formate zu extrahieren, damit sie nicht manuell in die Fachanwendung eingepflegt werden müssen.
• Lockerungen von Problemfällen
  Speziell der Problemfall “Studienfach ist ungleich Promotionsfach” führte zu sehr vielen vermeintlichen Problemfällen. Die Problemfälle der technischen Fakultät und der Wirtschaftswissenschaften wurden reduziert, indem Listen von erlaubten Fächerkombinationen vereinbart wurden. Aktuell (Stand 01.08.2011) sind nur noch 348 Problemfälle im System.

Release 2.0.1 of PhD-student management online

Since Thursday, 28.07.2011 at 4 pm the version 2.0.1 of the PhD-Student Management is online. The essential improvements ,compared to version 2.0, are:

• Search for advisers also per surname
  so far registered advisers could only be searched via their chair or their professorship. This caused that authorized PhD-advisers, who are directly connected to a faculty or a department, that they couldn’t be found via GUI and had to be added manually. As the authorized PhD-advisers can now be found via surname search, the manual rework can be reduced.
• Existing adviser affirmations at active PhD-students
  The in version 2.0 provided document test had not yet realized that the document “Adviser Affirmation”is always available for active PhD-students. These pre-adjustments is now implemented. With the activation process it is secured that the from the adviser signed advising affirmation has been handed in.
• Possibility to use English document- and step-descriptions
  Now in the surface and the automatically generated e-mails  with English texts, English document- and step-descriptions are used, insofar as they are saved in the database.
• Improved phone numbers of advisers
  The from the function management (FM) delivered phone numbers of PhD-student advisers have, partially separated with hash-signs, been deposited as a long chain of signs. It has been decided, that only the first appearing phone numbers are adopted. Old phone number in docDaten were therefore improved via SQL-script and new added numbers are now incorporated until the first hash appears.
• Improved e-mail
  The automatically sent e-mails now have a hint for the automatic generation.
• Gender conform formulations
  Where necessary it is now written “PhD-student adviser (female/male)”.
• PhD-students’ data export for application
  Some faculties still manage the PhD-students via Excel-sheets by themselves. There is now the possibility to extract PhD-students by pushing the button into the according Excel form, so that they don’t have to be inserted manually into the application.
• Loosening of problem cases
  Especially the problem case “Subject of studies is not the PhD subject” caused a lot of problem cases. The problem cases of the technical faculty and economic science have been reduced by creating lists with allowed subject combinations. At the moment (date 01.08.2011) there are only 348 problem cases in the system.