Single Sign-On an der Uni Münster

• Rainer Perske

• Westfälische Wilhelms-Universität
  Zentrum für Informationsverarbeitung
  Röntgenstraße 7-13
  48149 Münster

• perske@uni-muenster.de
  +49 251 83 31582 (fon)
  +49 251 83 31555 (fax)

Inhalt

• Warum nicht einfach Shibboleth? (1 + 2)

• Alternativen (1 + 2)

• Situation

• Unser Single Sign-On

• Login-Vorgang (1 + 2)

• Hinweise für Infoanbieter

• Erweiterung: Zugangskontrolle per Zertifikat

• Erweiterung: Zugangskontrolle per Shibboleth

• Was noch?

• Fazit

• Apache-Patches (1 – 3)

Warum nicht einfach Shibboleth? (1)

• Situation 2010: MIRO hatte darauf gesetzt, DFN-AAI tut es weiterhin

  • MIRO = Münster Information System for Research and Organization (DFG-Projekt 5 Jahre)

• Intensive Praxistests zeigten Probleme:

  • Editierte Wiki-Dateien oder E-Mail-Texte weg – völlig inakzeptabel

  • Keine Datenübergabe zwischen Anwendungen (MeinZIV, ZIVprint, ...) möglich – naja

  • Nur Shibboleth-Gruppen nutzbar, keine eigenen – häufig inakzeptabel

  • Bindung an physischen Server erschwert Lastverteilung und Ausfallsicherheit – naja

  • Kein Single Sign-Off – nice to have

• Ursachen:

  • Redirect-Ketten bei SP-Erstkontakt oder Ticket-Refresh wandeln POST in GET

  • Keine Zwischenspeicherung von POST-Request-Daten

  • Keine saubere Trennung Authentifizierung/Autorisierung

Warum nicht einfach Shibboleth? (2)

• Für Sitzungsverwaltung in Clustern unbrauchbar: Sogar die Entwickler schreiben¹: “Avoid the SP's session caching layer and quickly establish a cluster-safe session using some other application-specific technology.”

• Vorgenannte Probleme prinzipiell lösbar

  • komplexe Erweiterung der Apache- (oder IIS-) Shibboleth-Module nötig

  • keinerlei Anzeichen, dass so etwas bald realisiert wird

  • eigene Realisierung würde lange Lernphase erfordern

• Rückblick aus 2012

  • POST-Daten-Problem ab SP 2.2 für application/x-www-form-urlencoded gelöst

  • aber nur mit Größenlimit und nicht für das bei uns wichtigere multipart/form-data

  • alle anderen Probleme unverändert

  • Umstieg auf Apache 2.4 nicht vor SP 2.5.1

¹ https://wiki.shibboleth.net/confluence/display/SHIB/CPPSPLoadBalanced

Alternativen (1)

• CAS – gleiche Probleme wie Shibboleth

• Etliche weitere – aus verschiedenen Gründen nicht oder nicht schnell realisierbar

• Nutzerzertifikate (im Browser oder besser auf Smartcard) – zu aufwändig für die Masse

• Pseudo-Single-Signon

  • Verschlüsselte Tickets („PasCodes“) mit Passwort und Ablaufdatum in Hidden-Input-Feldern

  • (Paarweise) Shared Secret zwischen Anwendungen

  • bereits realisiert: MeinZIV↔perMail, MeinZIV↔ZIVprint u. a, (anders) MeinZIV↔HIS-LSF

  • erfordert Klartext-Passwort beim ersten Login und Anpassung jeder einzelnen Anwendung

Alternativen (2)

• Portalproxy (komplex oder simpel)

  • im Webserverpark einfachst realisierbar und ganz schnell ausgetestet

    • Zentrale Nutzerverwaltung bereits vorhanden

    • Reverse-Proxy-Struktur mit Einbindung anderer Webserver bereits vorhanden

  • offen für verschiedene Authentifizierungsverfahren (s. u.)

    • Basic-Authentifizierung kein Sicherheitsproblem

    • aber Basic- und Digest-Authentifizierung nicht föderationsfähig

  • verlangt (fast) keine Änderungen an vorhandenen Anwendungen

    • sofern diese nicht auf eigener Passwortkontrolle bestehen

  Situation

  • Studienassistenzportal-Gruppe forderte schnelle Entscheidung

  • Wegen Shibboleth-Problemen in meinen Augen einziger Kandidat: Portalproxy

  • Ein gebranntes Kind scheut das Feuer:

    • Ich wollte drohenden „politischen“ Design-Entscheidungen zuvorkommen

    • Daher habe ich Fakten geschaffen und lasse diese für sich sprechen

  Unser Single Sign-On

  • KISS-Prinzip – Keep It Simple and Stupid (also nicht Websphere)

  • Browser denkt: Alles ist ein einziger Webspace eines einzigen Anbieters

  • Passwort (Cookie, Zertifikat, ...) wird nur vom Browser aufbewahrt

    • und bei jedem einzelnen Seitenabruf automatisch benutzt

  • Ausloggen = Schließen des Browsers

    • oder „Persönliche Daten / Neueste Chronik löschen“

    • oder (Very Dirty Trick) Anmeldung unter anderer Kennung erzwingen

  • Alles in einem einzigen URL-Baum: https://sso.uni-muenster.de

    • Inhalte identisch zu http(s)://www.uni-muenster.de

    • Nur Zugriffsrechte abweichend (ggf. http://www gesperrt, https://sso erlaubt)

  • Nur kleinste Änderungen im Webserverpark nötig

    • Tatsächlicher Zeitbedarf bis produktionsreif: Wenige Stunden!

  Login-Vorgang (1)

  • Frontend-Server erledigen Authentifizierung (Identitätskontrolle)

  • Frontend-Server wählt anhand URL-Pfad zuständigen Backend-Server

    • Beliebige Backend-Server weltweit einbindbar, nicht nur Webserverpark

  • Frontend-Server übergibt an Backend-Server:

    • Dummy-Nutzerkennung -+@TRUST@+- und Dummy-Passwort (mit Backend-Betreiber vereinbart)

    • X-Trusted-Remote-User: Echte Identität (i. d. R. = Nutzerkennung)

    • X-Trusted-Remote-Attr: URL-Pfad-abhängig weitere Attribute (Realname, Matrikelnummer o. ä.)

      • Eigener Frontend-Apache-Patch holt Angaben aus lokaler DB-Datei

      • DB-Dateien (pro URL-Pfad) zusammen mit /www/data/groups stündlich aktualisiert

  • Backend-Server prüft IP-Adresse und/oder Dummy-Passwort

    • Andere Passwörter braucht der Backend-Server nicht zu kennen

  Login-Vorgang (2)

  • Backend-Server im Webserverpark

    • Eigener Backend-Apache-Patch ersetzt -+@TRUST@+- durch Inhalt von X-Trusted-Remote-User

    • Backend-Server erledigt Autorisierung (Gruppenkontrolle, Zugangsgewährung) wie üblich

    • Aufgerufene Anwendungen bekommen i. d. R. nicht einmal mit, dass Single-Sign-On genutzt

  • Andere Backend-Server (inkl. perMail)

    • Entweder genauso, erfordert den Apache-Patch

    • Oder Modifikation der Anwendung, damit diese die Ersetzung vornimmt

  Hinweise für Infoanbieter

  • Alle Links im SSO ohne Hostangabe schreiben: <a href="/MeinZIV/">...</a>

  • Drei Dateien für Konfiguration: .htaccess, .htsslaccess, .htssoaccess

  • .htaccess und .htsslaccess:
    RedirectPermanent / https://sso.uni-muenster.de/

  • .htssoaccess:
    AuthName "Nur fuer ..."       (sichtbar nur wenn Autorisierung verweigert)
    AuthType Basic
    AuthBasicProvider dbm
    AuthDBMUserFile /www/data/usersso       (enthält nur -+@TRUST@+-)
    AuthDBMGroupFile /www/data/groups
    Require group ...

  • Logout-Link/Button (s. u.): <a href="/SingleSignOff">Logout</a>

  Erweiterung: Zugangskontrolle per Zertifikat

  • https://xsso.uni-muenster.de

  • X.509-Client-Zertifikat wird vom Frontend kontrolliert

    • aber weiter Basic-Authentifizierung zwischen Frontend und Backend

  • nur Zertifikate aus der DFN-Global-Hierarchie

  • nur Zertifikate mit Microsoft-UPN oder E-Mail-Adresse der Form
    username@uni-muenster.de oder username@wwu.de (keine Aliasnamen)

  • Eigener Frontend-Apache-Patch extrahiert Nutzerkennung (Erweiterung auf fremde Identitäten möglich)

  • Zertifikatspeicher (Browser, eToken, Smartcard) irrelevant

  • Falls abziehbarer Zertifikatspeicher (eToken, Smartcard): Single Sign-Off durch Abziehen

  • Neue Kopfzeile zur Übermittlung des Authentifizierungsverfahrens:

    • X-Trusted-Remote-Auth: PASS: (oder) X509:DN-des-Zertifikatausstellers

    • Kann per SetEnvIf ... und Deny From env=... zur Zugangsbeschränkung dienen.

  Erweiterung: Zugangskontrolle per Shibboleth

  • https://ssso.uni-muenster.de

  • Zugangskontrolle mit Shibboleth – inklusive fast aller Probleme

  • Aber Authentifizierung (auf Frontend) und Autorisierung (auf Backend) jetzt unabhängig

  • Ursprünglich nur IdP aus MIRO-Projekt, seit August 2012 DFN-AAI

  • eduPersonPrincipalName als Nutzerkennung

  • Eigener Frontend-Apache-Patch schreibt Scoped Affiliations in Pseudo-Gruppen um

    • X-Trusted-Remote-Role: @staff@uni-koeln.de,@member@uni-muenster.de

  • Eigener Backend-Apache-Patch erlaubt Require group @staff@uni-koeln.de

  • X-Trusted-Remote-Auth: SHIB:

  • An alle Identity Provider in der DFN-AAI:

    • Bitte eduPersonPrincipalName und eduPersonScopedAffiliation für uns freischalten.

  Was noch?

  • X-Trusted-Remote-Name: Voller-Name-als-HTML (von Portalgruppe erbeten)

  • Automatischer Redirect sso → xsso oder sso → ssso per Cookie setzbar

  • Äußerst rudimentäres Single Sign-Off per href="/SingleSignOff":

    • Infotext abhängig von Authentifizierungsmethode

  • Weitere Zugangskontrollmechanismen unter weiteren Adressen jederzeit implementierbar

    • vielleicht bald der neue Personalausweis?

  • Ablösung Basic-Auth durch Digest-Auth steht bevor

    • Außer lynx und PHP-fopen("https://user:pass@host.do.main/...") können das wohl alle (inkl. PHP-Curl)

  Fazit

  • Unser Single Sign-On

    • vermeidet die meisten Shibboleth-Probleme,

    • tut bislang was es soll,

    • wird von unseren Infoanbietern optimal angenommen,

    • ist flexibel bezüglich weiterer Entwicklungen und Anforderungen

    • und bindet (mit weniger Problemen als vorher) trotzdem die ganze DFN-AAI ein.

  • Ein voller Erfolg

  Diff für mod_auth_basic.c auf den Backend-Servern

  Ersetzen von -+@TRUST@+- durch die angemeldete Nutzerkennung

  
  --- mod_auth_basic.c    2011-11-23 14:21:04.000000000 +0100
  +++ mod_auth_basic.c.new        2012-07-31 13:19:06.000000000 +0200
  @@ -281,6 +281,15 @@
           return return_code;
                }
                 
  +/* ##++## inserted for webserverpark backend */
  +    if (r->user && !strcmp(r->user, "-+@TRUST@+-") && r->connection->remote_ip && !strncmp(r->connection->remote_ip, "128.176.5.", 10)) {
  +        const char *s = apr_table_get(r->headers_in, "X-Trusted-Remote-User");
  +        if (s) {
  +            r->user = apr_pstrdup(r->pool, s);
  +            apr_table_setn(r->notes, "X-Using-Trusted-Remote-User", "1");
  +        }
  +    }
  +/* ##++## end of insertion */
       return OK;
        }
         
  

  Diff für mod_authz_dbm.c auf den Backend-Servern

  Einbinden der Scoped Affiliations als Nutzergruppen (nur Shibboleth)

  
  --- mod_authz_dbm.c     2011-11-23 14:21:16.000000000 +0100
  +++ mod_authz_dbm.c.new 2012-08-01 15:07:49.000000000 +0200
  @@ -130,6 +130,25 @@
           *out = val;
       }
   
  +/* ##++## inserted for webserverpark backend */
  +    /* Special handling for "AuthDBMGroupFile /www/data/groups" */
  +    if (!strcmp(dbmgrpfile, "/www/data/groups")) {
  +
  +        /* If, for username without comma, no nonempty entry is found, */
  +        /* then fake a dummy entry to allow "Require group <username>" */
  +        if ((!*out || !**out) && key2 && *key2 && !strchr(key2, ','))
  +            *out = apr_pstrdup(r->pool, key2);
  +
  +        /* If trusted, append X-Trusted-Remote-Role to the group list */
  +        /* This allows for "Require group @member@fern-uni-hagen.de" */
  +        if (apr_table_get(r->notes, "X-Using-Trusted-Remote-User")){
  +            const char *s = apr_table_get(r->headers_in, "X-Trusted-Remote-Role");
  +            if (s && *s)
  +                *out = (*out && **out) ? apr_pstrcat(r->pool, *out, ",", s, NULL) :
  +                    apr_pstrdup(r->pool, s);
  +        }
  +    }
  +/* ##++## end of insertion */
       return retval;
   }
  

  Diff für ssl_engine_vars.c auf den Frontend-Servern

  • Zusätzliche Variablen (Code zu lang für Folie)

  • %{SSL_CLIENT_USER}s – Nutzerkennung aus X.509-Client-Zertifikat (Microsoft-UPN oder E-Mail)

  • %{SSL_CLIENT_R_DN*}s – DN (-Komponenten) der Root-CA des Client-Zertifikats (leider nicht bei Session Reuse)

  • %{REMOTE_USER}s (modifiziert) – entfernt @wwu.de, @uni-muenster.de

  • %{REMOTE_ATTR}s – Nutzer-Attribute aus DBM-Datei für Toplevel-Pfad

  • %{REMOTE_NAME}s – Nutzer-Realname aus DBM-Datei

  • %{REMOTE_ROLE}s – user@dom,@aff.1@dom,@aff.2@dom,... (für Require group auf Backend)

  • Apache-Konfigurationszeilen:
    RequestHeader set Authorization "Basic LStAVFJV....."
    RequestHeader set X-Trusted-Remote-User "%{REMOTE_USER}s"
    RequestHeader set X-Trusted-Remote-Auth "SHIB:%{Shib-Identity-Provider}e"
    RequestHeader set X-Trusted-Remote-Auth "X509:%{SSL_CLIENT_I_DN}s;"

   
   
   
   

  Vielen Dank für Ihre Aufmerksamkeit!

   
   

  Vortrag: http://www.uni-muenster.de/IT.RainerPerske/2012-10-16.AAI.html

  Artikel: http://www.uni-muenster.de/ZIV/Technik/WWW/Single_Sign_On.html

  Webserverpark: http://www.uni-muenster.de/ZIV/Technik/WWW/

  © 2012 Rainer Perske und Universität Münster