… 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.
- Attribute zur Personalisierung von Anwendungen
- 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.
- Attribute for personalising of applications
- 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.