- trimmer-plugin: Leerzeichen zu Beginn und am Ende von Strings werden vor dem Speichern grundsätzlich entfernt

- Optimierungen Statistik

Was einst mit einer Idee, oder der vergeblichen Google-Suche nach dem passenden Icon, begann hat nun eine erstaunliche Marke erreicht: das offizielle RRZE-Icon-Set hat sein 400. Icon!

Aufgrund dieser großen Zahl an verschiedenen Icons und ihrer unterschiedlichen Verwendung wurde die Anzahl der Unterordner um zwei weitere erweitert. Mittlerweile sind die Icons also aufgeteilt in:

actions (Technische Aktionen, wie etwa: Sortieren, Zusammenfügen, das Verschicken von E-Mails, etc.)

 categories (Verschiedene Zugehörigkeiten wie: Arbeitnehmer, Admin, Benutzer, etc.)

 devices (Im allgemeinen IT-Hardware wie: Server, Datenbank, etc.)

 NEU: documents (Dokumente aller Art)

 emblems (Der größte Ordner umfasst alle Icons die ein Label oder ein konkretes Bild für einen abstrakten Begriff oder eine Funktion darstellen.)

 NEU: logos (Hier befinden sich alle Icons die in irgendeiner Weise ein Logo beinhalten.)

 mime-types (Hier lassen sich Icons für verschiedene Medientypen finden: Text, Video, Audio, etc.)

 status (Alle Icons, die einen Status darstellen: wartend, geprüft, gelöscht, etc.)

Das hauseigene Icon-Set stellt "kleine bunte Bildchen" zu verschiedenen IT-Themen, Aktionen, Funktionen und vielem mehr zur Verfügung.

Um einen einheitlichen Stil zu erhalten werden bei der Erstellung die Vorgaben des Tango-Icon-Themes eingehalten.

Verfügbar sind die Icons im Svg- (jeweils eine detailreiche und eine detailärmere Variante für die kleineren Skalierungen) und im Png-Format in den Größen 16x16, 22x22, 32x32, 48x48, 150x150 und 720x720 Pixel und können direkt auf der Seite heruntergeladen werden.

Falls allerdings das passende Icon immer noch fehlen sollte lässt sich dieses jederzeit noch der Sammlung hinzufügen. Hierfür einfach eine E-Mail an franziska.sponsel@fau.de schicken.

Wichtig bei der "Icon-Bestellung" ist allerdings, dass folgende Grundinformationen in der Mail stehen:

1. Welche Funktion etc. soll das Icon haben bzw. darstellen? Am besten auch für IT-Laien verständlich ;)

2. Gibt es schon konkrete Vorstellungen zum Aussehen (z.Bsp. ein Häuschen für "home") oder Farbwünsche?

Es sollte auch immer darauf geachtet werden, dass durch die kleine Skalierung ein Icon  aus nicht mehr als maximal 3 Bestandteilen bestehen kann.

Mittlerweile hat das RRZE-Icon-Set die Versionsnummer 2.3 erreicht und hat in einer Vielzahl von Projekten Anklang und Verwendung gefunden. Sowohl hier in Erlangen in RRZE eigenen Projekten, aber auch in anderen Arbeiten und Projekten in Deutschland, Indien bis hin zum sonnigen California, USA.

English Version

What once started off with an idea, or a fruitless Google search for the perfect Icon, has now reached an incredible benchmark: the official RRZE Icon Set got its 400. icon!

Because of this huge number of various icons and their different usage, the number of sub-folders has been expanded by two additional folders. Therefore the icons are now divided into:

actions (technical actions, e.g.: sort, merge, send e-mails, etc.)

categories (different entitlement or categories, e.g.: employee, admin, user, etc.)

devices (generally IT-hardware, e.g.: server, databases, etc.)

NEW: documents (documents of all kind)

emblems (the biggest folder concludes all icons which represent a label or a proper picture for an abstract term or function)

NEW: logos (here you can find icons which represent or conclude a logo)

mime-types (icons for different media types, e.g.: text, video, audio, etc.)

status (icons that represent a status, e.g.: awaiting, approved, deleted, etc.)

The RRZE own icon set offers "tiny colorful pictures" for various IT topics, actions, functions and many more.

To create a consistent style the icons are made according to the style sheet of the Tango Icon Theme.

The icons are available in svg- (a more and a less detailed version for smaller scaled icons) and in png-format in the sizes 16x16, 22x22, 32x32, 48x48, 150x150 and 720x720 pixels and can be downloaded directly from the   website .

If the perfect icon for a purpose is still missing it can easily be added to the set. Therefore don't hesitate to send a request e-mail to  franziska.sponsel@fau.de.

Important for the "Icon-Order" is that the following basic information is given and in the e-mail:

1. What function etc. should the icon represent? The best way is to explain it that even an ordinary person can understand it ;)

2. Are there already ideas on how the icon should look like (e.g. a small house for "home") or wishes for the icon's color?

You should also keep in mind that, due to the small size of an icon, it can only consist of a maximum of 3 properties.

By now the RRZE Icon Set has reached the version number 2.3 and is used in various projects. Here in Erlangen, but also from whole Germany, India to the sunny state of California, USA.

Das Ende der Wartungsarbeiten wird durch Entfernen der Hinweise auf den jeweiligen Portalen mitgeteilt.

Wir bitten um Ihr Verständnis.

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.

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.

[groovy]

/*

* 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}" }

}

}

}

[/groovy]

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

[bash]

grails clean -Dlive=ppsa-layout

grails run-app -Dlive=ppsa-layout

[/bash]

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.

[groovy]

/*

* 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}" }

}

}

}

[/groovy]

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

[bash]

grails clean -Dlive=ppsa-layout

grails run-app -Dlive=ppsa-layout

[/bash]

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:

[bash]

grails install-plugin release

[/bash]

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:

[groovy]

/*

* 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

[/groovy]

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.

[bash]

grails maven-deploy

grails maven-install

[/bash]

Download

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

[groovy]

grails.project.dependency.resolution = {

repositories {

mavenLocal()

mavenRepo name:"rrzeArchiva", root:"http://REPOSITORY:PORT/archiva/repository/internal"

}

plugins {

runtime ":ppsa-menu:latest.release"

}

}

[/groovy]

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.

[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"

}

}

[/groovy]

---- 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 ----

Managing Grails Plugins in own Maven Repository

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:

[bash]

grails install-plugin release

[/bash]

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:

[groovy]

/*

* 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

[/groovy]

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.

[bash]

grails maven-deploy

grails maven-install

[/bash]

Download

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

[groovy]

grails.project.dependency.resolution = {

repositories {

mavenLocal()

mavenRepo name:"rrzeArchiva", root:"http://REPOSITORY:PORT/archiva/repository/internal"

}

plugins {

runtime ":ppsa-menu:latest.release"

}

}

[/groovy]

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.

[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"

}

}

[/groovy]

---- 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 ----

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.

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

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.

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

IdM Life Cycle

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.

IdM Overview

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.

CREATE TABLE source

(

id serial NOT NULL,

"text" character varying(255),

CONSTRAINT id_pkeyPRIMARY KEY (id)

)

[/sql]

mit Regel:

[sql]

CREATE RULE "insert_rule" AS

ON INSERT TO source DO  INSERT INTO dest (sourceid)

VALUES (NEW.id);

[/sql]

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

[sql]

nextval('source_id_seq')

[/sql]

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:

[sql]

CREATE TABLE source

(

id serial NOT NULL,

"text" character varying(255),

CONSTRAINT id_pkeyPRIMARY KEY (id)

)

[/sql]

with rule:

[sql]

CREATE RULE "insert_rule" AS

ON INSERT TO source DO  INSERT INTO dest (sourceid)

VALUES (NEW.id);

[/sql]

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

[sql]

nextval('source_id_seq')

[/sql]

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.

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. 8-)

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 . 8-)