RRZE – Projekte & Prozesse (P&P)

Das Blog der RRZE Stabsstelle "Projekte & Prozesse"

Content

Identity Management an der FAU – Hintergrund und aktueller Stand (Teil 3)

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:

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:

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.

 

Identity Management an der FAU – Studierendenverwaltung (Teil 2)

This gallery contains 7 images.

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 […]

Identity Management an der FAU – Übersicht (Teil 1)

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

Lebenszyklus

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

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

Lebenszyklus
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 Übersicht
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.

Registrierung für Studenten bei der VHB via SSO

English Version
Die Registrierung für Studenten bei der Virtuellen Hochschule Bayern (VHB) erfolgt seit Donnerstag, dem 09.09.2010, mittels WebSSO. Um die Dienste der VHB nutzen zu können, kommt bei der Registrierung und der Rückmeldung eine elektronische Authentifizierung bei der Heimatuniversität des Studierenden zum Einsatz. Bis gestern erfolgte dies über eine proprietäre Anwendung, welche unter https://www.freischaltung.uni-erlangen.de/cgi-bin/freischaltung-vhb.pl erreichbar ist bzw. war. Dieses, in die Jahre gekommene, Skript wurde nun durch eine sichere und standardisierte Anbindung abgelöst: WebSSO auf Basis von Shibboleth 2. Der Login sollte bereits von Diensten wie Mein Campus oder StudOn bekannt sein.

WebSSO Login

WebSSO Login

Voraussetzung dafür war u.a. der Beitritt des Zentralen Anmeldedienstes der Universität Erlangen-Nürnberg in die Föderation des Deutschen Forschungsnetzes (DFN), der  Authentifizierungs- und Autorisierungs-Infrastruktur im DFN (DFN-AAI). Siehe auch: Beitritt DFN-AAI-Föderation

Registration for Students at VHB via SSO

The registration for students at the VHB (Virtuelle Hochschule Bayern) happens since thursday, 09.09.2010, via WebSSO. To be able to use the services of the VHB an electronic authentification during the registration and confirmation is sent to the home university of the student. Untill yesterday this happened through a proprietary application which can or could be found at https://www.freischaltung.uni-erlangen.de/cgi-bin/freischaltung-vhb.pl.  This elderly script will now be exchanged with a secure and standardised connenction: WebSSO on Basis of  Shibboleth 2. The login should be familiar from services like Mein Campus and  StudOn.
Requirement for this has benn among others the joining of the  Central Login Service of the University of Erlangen-Nuremberg in the federation of the German Community for Searching and  Authentification- and Autorisation-Infrastructur in the DFN (DFN-AAI). See further:  Beitritt DFN-AAI-Föderation.

14 Tage Single …

English Version

… Sign-On


Am Mittwoch, dem 14.10.2009, ging der Zentrale Anmeldedienst der Universität Erlangen-Nürnberg online. Dabei handelt es sich um ein sog. Single Sign-On (kurz: SSO) für Web-Anwendungen.

Für eine Was-bringt-mir-das-Übersicht wird auf die dazugehörige Pressemeldung verwiesen. Für alle die einen Blick hinter die Kulissen werfen wollen, soll eine kleine Serie von Blogbeiträgen die technischen Grundlagen und die gewonne Erfahrung vermitteln.

Identity Management

Grundlage für ein SSO-System ist ein funktionierendes Identity Management (kurz: IdM). Ein IdM-System provisioniert alle aktuell gültigen Benutzerkonten in die Datenhaltung des SSO-Systems. Durch eine event-basierte Aktualisierung wird sichergestellt, dass immer der IST-Zustand im SSO-System vorliegt. Benutzer welche die Universität verlassen, sind am nächsten Tag nicht mehr im SSO-System zu finden.

Im vorliegenden Fall provisioniert IdM einen OpenLDAP-Server. Dabei werden alle Benutzerkonten in einen Container unter
ou=people,ou=websso,ou=sso,dc=rrze,dc=uni-erlangen,dc=de
geschrieben. Ein typischer Eintrag könnte wie folgt aussehen:

dn: uid=ddummy,ou=people,ou=websso,ou=sso,dc=rrze,dc=uni-erlangen,dc=de
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
objectClass: eduPerson
objectClass: dfnEduPerson
objectClass: fauSsoPerson
objectClass: schacPersonalCharacteristics
objectClass: schacLinkageIdentifiers
cn: Dolly Dummy
displayName: Dolly Dummy
eduPersonAffiliation: student
eduPersonAffiliation: employee
eduPersonOrgDN: dc=uni-erlangen,dc=de
eduPersonPrincipalName: ddummy@uni-erlangen.de
eduPersonScopedAffiliation: student@uni-erlangen.de
eduPersonScopedAffiliation: employee@uni-erlangen.de
givenName: Dolly
mail: Dolly.Dummy@rrze.uni-erlangen.de
o:: RnJpZWRyaWNoLUFsZXhhbmRlci1Vbml2ZXJzaXTDpHQgRXJsYW5nZW4tTsO8cm5iZXJn
schacGender: 2
schacPersonalUniqueCode: urn:mace:terena.org:schac:personalUniqueCode:de:uni-erlangen.de:Matrikelnummer:1234567
sn: Dummy
uid: ddummy
userPassword:: e1NTqEF9e3Ew3UdwY1crMFdPc3hwaGo3UVpNTtFIdnFJcoJ6ZGg=

Ein Eintrag enthält neben dem Benutzernamen (uid) und dem Passwort in SSHA-gehashter Form (userPassword) weitere Attribute zum Benutzerkonto.

Benutzername und Passwort dienen natürlich der Authentifizierung des Benutzers am SSO-Dienst. Die anderen Attribute können grob in zwei Kategorien unterteilt werden.

  1. Attribute zur Personalisierung von Anwendungen
  2. Attribute zur Autorisierung

Attribute der ersten Kategorie sollen es der Anwendung z.B. ermöglichen die korrekte Anrede (z.B. displayName oder schacGender) zu finden oder die Person hinter dem Benutzerkonto per E-Mail zu erreichen (mail).

Attribute der zweiten Kategorie dienen der Anwendung zum Setzen von unterschiedlichen Berechtigungen. Z.B. kann Anwendung A nur Studenten (eduPersonAffiliation: student) Zugriff auf einen bestimmten Bereich erlauben.

Im ersten Beitrag dieser Serie wurde die Anbindung des SSO-Systems an das vorliegende IdM beschrieben. Im nächsten Schritt wird der sog. Identity Provider, also die zentrale Komponente des SSO-Dienstes, betrachtet. Zur Überbrückung gibt es noch eine kleine Statistik:


Anmerkung:
Der Graph zeigt die Logins pro Stunde der einzelnen Service Providers übereinander angeordnet

14 Days Single…

… Sign-On


On wednesday 14.10.2009 the  Central Login Service of the Univesity of Erlangen-Nuremberg went online. This so called Single Sign-On (short: SSO) is used for web logins.

For a What-do-I-get-out-of-it-overview read the corresponding Press Report. For a peek behind the scenes a small series of blog entries should give the technical basic knowledge and the earned experience.

Identity Management

Basis for the SSO-System is a functioning Identity Management (short: IdM). An IdM-System comissions every recently valid user account in the data management of the SSO System. Through a event based update all the time the as-is state is secured. Users who leave the university are no longer to be found in the SSO System the next day.

In the following case IdM comissions an OpenLDAP-Server. Here every user account is written into one container under:
ou=people,ou=websso,ou=sso,dc=rrze,dc=uni-erlangen,dc=de

A typical entry could look like following:

dn: uid=ddummy,ou=people,ou=websso,ou=sso,dc=rrze,dc=uni-erlangen,dc=de
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
objectClass: eduPerson
objectClass: dfnEduPerson
objectClass: fauSsoPerson
objectClass: schacPersonalCharacteristics
objectClass: schacLinkageIdentifiers
cn: Dolly Dummy
displayName: Dolly Dummy
eduPersonAffiliation: student
eduPersonAffiliation: employee
eduPersonOrgDN: dc=uni-erlangen,dc=de
eduPersonPrincipalName: ddummy@uni-erlangen.de
eduPersonScopedAffiliation: student@uni-erlangen.de
eduPersonScopedAffiliation: employee@uni-erlangen.de
givenName: Dolly
mail: Dolly.Dummy@rrze.uni-erlangen.de
o:: RnJpZWRyaWNoLUFsZXhhbmRlci1Vbml2ZXJzaXTDpHQgRXJsYW5nZW4tTsO8cm5iZXJn
schacGender: 2
schacPersonalUniqueCode: urn:mace:terena.org:schac:personalUniqueCode:de:uni-erlangen.de:Matrikelnummer:1234567
sn: Dummy
uid: ddummy
userPassword:: e1NTqEF9e3Ew3UdwY1crMFdPc3hwaGo3UVpNTtFIdnFJcoJ6ZGg=

An entry is given an username (uid) and a password in SSHA-hashed form (userPassword) and further attributes of the user account.

Username and password ´are of course used to authentificate the user in the SSO Service. The other attributes can be differentiated into two categoies.

  1. Attribute for personalising of applications
  2. Attribute for authorisation

Attributes of the first categorie should make it for example possible for the application  to find the correct form of address  or to reach the person behind the user account via email (mail).

Attributes of the second categorie are used for the application to set different rights. For example the application A gives only students  (eduPersonAffiliation: student)the right to use a specific part of the application.

In the first article of this serial the connection with the SSO System is shown. In the next step the so called Identity Provider, the central component of the SSO service is described. To bridge these two, here is a small statistic:


Note:
The graph shows the logins per hour of each and every provider one upon the other.

Refactoring WAID

WAID is build-up of various, separately developed, components which are combined in a monolithic application. The application is structured and deployed as a single web application archive(war). The above mentioned components are of different granularity and perform tasks related to business logic, data fetching, presentation, transformation and so on. Refer to Fig.1 for a simplified diagram:

Architektur (Komponenten) von WAID

Splitting the application into small parts during the development cycle proved to be more than useful for code maintenance and rapid on-demand changes. Similar component-based approach is now proposed for the runtime structure of the application. The idea is to break up the application into smaller business-logic-based parts which can be easily exchanged during runtime without or with insignificant downtimes. Downtimes should occur only at redeployment of components which are directly related to user sessions. The exchange of all other underlying components should happen transparent to the users of the application. A simplified version of WAID’s current runtime architectural design can be seen on Fig.2. The application is started by deploying the web application archive into a JBoss AS. The JBoss server initializes a Spring (springframework) context, which is depicted by orange on Fig.2. The Spring framework is responsible for linking together the different runtime components. The most important component is idmone-core. This module is itself a Spring project which is developed separately and is responsible for the back-end functionality related to interacting with MetaDirectory. This project is only configured and used within the web application. Security is provided by the spring-security module, which is not shown on the Fig.2 but it closely couples with the Tapestry module, so these are represented by a single block. The Tapestry module is responsible for rendering the web page templates. Other required components are added within the Spring context to provide additional functionality. The pdf-generator module is shown on Fig.2 as an example of these type of components. The current implementation is focused on combining different projects into a single web application. The Spring framework provides the necessary flexibility and configuration options. The newly proposed component paradigm does the same but at runtime. Components are bound together when requested and not at initialization time. This allows for changing the underlying components implementation without re-deployment of the dependent applications. This would also allow for a better load distribution because different components can run on different machines. Generating pdf files, for example, can consume quite a lot of CPU cycles and memory. Distributing components to different machines can provide better performance but at the same time can make components reusable. Thus it would be possible to share a runtime component between applications – for example, pdf generation utilities can be used by several applications. An additional advantage is that in case of a bug fix only a single instance of a component is to be replaced. This would clearly prevent repackaging all applications that use it.

Struktur von WAID vor Refactoring

At the same time the proposed paradigm enables a major conceptual shift to Service Oriented Architecture(SOA). To put it short, the idea is instead of combining smaller projects into bigger applications, to start building up composite applications. These will consist of different runtime-bound services. The services will provide distributed business logic instead of packaged functionality. Once a certain degree of “service orientation” is achieved it would be possible to start using enterprise integration design patterns to accommodate better communication between the different systems involved. A proof of concept has been developed and a schematic view of the proposed solution is shown on Fig.3.

WAID Struktur nach Refactoring

At first glance there is not much of a difference. However, the yellow components are Enterprise Java Beans(EJBs) and run outside the web application. These can be looked up by the web application and used. EJBs have two type of interfaces local and remote. On the figure the local interface is depicted in pale blue and is the one connected with WAID. Technically this type of interface is used in the case when both modules run within the same application server, thus enabling data exchange with better performance. Although idmone-core exposes its functionality in the form of EJBs these are still initialized by a Spring context, depicted with green on Fig.3. Several developers share the opinion that Spring and JEE are excluding and competing standards but in our case these seem to form a symbiosis.

At the same time a proposal is evaluated to deploy the application as an exploded war file to accommodate on-the-fly changes. This proposal is done for the purpose of fixing typos, translation errors and similar. The same technique was tested, as a proof of concept, for implementing complex changes such as registering or unregistering existent Tapestry components on a page. So far , the concept seems useful but raises questions related to stability, reliability and can lead to inconsistencies if not thoroughly thought through. By inconsistencies are meant different versions of code on the productive system and the one tagged in the repository. In emergency cases there exists the possibility that updates are introduced in the productive system and these are later not propagated into the source code. In general managing a single web application archive seems to be a better way of handling tagging. Thus a system restore can be done by copying a single file instead of hundreds of small ones. This operation is also much more time efficient in the above mentioned case. At the time being, deploying WAID as an exploded archive is not considered harmful. However, unless the above mentioned issues are properly address and tested, changes of files under the exploded directory is granted only in exceptional situations.

Eine neue Struktur für WAID

WAID besteht aus verschiedenen, unabhängig entwickelten Komponenten, zusammengefügt zu einer monolithischen Anwendung. Diese Anwendung wird als einfaches web application archive (war) strukturiert und entwickelt. Die oben genannten Komponenten haben unterschiedliche Granularität und erfüllen Aufgaben im Zusammenhang mit Business Logic, Datensammlung, Präsentation, Transformation und so weiter. Abb.1 zeigt ein vereinfachtes Diagramm:

Architektur (Komponenten) von WAID

Die Aufteilung der Anwendung in kleinere Teile erwies sich als vorrteilhaft für Codepflege und schnell gewünschte Änderungen. Eine ähnliche komponentenbasierte Herangehensweise bietet sich nun für die Laufzeitstruktur der Anwendung an. Die Idee besteht darin, die Anwendung in kleinere, auf Business Logic basierende Einheiten aufzubrechen, die einen einfachen Austausch während der Laufzeit erlauben, entweder ganz ohne, oder zumindest mit vernachlässigbaren Ausfallzeiten. Ausfälle sollten nur bei einer Umstrukturierung von Komponenten stattfinden, die direkt mit den Nutzer-Arbeitssitzungen zu tun haben. Änderungen an allen anderen zugrundeliegenden Komponenten sollten so geschehen, dass sie für die Nutzer der Anwendung transparent sind. Eine vereinfachte Version der aktuellen WAID Laufzeitarchitektur ist in Abb.2 dargestellt. Die Anwendung wird gestarted, indem das Webanwendungsarchiv in eine JBoss AS übertragen wird. Der JBoss Server initialisiert einen Spring Kontext, der in Abb.2 orange dargestellt ist. Das Spring framework ist dafür verantwortlich, die verschiedenen Laufzeitkomponenten zu verbinden. Die wichtigste Komponente ist idmone-core. Das Modul ist selbst ein unabhängig entwickeltes Spring Projekt, verantwortlich für die Back-end Funktionalität im Zusammenhang mit der MetaDirectory-Interaktion. Das Projekt wird nur innerhalb der Webanwendung konfiguriert und genutzt. Sicherheit wird durch ein Spring Security Modul gewährleistet. Dieses Modul ist in Abb.2 nicht gezeigt, es ist jedoch eng an das Tapestry Modul gekoppelt, so dass beide durch einen einzelnen Block dargestellt werden. Das Tapestry Modul ist für das Rendern der Web page templates verantwortlich. Andere benötigte Module werden innerhalb des Spring Kontextes hinzugefügt, um zusätzliche Funktionalität bereitzustellen. Das pdf-Generator Modul in Abb.2 dient als Beispiel für diese Art Komponente. Der Fokus der momentanen Implementierung liegt darauf, die verschiedenen Projekte zu einer einzigen Webanwendung zusammenzubringen. Das Spring Framework bietet die dafür nötige Flexibilität und die entsprechenden Konfigurationsmöglichkeiten. Das kürzlich vorgeschlagene Komponentenmodell erfüllt die gleiche Aufgabe auf der Laufzeitebene. Komponenten werden erst auf Anfrage zusammengefasst, und nicht bereits bei der Initialisierung. Dies erlaubt es, die zugrundeliegenden Komponenten auszutauschen, ohne alle abhängigen Komponenten erneut übertragen zu müssen. Es macht zudem eine bessere Lastverteilung möglich, da die jeweiligen Komponenten auf unterschiedlichen Servern laufen können. PDF-Dateien zu generieren, beispielsweise, kann eine Menge CPU-Zeit und Arbeitsspeicher belegen. Durch die Verteilung der Komponenten auf verschiedene Rechner kann sowohl eine bessere Performance, als auch eine Wiederbenutzbarkeit der einzelnen Komponenten erreicht werden. Dadurch wäre es möglich, Laufzeitkomponenten mit verschiedenen Anwendungen zu nutzen – Dienstprogramme für die pdf-Generierung beispielsweise können von mehreren Anwendungen genutzt werden. Ein weiterer Vorteil liegt darin, das bei einem Bugfix nur eine einzige Instanz der Komponente ersetzt werden muss. Dadurch würde verhindert, alle Anwendungen neu packen zu müssen, die die Komponente nutzen.

Struktur von WAID vor Refactoring

Gleichzeitig ermöglicht das vorgeschlagene Modell eine wichtige Konzeptverschiebung hin zur dienstorientierten Architektur (Service Oriented Architecture, SOA). Kurz gesagt besteht die Idee darin, Kompositanwendungen zu bauen anstatt kleine Projekte zu großen Anwendungen zusammenzufassen. Diese Kompositanwendungen werden aus verschiedenen Laufzeitgebundenen Diensten bestehen. Die Dienste stellen eine dezentralisierte Business Logik zur Verfügung anstelle einer fertig gepackten Funktionalität. Sobald ein gewisser Grad der “Dienstorientierung” erreicht ist, würde es möglich werden, Unternehmensintegrations-Muster zu nutzen, um eine bessere Kommunikation zwischen den verschiedenen involvierten Systemen zu erreichen. Eine Machbarkeitsstudie ist bereits entwickelt worden und eine schematische Übersiccht der vorgeschlagenen Lösung ist in Abb.3 zu sehen.

WAID Struktur nach Refactoring

Auf den ersten Blick ist kein großer Unterschied zu sehen. Die gelben Komponenten sind jedoch Enterprise Java Beans (EJBs), die ausserhalb der Webanwendung laufen. Sie können von der Webanwendung aufgerufen und genutzt werden. EJBs haben zwei Arten von Schnittstellen, lokal oder remote. In der Darstellung ist die lokale Schnittstelle hellblau dargestellt, verbunden mit WAID. Technisch gesehen wird diese Art der Schnittstelle genutzt, wenn beide Module innerhalb der gleichen Anwendung laufen, um einen Datenaustausch mit besserer Performance zu erreichen. Obwohl idmone-core seine Funktionalität in Form der EJBs offenlegt, werden sie trotzdem durch einen Spring Kontext initialisiert, in Abb.3 dunkelgrün dargestellt. Mehrere Entwickler sind der Meinung, dass SPRING und JEE sich gegenseitig ausschließen und miteinander konkurrieren. In unserem Fall bilden sie jedoch anscheinend eine Symbiose.

Zur gleichen Zeit wird ein Vorschlag bewertet, die Anwendung als entpackte .war Datei einzusetzen, um “fliegende” Änderungen möglich zu machen. Ziel des Vorschlages ist ein vereinfachtes Verbessern von Schreibfehlern, Übersetzungsfehlern und Ähnlichem. Die Technik wurde als Machbarkeitsstudie bei der Umsetzung komplexer Änderungen erprobt, wie dem Registrieren und Entfernen existierender Tapestry Komponenten auf einer Seite. Bisher erscheint das Konzept brauchbar, es wirft jedoch Fragen in Bezug auf Stabilität und Zuverlässigkeit auf, und kann zu Inkonsistenzen führen, wenn es nicht gründlich genug durchdacht ist. Inkonsistenzen beziehen sich in diesem Zusammenhang auf verschiedene Code-Versionen im Produktivsystem und dem Repository. In Notfällen besteht die Möglichkeit, dass Updates im Produktivsystem eingefügt werden, dann aber nicht in den Code übernommen werden. Generell erscheint für die Handhabe des tagging eine einzelne Webanwendung besser geeignet, da eine Systemmwiederherstellung in diesem Fall durch das Kopieren einer einzelnen Datei einfacher ist als durch Hunderte kleiner Dateien. Die Operation verläuft ebenso deutlich effizienter im oben genannten Fall. Zum gegenwärtigen Zeitpunkt wird der Einsatz von WAID als entpacktes Archiv als nicht schädlich beurteilt. Solange jedoch die oben genannten Schwierigkeiten nicht ordentlich angegangen und getestet worden sind, sind Dateiänderungen im entpackten Verzeichnis nur in Ausnahmesituationen gestattet.

Neue Funktion im IdM Self-Service

English Version

Vergessenes Passwort kann ab sofort über E-Mail-Adresse zurückgesetzt werden

Eine neue Funktion erleichtert im IDM Self-Service (WAID) künftig das Vorgehen bei vergessenem Passwort. Zusätzlich zu den Sicherheitsfragen hat der Benutzer nun die Möglichkeit, eine beliebige E-Mail-Adresse zum Zurücksetzen des Passwortes zu hinterlegen. Zur Aktivierung dieser Funktion muss die hinterlegte E-Mail-Adresse einmalig bestätigt werden. Hierfür erhält der Benutzer an die eingetragene Adresse eine E-Mail mit einem Link, den er innerhalb von 24 Stunden anklicken muss.

Bei vergessenem Passwort kann der Nutzer dann eine E-Mail an die angegebene Adresse anfordern und das Passwort durch Anklicken des darin enthaltenen Links innerhalb von 24 Stunden neu setzen. Das Rücksetzen des Passwortes über die Sicherheitsfragen ist trotz der neuen Funktion nach wie vor möglich.

Leider erfolgt die Kommunikation zwischen E-Mail-Servern prinzipiell unverschlüsselt. Die neue Funktion ist daher vor diversen Attacken (sogenannte “man-in-the-middle-Attacken”) nicht geschützt und birgt die (allerdings geringe) Gefahr, von Dritten missbraucht zu werden.

Das am häufigsten zu erwartende Problem wird leider nicht zu umgehen sein: Eine nicht existente oder nicht zustellbare externe Mailbox.

New Function in IdM Self-Service

Forgotten password can now be put back via e-mail address.

A new function makes the process of a forgotten password easier in the IdM Self-Service (WAID). Additionally to the safety questions the user is able to deposit any e-mail address to put back the password. For the activation of this function the deposited e-mail address needs to be confirmed once. Therefore the user will receive an e-mail with a link to the deposited address which needs to be clicked within 24 hours.

In case of a forgotten password the user can request an e-mail to the deposited address and can, within 24 hours, set a new password by clicking the link in the e-mail. The password can still be reseted with the safety questions.

Unfortunately the communication between the e-mail servers happens uncoded. Therefore the new function is not protected from different attacks (so called “man-in-the-middle-attack”) and has also the risk to be abused by thirds.

The most likely problem that can not be avioded: a non existing or not reachable extern mail box.

WAID & CO – ZKI-AK Verzeichnisdienste in Aachen

Herr Dr. Rygus und Herr Tröger nahmen für das RRZE am Treffen des ZKI Arbeitskreises Verzeichnisdienste in Aachen teil.

Während Herr Rygus über Konzept, Aufbau und erste Erfahrungen des Erlanger Idm-Projekts IDMone berichtete, verschaffte Herr Tröger mit seinem Vortrag "Das Web-Frontend WAID und andere Entwicklungen im Rahmen des Erlanger IdM-Projekts (IDMone)" einen eher praktischen Einblick in die Thematik.

Sowohl am Donnerstag als auch am Freitag gab es interessante Vorträge, auf welche jedoch im Einzelnen hier nicht eingegangen werden soll. Neben zwei Anmerkungen bleibt nur noch ein Lob für den herzlichen Empfang und die gute Organisation an den Gastgeber auszusprechen.

Zum Thema Matching bzw. dessen Vorbereitung konnte Frau Dr. Warren der Universität Würzburg einen interessanten Link zu einem Sourceforge-Projekt beisteuern: DRRE (Data Rules and Routing Engine).
Leider fehlte bisher die Zeit, dieses Vorhaben genauer unter die Lupe zu nehmen. Nochmals vielen Dank an Frau Warren an dieser Stelle!

Hervorzuheben ist ebenfalls ein Gespräch mit Herrn Stefan Zech und Herrn Taito Radtke der FHTW Berlin. Deren Projekt JUDIT ((J)User Directory Information Tree) kann einige Gemeinsamkeiten zu IDMone aufweisen. Angefangen bei den Vorbereitungen (Schemaanalyse), über Aufbau des Meta-Directories (Affiliations) bis hin zur Technologiewahl des Web-Frontends (Tapestry). Nach dem aktuellen Kenntnisstand, könnten beide Projekte von einem größeren Informationsaustausch profitieren.

Identity Management schnell und intuitiv erreichbar

English Version
Der Identity (IdM) Self Service des RRZE für alle Beschäftigten und Studierenden der Friedrich-Alexander-Universität Erlangen-Nürnberg ist ab sofort unter https://www.idm.uni-erlangen.de/ zu erreichen.

Das erste Feedback der Benutzer zielte auf die Länge der URL des Identity Management (IdM) Self Service ab: ?Zu lang und der zentralen Rolle dieses Dienstes nicht gerecht werdend?, war der Tenor. Aus diesem Grund wurde die neue URL https://www.idm.uni-erlangen.de/ etabliert. Hierunter ist der Dienst nun dauerhaft zu erreichen. Bisherige Links werden weitergeleitet und behalten vorerst ihre Gültigkeit. Dennoch bitten wir alle Benutzer, ihre Lesezeichen bzw. Favoriten entsprechend zu aktualisieren.

Im Zuge der neuen Namensgebung wurde auch die Hardware für das Identity Management (IdM) erweitert. Der Dienst sollte nun also noch schneller als bisher reagieren.

Für Fragen rund um das Identity Management werfen Sie doch mal einen Blick in die Hilfe, die FAQ oder wenden sich direkt per E-Mail an idm@rrze.uni-erlangen.de.

Identity Management quick and intuitively reachable

The identity (IdM) self service of the RRZE for all the employees and students at the Friedrich-Alexander-University Erlangen-Nuremberg is now reachable at  https://www.idm.uni-erlangen.de/.

The first users’ feedback targeted the length of the URL of the identity management (IdM) self service: ?Too long and does not measure up with the service’s central role? was the main tenor. Because of this reason the new URL https://www.idm.uni-erlangen.de/ was established. Here the service is steadily reachable here. Links up to now will be forwarded and will keep their availability for now. Nevertheless we ask the users to update their bookmarks, or favourites accordingly.

In the course of a new naming the hardware for the identity management (IdM) has been extended. The service should now react even faster than before.

For questions around the identity management please look up the Help, the FAQ or send and e-mail directly to idm@rrze.uni-erlangen.de.

IDMone Release 2.1 online

English Version
Das aktuelle Release bietet vor allem Verbesserungen in der Web Oberfläche IdM Self Service. So wurde unter anderem eine Feedbackseite eingerichtet. Außerdem stehen nun alle Informationen auch in englischer Sprache zur Verfügung. Desweiteren wurden die Administratoren-Funktionen erweitert.

Feedbackseite

Wie bei jedem Produkt kann es auch beim IdM Self Service dazu kommen, dass der Nutzer Hilfe benötigt. Dafür wurde jetzt im technischen Menü (auf der Seite oben rechts) der Punkt “Feedback” eingerichtet. Klickt der Nutzer darauf, erscheint eine Formularseite, mit der er eine Anfrage an das RRZE senden kann. Die Anfrage wird zum HelpDesk-System des RRZE weitergeleitet und dort zeitnah durch qualifizierte Fachleute im RRZE bearbeitet. Das IDMone-Team hofft gleichzeitig, dadurch direkter mit den Kunden der IdM Self-Service Oberfläche in Kontakt zu kommen, und lädt alle Nutzer ein, diese Funktion auch für Kritik, Anregungen oder Lob zu nutzen.

Affiliation- bzw. Rollen-Anzeige

Den IdM Self Service nutzen alle Angehörigen der Friedrich-Alexander Universität, unabhängig davon, welche Rolle sie an der Hochschule innehaben: Studierende, Beschäftigte, Dozenten, Prüfer, Gastwissenschaftler und Andere. Im Englischen hat sich dafür der Begriff “Affiliation” etabliert. Da sich im deutschsprachigen Raum noch keine einheitliche Bezeichnung durchgesetzt hat (und für den englischen Begriff noch keine passende Übersetzung gefunden wurde), spricht das RRZE in diesem Zusammenhang auch von Rollen. Im Grunde geht es darum, dass dem Nutzer alle Rollen, die er an der Universität innehat, samt der Informationen, die daraus resultierend über ihn gespeichert werden, im IdM Self Service unter dem Menüpunkt “Benutzerdaten” angezeigt werden.

Ihre Meinung zählt

Wie würden Sie den Begriff “Affiliation” übersetzen?
Welche Bezeichnung würden Sie vorziehen?
Bitte stimmen Sie hier ab:

Übersetzung der Briefe

Good News for our English speaking users: All letters (pdf files) offered within the IdM Self Service are now translated to English. The IdM Self Service should offer you now a 100% English experience.

Any errors in translation found? Do not hesitate to write us an Email to idm@rrze.uni-erlangen.de or use the feedback form (link left of the language flag).

Administratoren-Funktionen

Was nur für einige der IdM Kunden, nämlich die Administratoren mit den entsprechenden Berechtigungen, sichtbar ist: Der IdM Self Service verfügt nun auch über administrative Funktionen.

Affiliations Anzeige auch für Adminstratoren

Nicht nur die Kunden bekommen Ihre Affiliations angezeigt. Auch die Administratoren können nun die Art der Zugehörigkeit einer Person zur Universität schnell und einfach nachvollziehen. Das IdM-Team hat damit einen wesentlichen Wunsch, der in den letzten Wochen insbesondere von den Beschäftigten des RRZE geäußert wurde, realisiert.

Dienstleistungs-Anzeige auch für Adminstratoren

Bisher war für Administratoren nicht einsehbar, welche RRZE-Dienstleistungen für den einzelnen Kunden erbracht werden. Auch dies ist nun integriert. Damit macht das IdM Self Service einen weiteren großen Schritt in Richtung zentraler Anlaufstelle für die Personen- und Dienstleistungsverwaltung.

Studentische Aktivierungs- (s-) Kennungen über Quick-Search für Administratoren suchbar

Mit der Einführung des Identity Managements wurde die Benutzerkennung auf eine syntaxfreie Erstellungsregel umgestellt. Dies trifft vor allem Studierende, deren bisherige Kennung mit einem “s” begann (daher der Name „s-Kennungen“). Diese bekommen mit der Aktivierung im IdM Self Service eine neue, semantikfreie Kennung zugewiesen. Ungünstig ist es, wenn diese Kennung vergessen wird und nur ein alter Studentenausweis die Aktivierungskennung angibt.
Administratoren können nun über das Schnell-Such-Feld (Quick-Search) nach dieser ursprünglichen Kennung suchen. Diese wird auch in den Benutzerdaten bei der Rolle Student als “Benutzerkennung (orig.):” ausgegeben.

noch Fragen?

Sie haben noch Fragen zum IdM oder dem IdM Self Service?
Dann sehen Sie doch unsere FAQs an – diese werden laufend aktualisiert und ergänzt.
Sind noch Fragen offen? Dann schreiben Sie uns eine E-Mail an idm@rrze.uni-erlangen.de.

IDMone Release 2.1 online

The current release especially offers improvements in the web interface IdM Self Service. Among others a feedback page has been set up. Furthermore all the information are now available in English. Also the admin functions have improved.

Feedback Page

As for every project it could happen that the user of the IdM self service needs some help. Therefore the new button “Feedback” was added to the technical menu (on the right top of the page).  If the user clicks this button a form page will appear with which the user can send a request to the RRZE. The request will be forwarded to the  HelpDesk-System des RRZE and worked on by skilled professionals at the RRZE. At the same time the IDMone team hopes to be closer in contact to the customers of the IdM self service interface, and therfore invites the users to use this function for critique, suggestions or reasurment.

Affiliation and Role Display

The IdM self servie uses every member of the Friedrich-Alexander University, independently from the role they have within the university: student, employee, lecturer, examiner, visiting professor or others. The English term “affiliation” has established for this case. Because there hasn’t been a consistent term in the German speaking area (and the English term did not have a fitting translation) the RRZE speaks in this case also about roles. Basically it is about that under the menu point “Uderdata” the user can see every roles which he/she has within the university, including the resulting information, which are safed about the user.

Your opinion counts

How would you translate the term “affiliation”?
Which term would you prefer?
Please vote here:

Translation of letters

Good News for our English speaking users: All letters (pdf files) offered within the IdM Self Service are now translated to English. The IdM Self Service should offer you now a 100% English experience.

Any errors in translation found? Do not hesitate to write us an Email to idm@rrze.uni-erlangen.de or use the feedback form (link left of the language flag).

Admin functions

What is only visible for a few IdM customers, such as the admins with the according rights: the IdM self service now contains administrative functions.

Affiliation display also for admins

Not only customers can view their affiliations. Also admins can quick and easily follow the form of the affiliation of a person at the university. The IdM team therefore realised the essential desire which was especially by employees of the RRZE required.

Service display also for admins

Until now the admins could not see which RRZE services are provided for each customer. This is now integrated, too. Therefore the IdM self service takes another big step towards central contact point for personnel and service management.

Student activation identification searchable for admins via Quick-Search

With the introduction of the identity management the user identification was converted into a syntax free creation rule. This applies especially for students whose identification started with a “s” (so called “s identifications”). They will receive with the activiation at the IdM Self Service a new and semantic free identification. It is inconvenient if this identification is forgotten and only an old student id can be used for the activation identification.
Admins can now search for the original identification via the quick search field (Quick-Search). It will also display in the user data under the role “User identification (orig.)”.

still questions?

You still have questions about IdM or the IdM self service?
Then have a look on our FAQs  – they are continously updated and supplemented.
Still questions? Then write an e-mail to idm@rrze.uni-erlangen.de.