RRZE – Projekte & Prozesse (P&P)

Das Blog der RRZE Stabsstelle "Projekte & Prozesse"

Content

Beitritt eduGAIN-Interföderation

English version

Am Donnerstag, dem 29.08.2013, wurde der Identity Provider (IdP) der Universität Erlangen-Nürnberg in die Interföderation eduGAIN aufgenommen. Damit wurde das Angebot der nutzbaren Dienste über den Zentralen Anmeldedienst der Universität Erlangen-Nürnberg erneut erweitert. Neben den bereits angebundenen Diensten, wie z.B.

können nun auch Dienste anderer Föderationen genutzt werden. Ein Beispiel dafür ist Foodle der Feide Föderation (Norwegen), ein Werkzeug für einfache Umfragen oder Abstimmungen, sowie zum Planen von Treffen.

Weiterführende Links:

 

Joining the eduGAIN-Interfederation

On thursday 29.08.21013 the Identity Provider (IdP) of the University Erlangen-Nuremberg has joined the interfederation eduGAIN. So now the usable services via the Central Login Service of the University Erlangen-Nuremberg was expanded again . Beside the already tied in services, for example

services from other federations can be used. One example is Foodle of the Feide federation (Norway), a service for simple surveys or polls and for scheduling meetings.

Further links:

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.

Beitritt DFN-AAI-Föderation

 English version

Am Mittwoch, dem 11.08.2010, wurde der Identity Provider (IdP) der Universität Erlangen-Nürnberg in die DFN-AAI-Föderation aufgenommen. Damit ist der Zentraler Anmeldedienst der Universität Erlangen-Nürnberg nicht mehr nur auf lokal angebotene Dienste beschränkt. Neben den bereits angebundenen Diensten, wie z.B.

können nun auch Dienste anderer Einrichtungen genutzt werden. Ein Beispiel dafür ist Gigamove der RWTH Aachen, ein webbasierter Dienst um größere Dateien im Internet auszutauschen.

Weiterführende Links:

Joining the DFN-AAI-Federation

On  wednesday 11.08.21010 the Identity Provider (IdP) of the University Erlangen-Nuremberg has joined the  DFN-AAI-Federation. So now the Central Login Service of the University Erlangen-Nuremberg is no longer restricted on local services only. Beside the already tied in services, for example

  • Uniportal Erlangen-Nürnberg
  • Mein Campus
  • StudOn

    • services from other institutions can be used. One example is  Gigamove of the RWTH Aachen, a webbased service to change larger datas in the Internet.

    Further links:

  • List of Service-Provider in the DFN-AAI-Federation
  • List of Identity Provider in the DFN-AAI-Federation (a.o. University Erlangen-Nuremberg)

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

    Frank Tröger

    Foto Frank Tröger

    I studied Computer Science at the Friedrich-Alexander University Erlangen-Nuremberg. During my studies I started working as an assistant scientist for the user management group at the Regional Computing Center Erlangen (RRZE). After finishing my Master’s degree in Computer Science (Diplom-Informatiker), I was made a member of the mail group and used directory services for university-wide mail routing. Since November 2006 I have been a member of the Identity Management project. I am intensely engaged in building up the meta directory including the connections to all source and target systems.

    Since February 2007, I have been an external PhD candidate at the Dept. of Computer Science 6 (Data Management) with research interests in identity management, federated systems and especially access control.

    Contact me or share your Contact on Xing.

    Deutsche Version

    Ich habe an der Friedrich-Alexander-Universität Erlangen-Nürnberg Informatik studiert. Während meines Studiums fing ich an, als Wissenschaftliche Hilfskraft für die Benutzerverwaltung des Regionalen Rechenzentrums Erlangen zu arbeiten. Nachdem ich mein Studium (Diplom-Informatiker) abgeschlossen hatte, wurde ich Mitglied der Mail-Gruppe und benutzte Verzeichnisdienste für universitätsweites Mail-Routing. Seit November 2006 bin ich Mitglied des Identity Management Projekts. Ich bin eng in die Erstellung des Meta Directory sowie dessen Verbindungen mit Quell- und Zielsystemen eingebunden.

    Seit Februar 2007 bin ich externer Doktorand am Lehrstuhl für Informatik 6 (Datenmanagement) mit Forschungsinteresse in Identitätsmanagement, Föderierte Systeme und insbesondere Zugriffskontrolle.

    Kontaktieren Sie mich oder fügen Sie mich in Xing hinzu.

    Neue Benutzerverwaltung geht in die erste Produktivrunde

    Das am Regionalen RechenZentrum Erlangen angesiedelte Projekt IDMone hat den Aufbau einer zentralen Identitätsverwaltung zur automatisierten Vergabe von Benutzerkennungen für alle Angehörigen und Kunden der Friedrich-Alexander-Universität zum Ziel.

    Vier Mitarbeiter des Projekts IDMone arbeiten seit November 2006 am Aufbau einer zentralen Identity-Management-Infrastruktur die als Grundlage für eine effiziente Nutzung der universitären IT-Dienste dienen soll. Am Mittwoch, den 8.Oktober 2008, geht IDMone “hinter den Kulissen” mit einem ersten Teilergebnis in den Produktivbetrieb. Die Daten aller aktivierten, also frei geschalteten, Studierenden werden automatisch in das Webportal für Studierende und Prüfer ,mein campus, provisioniert. Damit müssen Benutzeraccounts nicht mehr manuell angelegt werden und Studierende können ihr Passwort jederzeit über die Funktion “Passwort vergessen” selbst zurücksetzen. Dies trägt zu einer wesentlichen Entlastung der Hotline und des Helpdesks von mein campus bei. Eine Weboberfläche, über die schließlich die zentrale Passwortverwaltung für verschiedene Dienste erfolgt, erhält IDMone in den kommenden Wochen.

    Das Projektleitdokument sowie das Fachkonzept mit grundsätzlichen Überlegungen zur technischen Realisierung sind unter http://www.rrze.uni-erlangen.de/forschung/laufende-projekte/idm.shtml veröffentlicht. Alle Arbeitsschritte werden darüber hinaus von IDMone unter http://www.blogs.uni-erlangen.de/IDM/ gebloggt.

    First round of productivity for new user management

    IDMone, is a project of the Regional Computing Centre Erlangen (RRZE). Its main task is the creation of a centralized identity management, assigning user IDs to all members and customers of the Friedrich-Alexander-University.

    Since November 2006, four members of project IDMone have been working on creating a central identity management infrastructure. This is going to be the basis for efficient use of university IT-services. On Wednesday, October 8th 2008, IDMone will start productivity “behind the scenes” with a first part of its results. The web portal mein campus will be automatically provisioned with data for all active students with activated user IDs. That means user accounts no longer need to be created manually, and students can reset their passwords with the “password change” functionality. This will relieve some of the workload on mein campus’s Hotline and Helpdesk. Within the next weeks, IDMone will get a web interface for central password management for the various services.

    You can find the a project summary document and the technical conceptualization with basic considerations concerning the realization under http://www.rrze.uni-erlangen.de/forschung/laufende-projekte/idm.shtml. All design steps will also be blogged by IDMone under http://www.blogs.uni-erlangen.de/IDM/.