RRZE – Projekte & Prozesse (P&P)

Suche


10.09.2010

Registrierung für Studenten bei der VHB via SSO

Frank Tröger, 14:59 Uhr in IdM, Web-SSO; Tags: , , ,

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

Frank Tröger, 14:45 Uhr in IdM, Web-SSO; Tags: , , , , , ,

 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)
  • 29.10.2009

    14 Tage Single …

    Frank Tröger, 08:00 Uhr in Web-SSO; Tags: ,

    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.

    11.04.2007

    Shibboleth Testanwendungen

    Hendrik Eggers, 00:10 Uhr in Web-SSO; Tags: ,

    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.

    29.03.2007

    antville Shibbolethisierung

    Hendrik Eggers, 20:48 Uhr in Web-SSO; Tags: ,

    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?

    14.03.2007

    Mediawiki “shibbolethisiert”

    Hendrik Eggers, 23:56 Uhr in Web-SSO; Tags: ,

    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.

    27.02.2007

    Nachtrag: Service Provider

    Hendrik Eggers, 22:25 Uhr in Web-SSO; Tags: ,

    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.

    19.12.2006

    Shibboleth Identity Provider installiert

    Hendrik Eggers, 15:05 Uhr in Web-SSO; Tags: ,

    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.

    Nach oben