Ablauf der Anbindung eines neuen Shibboleth Service Providers (kurz: SP)


Erstellen eines Feature Request (RFC)

Zusammen mit dem IdM-Team füllt der Kunde einen RFC aus.

 Die Spezifikation im RFC enthält u.a.:
  • Authentifizierter Personenkreis
  • Anzahl zu authentifizierender Nutzer (ca.)
  • Ansprechpartner
  • URL(s) zu den geschützen Anwendungen
  • EntityID des Shibboleth Service Providers (SP)
  • URL zur SP-Metadatenseite
  •  Gültigkeit des Zertifikates
  •  Attribute (derzeit möglich)

    commonName

    dfnEduPersonTermsOfStudy

    eduPersonAffiliation

    eduPersonEntitlement

    eduPersonPrincipalName

    eduPersonScoped Affiliation

    eduPersonTargetedID

    email

    givenName

    ikz

    rwthGender

    rwthID

    rwthMatrikelnummer

    rwthpersonalnummer

    rwthSVAPersonStatus

    surname

    uid (explizite
    Rücksprache nötig)

     

    siehe auch Attribute in der DFN-AAI 

 

Abstimmung des Feature Request (RFC)

Die finale Version dieses RFC legt der Kunde dem Datenschutzbeauftragten der RWTH Aachen zur Einsicht und Genehmigung vor. Eine Korrektur ist nur in begründeten Ausnahmefällen noch möglich und bedarf einer erneuten Genehmigung durch das IdM-Team sowie des Datenschutzbeauftragten

Der Kunde richtet den Service Provider gemäß den Spezifikationen im RFC ein.
Eine detaillierte Installationsanleitung ist entweder auf den Seiten des DFN oder bei Switch einsehbar, für ein Upgrade eines bestehende SP siehe ebenfalls Switch

 Shibboleth SP Beispiele-Konfiguration (verifiziert für CentOS und Shib SP 2.5.3)
  • Zertifikate
    1. Für die RWTH-Föderation akzeptieren wir i.d.R. nur Zertifikate der RWTH-CA (Ausnahmen müssen begründet werden), also der Zertifikatskette :
      Wurzelzertifikat (Telekom 2) ↔ Intermediate-Zertifikate (DFN-PCA-Zertifikat) ↔ CA-Zertifikat (RWTH-CA-Zertifikat)
    2. Mit openssl kann auf dem Server direkt wie folgt ein Zertifikat erstellt werden:

       Zertifikat erstellen

      bei ${E-MAIL} muss natürlich noch eine gültige E-Mail Adresse angegeben werden

      Wird mit einer openssl Konfigurations-Datei gearbeitet, so erfolgt die Erstellung des Zertifikates wie folgt (hier mit der Beispiel-Datei ca_req.confifg

       ca_req.config

      Bei der Erstellung des Zertifikat-Request werden die benötigten Informationen über einen Dialog abgefragt, hier sind die voreingestellten Werte anzupassen

    3. Ein für Shibboleth gültiges Zertifikat kann über die RWTH-Zertifikat-Seite beim DFN erstellt/beantragt werden.
      Hier ist folgende Auswahl zu treffen: Zertifikatsprofil: Shibboleth IdP SP
    4. Zertifikat auswechseln
  • SP-Konfigurations-Datei

     i.d.R. /etc/shibboleth/shibboleth2.xml

    • Der SP-Betreiber muss folgende Informationen eruieren:

       Informationen zum SP

      WERT

      Beschreibung

      FQDN

      Fully Qualified Domain Name, Rechnername lauf DNS/RFC

      ENTITY-ID

      eindeutige und zugewiesene ID, siehe RFC (i.d.R. FQDN/shibboleth2)

      HOME-URL

      URL zu der nach einer erfolgreichen Authentifizierung gewechselt werden soll, bspw. Web-Root des Service Providers

      CONTAC-E-MAIL

      Kontakt-E-Mail (wenn möglich eine aus dem RFC), die bei einer Fehlermeldung durch den SP als Kontaktinformation eingeblendet wird

       

       

       tkomroot.pem

       

       

      Das Root Zertifikat der an der RWTH verwendeten Zertifikatskette, dieses muss mit dem Namen "login.tkomroot.pem" im Verzeichnis /etc/shibboleth/ liegen, liegt die Datei in einem anderen Verzeichnis, so ist der volle Pfad in der aufgeführten Beispiel-Konfiguration einzutragen

      SP-CERT-KEY

      Der private Schlüssel, der bei der Zertifikats-Request-Generierung verwendet wurde, dieser liegt entweder in /etc/shibboleth (dann nur der Name inkl. Dateiendung) oder aber in einem anderen Verzeichnis (dann ist der ganze Pfad anzugeben). Hier ist darauf zu achten, dass der Shib-User des Systems (shibd oder ähnlich, siehe /etc/passwd) der Besitzer des Schlüssels ist und alleinige Leserechte auf diese Datei besitzt. Wird das Zertifikat (und somit der private Schlüssel) sowohl für Shibboleth als auch für den Web-Server verwendet, so sollte ein sowohl von Apache als auch Shibboleth zugänglicher Speicherplatz gewählt werden - die Besitzrechte des privaten Schlüssels tangiert dies jedoch nicht (Apache wird als root gestartet).

      SP-CERT

      Das Shibboleth-taugliche Zertifikat, das durch die RWTH-CA/DFN oder vergleichbare und mit dem IdM vereinbarte (i.d.R. lediglich Information über den Registrar - kein SelfSigned) Instanz übermittelt wurde. Das Zertifikat kann dem Benutzer 'root' und der Gruppe 'root' gehören, solange für alle (auch "other") das Leserecht besteht (Rechte: 444). Wird das Zertifikat sowohl für Shib als auch für den Web-Server verwendet, so sollte ein sowohl von Apache als auch von Shibboleth zugänglicher Speicherplatz gewählt werden - die Besitzrechte an dem Zertifikat müssen hier nicht geändert werden (da bereits Rechte 444 vorliegen sollten).

    • Die folgende 

       Shibboleth Service Provider Beispiel Konfiguration

      steht nach Rücksprache mit dem IdM-Team (via servicedesk@itc.rwth-aachen.de) dem Kunden zur Verfügung. Vorab sollten noch einige Informationen ausgetauscht werden (bspw. Zielsystem et al.). Alternative bei kann bei einer Installation aus dem Debian/Ubuntu Repository auch das Script

       /usr/bin/shib-metagen

      verwendet werden.

       

    •  Berechtigung anhand von Attribut Werten

      Via Shibboleth werden durch Übermittlung von Attributen die Informationen transferiert, die eine geschütze Ressource zur weiteren Verarbeitung braucht. Dies kann beispielsweise die E-Mail Adresse sein, die ein geschütztes Blog benötigt, um den Benutzer über neue Einträge etc. zu informieren. Ein anderer möglicher Fall wäre, dass durch den ServiceProvider ein Attribut Mapping stattfindet. Hier könnte z.B. die E-Mail Adresse auch gleichzeitig als Login-Name für das Blog fungieren.
      Neben diesen Grundvoraussetzungen kann aber über eine Auswertung der übermittelten Attribute am Shibboleth Service Provider - genauer dem vorgeschalteten Web-Server (im Idealfall ein Apache) - eine granulierte Zugangsberechtung etabliert werden.
      Würde zum Beispiel die E-Mail Adresse zu einem per Shibboleth geschützten Blog übermittelt werden, so könnte über eine Webserver/Apache <directory> oder <location> Directive festgelegt werden, dass nur E-Mail-Adressen, die auf @itc.rwth-aachen.de enden, valide wären und somit würden auch nur Benutzern mit einer solchen E-Mail Adresse Zugang erhalten.

      Technisch ist die feiner gegliederte Authentifizierung über die drei folgendne Konfigurationsmögloichkeiten erreichbar:

      1. Apache - statische Konfiguration
      2. Apache - .htaccess Dateien innerhalb des zu schützenden Verzeichnisses
      3. Apache/IIS - XML Access Regeln - präferiert in ausgelagerter Datei - innerhalb der Shibboleth-Konfiguration (dynamishe Änderungen ohne Neustart des Shibboleth-Service-Provider möglich)

      Weitere Infos dazu finden sich auf den Seiten

SP Konfiguration testen (am Beispiel einer Linux Installation)

 SP Funktionalität testet
  •  Shibboleth

    bzw.

  •  Apache2

    hier sollte das shib-Modul aufgelistet werden

    gewünschte Meldung hier: "Syntax OK"

     

  •  mod_shib Test (ohne Authentifizierung)

    Hier sollte stehen "A valid session was not found.", werden weitere Informationen angezeigt, ist dies ein Indiz für eine erfolgreiche Shibboleth-Sitzung.

    •  Sind die Metadaten korrekt?
    •  Login-Funktionalität prüfen
    •  Wird eine Sitzung initiert

      hier sollten Sitzungsinformationen ggf. inkl. übermittelter Attribute (Voraussetzung in shibboleth2.xml steht:showAttributeValues="true") erscheinen. Taucht hier noch "A valid session was not found." auf, stimmt etwas in der Shibboleth-Konfiguration nicht.

  •  weitere Informationen zu
    Status
    Assertion
    DiscoFeed

Shibboleth Testsystem der RWTH Aachen

Um die Funktionalität testen zu können bzw. als Hilfe für die Implementierung betreibt das IT Center einen Shibboleth Test Identity Provider.

Auf Anfrage kann dort ein Testbenutzer für Ihr Implementierungsvorhaben bereitgestellt und mit den entsprechenden Attributen versehen werden.

Siehe auch: Metadaten.

 

 Debugging
  • SAML
  • XML
    •  Syntax Prüfung
    •  Signatur Prüfung
      • mit dem XmlSecTool

         

        $ xmlsectool.sh --verifySignature --certificate metadata-signing.crt --inFile example-metadata.xml
      • xmllint (muss ggf. noch aus den Repositories nachinstalliert werden)

         

        $ xmlsec1 --verify --pubkey-cert-pem metadata-signing.crt example-metadata.xml
      • samlsing (muss ggf. noch aus den Repositories nachinstalliert werden)

         

        $ samlsign -u http://${SP-SERVER}/Shibboleth.sso/Metadata -k /path/to/x509/cert.pem
    •  weitere Informationen
    •  diverse Test-Scripte
      • auth_test.sh

         make a full roundtrip test to SimpleSAMLphp based SSO
      •  shiblogin.py