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.

Unter https://idmvm4.rrze.uni-erlangen.de/ wurden bisher in das Shibboleth System integrierte Anwendungen zusammengetragen, sowie die login-Seiten an das RRZE Layout angepasst.
Die Anwendungen können mit der angegebenen Testkennung getestet werden.

Die Einbindung der Blog-Software antville in das Shibboleth single sign on System wurde begonnen und eine einfache Authentifizierung funktioniert bereits.
Noch zu klärende Probleme sind:
* Wie verhindert man daß sich Dritte mit Namen registrieren, welche dann von Shibboleth verwendet werden könnten?
* Verwendung eines Web-Passwortes aus dem IDM, damit sich Nutzer auch ohne SSO anmelden können.
* Bleibt es bei der unix-Kennung für den Namen?

Mediawiki, die Software auf der Wikipedia basiert, und welche unter anderem im Intranet des RRZE verwendet wird, wurde erfolgreich “shibbolethisiert”, also an das Single Sign On Testsystem angebunden.
Das heißt, dass man, um Artikel unter seinem Namen zu bearbeiten, sich nicht mehr separat einloggen muss, und falls man noch kein Benutzerprofil erstellt hat, wird dieses mit den vom Identity Provider bereitgestellten Daten (Login, Vor- und Nachname, sowie Email-Adresse) automatisch angelegt.
Das nächste Ziel ist die Antville Blog-Software, auf der unter anderem dieses Blog aufbaut.

Seit etwa zwei Wochen haben wir einen exemplarischen Service Provider laufen, der in der TestFörderation mit unserem Identity Provider kommuniziert und bereits einen einfachen Zugriffsschutz auf Verzeichnisse anbieten kann (zB. für fauXpas o.ä.).
Seit etwa einer Woche schraubt Steffen Büttner an der Einbindung des RRZE News Systems.
Mit Wolfgang Wiese vom Webteam habe ich Kontakt aufgenommen und ihn zur Einbindung des RRZE-Wikis befragt. Er sieht noch grundlegende Probleme, wie etwa zusätzlicher Supportaufwand, Irritation der Benutzer durch Phishing Filter in neueren Browsern, etc. Abgesehen davon möchte er warten, bis das wiki auf leistungsfähigere Server umgezogen ist, die jetzigen scheinen ihm nicht ausreichend zu sein.
Morgen früh gehts nach Berlin, ich bin mal gespannt was der Tag bringt.

Der Identity Provider (IP) ist installiert. Bis man ihn nutzen kann, muss er aber noch LDAP lernen, d.h. der OpenLDAP muss mit Infos gefüttert und der IP muss auf ihn konfiguriert werden.