Checkliste für das Ausfüllen der Metadaten

Beachten Sie bitte auch die aktuell gültige Fassung des Metadata Registration Practice Statements.

Bitte beherzigen Sie die Punkte dieser Checkliste, bevor Sie Ihren neuen IdP/SP in die Produktivföderation aufnehmen, bevor Sie also diesen Radio-Button klicken:

• Füllen Sie möglichst alle Felder aus. Wenn Warnungen auftauchen, beheben Sie sie zuerst.
• Verwenden Sie nur Hostnames bzw. URLs, die von außen auflösbar sind. Hausinterne Top-Level-Domains lassen sich nicht speichern.

Ein eindeutiger String, der diese Entität weltweit von anderen Entitäten unterscheidet. Die Entity ID ist ein absoluter URL im https-Schema. Die teilnehmende Organisation gewährleistet, dass sie berechtigt ist, die im URL enthaltene Domain zu verwenden. Details im Metadata Registration Practice Statement.

Beispiele:

• IdP: https://idp.example.org/idp/shibboleth
• SP: https://sp.example.org/shibboleth

Bemerkungen: Die Entity ID findet sich bei Shibboleth IdPs in der Datei ./conf/idp.properties, bei Shibboleth SPs in der Datei /etc/shibboleth/shibboleth2.xml.

Achtung: Eine einmal vergebene Entity ID kann nicht mehr geändert werden! Das Ändern der Entity ID in dieser Maske führt dazu, dass eine neue Entität mit denselben Metadaten angelegt wird. Die bestehende Entität bleibt unverändert erhalten und muss ggf. gelöscht werden.

Das Element <mdui:DisplayName> beinhaltet eine menschenlesbare Bezeichnung des Dienstes. Der Display Name von IdPs wird im Auswahlmenü von Discovery Services angezeigt. Der Display Name von SPs wird beim Login am IdP sowie im Dialog zur Übertragung der vom SP angeforderten Nutzerdaten angezeigt. Falls der Display Name ein „Kaufmanns-Und“ enthält, muss dieses als & eingegeben werden!

Eine kurze Beschreibung des Providers für das öffentliche DFN-AAI-Verzeichnis und andere Dienste, die menschenlesbare Informationen aus Föderationsmetadaten extrahieren. Beispiel: „Identity Provider der Universität XY“. Falls die Beschreibung ein „Kaufmanns-Und“ enthält, muss dieses als & eingegeben werden!

Ein Link zu einer Seite, die weitere Informationen zum Dienst bzw. bei IdPs zur Einrichtung enthält.

Ein Link zur Datenschutzerklärung des jeweiligen IdP oder SP. Das Feld ist für Service Provider Pflicht. Wenn Sie nur eine deutschsprachige Datenschutzerklärung haben, können Sie das Feld „Privacy Statement URL (englisch)“ leer lassen und umgekehrt.

Link zu Logo und Favicon der Einrichtung bzw. des Dienstanbieters. Ein IdP-Favicon wird von den meisten Discovery Services bei der Einrichtungsauswahl angezeigt. Ein SP-Logo wird auf der Login-Seite des IdP eingeblendet. Für Service Provider wird *kein* Favicon benötigt. Vorgaben und Empfehlungen:

• Neue Logos und Favicons müssen in die Metadatenverwaltung hochgeladen werden und werden von ihr ausgeliefert. Logos müssen 64 bis 240 Pixel breit und 48 bis 180 Pixel hoch sein.
• Favicons sollten eine Größe von 16 mal 16 Pixel haben
• Transparenter Hintergrund

Vgl. hierzu auch die Empfehlungen im Shibboleth Wiki.

Kontaktinformationen wie E-Mail-Adresse und Telefonnummer ihres User-Helpdesks für das öffentliche DFN-AAI-Verzeichnis.

Zu Entity Attributes bzw. Entity Categories schauen Sie bitte diese ausführlichere Dokumentation an.

Anhand dieses Entity Attributs signalisiert ein Identity Provider, dass er grundsätzlich die in der entsprechenden Entity Category definierten Attribute an die betreffenden Service Provider überträgt.

Pro Entität sollten Kontaktadressen für folgende Funktionen angegeben werden (nach Möglichkeit keine persönlichen E-Mail-Adressen):

• administrativ: für Fragen bzgl. Verwaltung der Daten und Einhaltung der DFN-AAI-Richtlinien
• technisch: betriebliche Belange (z.B. für die Behebung technischer Störungen)
• support: Anlaufstelle für Endnutzer*innen
• security: Kontakt zur Meldung und Bearbeitung von Sicherheitsvorfällen, s.a. Choosing a Sirtfi Contact und Security Incident Response in der DFN-AAI.

Gültigkeitsbereich des IdP, meist die Domain der Einrichtung. SPs überprüfen die von einem IdP übermittelten 'scoped'-Attribute (z.B. eduPersonScopedAffiliation) gegen den hier angegebenen String und verwerfen die betreffenden Attribute ggf. Die teilnehmende Einrichtung muss berechtigt sein, die im Scope angegebene(n) Domain(s) zu führen. Details im Metadata Registration Practice Statement.

URL zum Initialisieren eines Anmeldeprozesses beim SP.

URL zum Starten des IdP-Discovery Mechanismus am SP.

Hier tragen Sie das Zertifikat ein, das für die SAML-Kommunikation verwendet werden soll, im PEM-Format. Jeder IdP/SP muss ein Zertifikat für Signierung und Verschlüsselung der SAML-Kommunikation publizieren. Dafür kann dasselbe Zertifikat verwendet werden (leerer Verwendungszweck) oder auch zwei verschiedene (Verwendungszweck im Drop-Down-Menü auswählen). Ausführliche Informationen zu Zertifikaten, Zertifikatstausch und Zertifikatskette sind auf der Seite Zertiftikate.

Für Service Provider, optional: Falls der betreffende SP Attribute Queries und Artifact Queries ausführen können soll, sollten SP-Zertifikate mit dem Client-Attribut ausgestattet sein. Bei der DFN-PKI sorgt das Profil „Shibboleth-IdP/-SP“ dafür, dass es dabei ist. Wenn Sie nicht die DFN-PKI nutzen, können Sie sich an der Dokumentation unserer Schweizer Kolleg*innen orientieren. Wenn Sie keine Attribute Queries und Artifact Queries brauchen, dann deaktivieren Sie bitte dieses Feature in der SP-Konfiguration. Beim Shibboleth SP muss das Element <AttributeResolver type=„Query“> auszukommentiert und shibd erneut gestartet werden. Außerdem sollten Sie den Binding URL für Artifact Resolution Services sowie alle SOAP-Bindings (Logout) entfernen. So überprüfen Sie Ihr SP-Zertifikat am Beispiel von openssl:

openssl x509 -in sp.example.org.crt.pem -noout -text | grep -A 1 "X509v3 Extended Key Usage"
            X509v3 Extended Key Usage:
                TLS Web Client Authentication, TLS Web Server Authentication

Identity und Service Provider mit Single Logout-Unterstützung müssen hier die entsprechenden Endpunkte publizieren.

Beispiel-Endpunkte für Shibboleth-IdPs:

https://idp.example.org/idp/profile/SAML2/Redirect/SLO
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect

https://idp.example.org/idp/profile/SAML2/POST/SLO
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST

https://idp.example.org/idp/profile/SAML2/POST-SimpleSign/SLO
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign

https://idp.example.org:8443/idp/profile/SAML2/SOAP/SLO
urn:oasis:names:tc:SAML:2.0:bindings:SOAP

Beispiel-Endpunkte für Shibboleth-SPs:

https://sp.example.org/Shibboleth.sso/SLO/SOAP
urn:oasis:names:tc:SAML:2.0:bindings:SOAP

https://sp.example.org/Shibboleth.sso/SLO/Redirect
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect

https://sp.example.org/Shibboleth.sso/SLO/POST
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST

https://sp.example.org/Shibboleth.sso/SLO/Artifact
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact

Die Endpunkte, an denen der Service Provider SAML-Assertions entgegennimmt. Beispiele:

Location: https://sp.example.org:8443/Shibboleth.sso/SAML2/POST
Binding: urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
Index: 1

Location: https://sp.example.org:8443/Shibboleth.sso/SAML2/POST-SimpleSign
Binding: urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign
Index: 2

Location: https://sp.example.org:8443/Shibboleth.sso/SAML2/Artifact
Binding: urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact
Index: 3

Location: https://sp.example.org:8443/Shibboleth.sso/SAML2/ECP
Binding: urn:oasis:names:tc:SAML:2.0:bindings:PAOS
Index: 4

Liste der Attribute, die der Service Provider entgegennimmt.

Beispiel:

Location: https://idp.example.org:8443/idp/profile/SAML2/SOAP/ArtifactResolution
Binding: urn:oasis:names:tc:SAML:2.0:bindings:SOAP
Index: 1

Single Sign On-Endpunkte eines IdPs. Beispiele:

Location: https://idp.example.org/idp/profile/SAML2/POST/SSO
Binding: urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
Location: https://idp.example.org/idp/profile/SAML2/POST-Simple-Sign/SSO
Binding: urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-Simple-Sign
Location: https://idp.example.org/idp/profile/SAML2/Redirect/SSO
Binding: urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect

IdP-Endpunkte für Attribute Queries über SOAP-Requests. Beispiel:

Location: https://idp.example.org:8443/idp/profile/SAML2/SOAP/AttributeQuery
Binding: urn:oasis:names:tc:SAML:2.0:bindings:SOAP

Die NameID-Formate, die seitens der IdP-/SP-Instanz unterstützt werden. Es sollte mindestens urn:oasis:names:tc:SAML:2.0:nameid-format:transient ausgewählt werden. Dieses Format ist i.d.R. nach einer Standard-Installation aktiv und wird für die Logout-Funktionalität benötigt. Weitere Formate sollten hier nur ausgewählt werden, wenn diese zuvor in der IdP-/SP-Konfiguration aktiviert worden sind.

Hier erfolgt die Zuordnung, in welche Umgebung(en) der IdP/SP aufgenommen werden soll. Dabei gilt:

• Die Zulassung für die Testföderation und die lokalen Metadaten erfolgt automatisch.
• Für die DFN-AAI Produktivföderation erfolgt die Freischaltung nach eingehender Prüfung durch das DFN-AAI Team. Die Freischaltung erfolgt in der Regel am nächsten Werktag, es sei denn, für diese Entität werden in der Verwaltungsoberfläche noch Fehler angezeigt. Diese Fehler müssen zuvor behoben werden!
• In die internationale Föderation eduGAIN können Sie ein IdP/SP erst aufnehmen, wenn er in DFN-AAI aufgenommen wurde.
• Hinweise zu den DFN-AAI-Policies finden sich hier im AAI-Wiki. Bei Fragen wenden Sie sich an die AAI-Hotline.

Weiterhin ist Folgendes zu beachten:

IdP:

• Zusätzlich zur DFN-AAI Produktivföderation kann ein IdP in der DFN-AAI-Testföderation und den lokalen Metadaten angemeldet sein. Von einem dauerhaften Verbleib in der Testföderation wird dringend abgeraten!

SP:

• Zusätzlich zur DFN-AAI Produktivföderation kann der SP auch in der DFN-AAI-Testföderation angemeldet sein (für einen produktiv-SP aber nicht empfohlen, um Logins über Test-IdPs unmöglich zu machen).
• Der Punkt „lokale Metadaten“ kann nur ausgewählt werden, wenn DFN-AAI nicht gewählt ist. Diese Option ist nur für Einrichtungen verfügbar, die eine Dienstvereinbarung abgeschlossen und mindestens einen IdP registriert haben.

• Nehmen Sie Ihr System in die Testföderation DFN-AAI-Test auf. Nutzen Sie unsere öffentlichen Testsysteme, um zu schauen, ob erfolgreich Attribute übertragen werden.

• Erst, wenn das klappt, beantragen Sie die Aufnahme in die Produktivföderation.