Single Sign-On an der Uni Münster

Bedienungsanleitung:

Bitte zuerst drei- bis viermal [Strg]-[+] drücken, um die Darstellung zu vergrößern.

Ein Klick rechts oben (Bereich Seitennummer) springt zur nächsten Seite.

Ein Klick links oben (Bereich Schlosslogo) springt zur vorherigen Seite.

Und hier gehts los.

Um die Inhalte auszudrucken, verwenden Sie einfach die Druckfunktion Ihres Browsers.

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/