Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung Nächste ÜberarbeitungBeide Seiten der Revision |
de:requirements [2020/03/26 16:39] – Wolfgang Pempe | de:requirements [2021/11/17 09:31] – Wolfgang Pempe |
---|
~~NOTOC~~ | ====== Voraussetzungen für die Teilnahme an der DFN-AAI und Best Practices ======= |
====== Voraussetzungen und Best Practices ============ | |
{{INLINETOC 2}} | ===== Voraussetzungen ===== |
===== Voraussetzungen für die Teilnahme an der DFN-AAI ===== | |
==== Allgemeine Voraussetzungen ==== | ==== Allgemeine Voraussetzungen ==== |
**Die folgenden Voraussetzungen gelten gleichermaßen für Identity Provider (IdP) und Service Provider (SP)** | <callout color="#ff9900" title="Für IdPs und SPs"> |
| Die folgenden formalen, technische und organisatorischen Voraussetzungen gelten gleichermaßen für Identity Provider (IdP) und Service Provider (SP). |
| </callout> |
===Formale Kriterien=== | ===Formale Kriterien=== |
* Zur Teilnahme an der DFN-AAI ist eine vertragliche Vereinbarung mit dem DFN-Verein erforderlich. Zur Anforderung der Vertragsunterlagen siehe unter [[de:registration|Anmeldung]]. Die Art der vertraglichen Vereinbarung hängt von der Art der Teilnahme an der DFN-AAI ab: | * Zur Teilnahme an der DFN-AAI ist eine vertragliche Vereinbarung mit dem DFN-Verein erforderlich. Zur Anforderung der Vertragsunterlagen siehe unter [[de:registration|Anmeldung]]. Die Art der vertraglichen Vereinbarung hängt von der Art der Teilnahme an der DFN-AAI ab: |
* Heimateinrichtungen / IdP-Betreiber: DFN-AAI ist ein Mehrwertdienst ([[https://www.dfn.de/dienstleistungen/dfninternet/entgelte/|DFNInternet ab I02]]), erforderlich sind Rahmenvertrag und Dienstvereinbarung. Letztere enthält auch Vereinbarungen für den SP-Betrieb. | * Heimateinrichtungen / IdP-Betreiber: DFN-AAI ist ein Mehrwertdienst ([[https://www.dfn.de/dienstleistungen/dfninternet/entgelte/|DFNInternet ab I02]]), erforderlich sind Rahmenvertrag und Dienstvereinbarung. Letztere enthält auch Vereinbarungen für den SP-Betrieb. |
* Dienstanbieter / SP-Betreiber: SP-Agreement (englisch) – keine sonstigen Voraussetzungen | * Dienstanbieter / SP-Betreiber: SP-Agreement (englisch) – keine sonstigen Voraussetzungen |
* Registrierung der IdP-/SP-Metadaten | * Die aktuell gültigen [[de:normative_documents|Policy-Dokumente]] sind zu beachten. |
* Siehe hierzu die [[de:metadata_admin_tool:checklist|Checkliste zur Registrierung der Metadaten]] | * Registrieren Sie die IdP-/SP-Metadaten über unsere [[https://www.aai.dfn.de/verwaltung|Metadatenverwaltung]] |
| * Hier finden Sie dafür eine [[de:checklist|Checkliste zur Registrierung der Metadaten]]. |
===Technische und organisatorische Kriterien=== | ===Technische und organisatorische Kriterien=== |
* Unterstützung des [[https://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf|SAML 2 Standards]] (zukünftig alternativ OpenID Connect, Datum wird bekanntgegeben). Vom Einsatz von Eigenimplementierungen wird dringend abgeraten. Stattdessen sollte IdP-/SP-Software eingesetzt werden, für die langfristiger Support und Weiterentwicklung seitens der Community gewährleistet sind, z.B. [[https://www.shibboleth.net/products/|Shibboleth]] oder [[https://simplesamlphp.org/|SimpleSAMLphp]]. Der DFN-Verein ist Mitglied im [[https://www.shibboleth.net/|Shibboleth-Konsortium]] und bietet für diese Software [[https://doku.tid.dfn.de/de:aai:portfolio|Support, Workshops und Schulungen]] an. | * Unterstützung des [[https://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf|SAML 2 Standards]] (zukünftig alternativ OpenID Connect, Datum wird bekanntgegeben). Vom Einsatz von Eigenimplementierungen wird dringend abgeraten. Stattdessen sollte IdP-/SP-Software eingesetzt werden, für die langfristiger Support und Weiterentwicklung seitens der Community gewährleistet sind, z.B. [[https://www.shibboleth.net/products/|Shibboleth]] oder [[https://simplesamlphp.org/|SimpleSAMLphp]]. Der DFN-Verein ist Mitglied im [[https://www.shibboleth.net/|Shibboleth-Konsortium]] und bietet für diese Software [[https://doku.tid.dfn.de/de:aai:portfolio|Support, Workshops und Schulungen]] an. |
* [[de:metadata|Föderationsmetadaten]] | * Die [[de:metadata|Föderationsmetadaten]] enthalten alle für die Kommunikation zwischen IdP und SP nötigen Informationen, z.B. EntityIDs (Identifier der Systeme), Service-Endpunkte, Kontaktinformationen und Zertifikate. Sie |
* müssen **mindestens** einmal täglich heruntergeladen werden | * müssen **mindestens** einmal täglich heruntergeladen werden. |
* die Signatur der Metadaten muss anhand des jeweils gültigen, von der DFN-AAI bereitgestellten Zertifikats validiert werden | * Die Signatur der Metadaten muss anhand des jeweils gültigen, von der DFN-AAI bereitgestellten Zertifikats validiert werden. |
* Betriebssicherheit | * Betriebssicherheit |
* Die eingesetzte Software muss aktuell gehalten und Security Updates/Patches zeitnah eingespielt werden | * Die eingesetzte Software muss aktuell gehalten und Security Updates/Patches zeitnah eingespielt werden. |
* Bei der [[de:metadata_admin_tool:checklist|Registrierung der Metadaten]] muss ein Kontakt für Sicherheitsfragen angegeben werden | * Bei der [[de:checklist|Registrierung der Metadaten]] muss ein Kontakt für Sicherheitsfragen angegeben werden. |
* Zertifikate für die SAML-basierte Kommunikation | * Zertifikate für die SAML-basierte Kommunikation |
* Die eingesetzte SAML-Software muss beim Wechsel des Schlüsselmaterials einen unterbrechungsfreien Key Rollover ermöglichen. Informationen und weiterführende Hinweise finden sich unter [[de:certificates#zertifikate_fuer_die_saml-basierte_kommunikation|Zertifikate]] | * Die eingesetzte SAML-Software muss beim Wechsel des Schlüsselmaterials einen unterbrechungsfreien Key Rollover ermöglichen. Informationen und weiterführende Hinweise finden sich unter [[de:certificates#zertifikate_fuer_die_saml-basierte_kommunikation|Zertifikate]]. |
| * https für Binding URLs |
| * Sämtliche in den Föderationsmetadaten hinterlegten Endpunkte müssen über TLS abgesichert sein |
* Sonstiges | * Sonstiges |
* Orientieren Sie sich bitte an den weiteren, unter [[de:join|Teilnahme]] aufgelisteten Schritten | * Orientieren Sie sich bitte an den weiteren, unter [[de:join|Teilnahme]] aufgelisteten Schritten. |
| |
==== Identity Provider ==== | ==== Identity Provider ==== |
| |
==== Service Provider ==== | ==== Service Provider ==== |
* Ein Service Provider muss in der Lage sein, [[de:common_attributes|gängige Attribute]] in [[https://wiki.shibboleth.net/confluence/display/CONCEPT/SAMLAttributeNaming|standardkonformem Encoding]] (urn:oid) zu empfangen und zu verarbeiten. | <callout color="#ff9900" title="Warum wollen Hochschulen und Forschungseinrichtungen föderiertes Web Single Sign-On?"> |
* Die für die Nutzung des Dienstes erforderlichen Attribute müssen in den Föderationsmetadaten deklariert werden | * Nutzer*innen haben mit Web-SSO nur noch //eine// Nutzerkennung und //ein// Passwort - nicht eins pro Dienst. |
* Ein Service Provider muss in der Lage sein, Attribut-basierte Autorisierung zu implementieren, sofern nicht alle über einen IdP verfügbare Identitäten auf die betreffenden Ressourcen zugreifen dürfen. Hierbei gilt es zu beachten, dass sich üblicherweise nicht nur Angehörige einer Einrichtung über einen IdP authentisieren können, sondern jede im IdM der Einrichtung geführte Identität. Dies können z.B. auch Gäste, Alumni oder Stadtnutzer einer Bibliothek sein. | * Sie sind nach //einem// Login am IdP mit ihrem Browser für einen bestimmten Zeitraum an //allen// angebundenen Diensten angemeldet. |
* Da Shibboleth IdPs Assertions per Default verschlüsseln, wird **dringend empfohlen**, SP-Implementierungen einzusetzen, die in der Lage sind, verschlüsselte Assertions zu entschlüsseln. | * Die zentrale Loginseite kann von IdP-Betreiber*innen nach aktuellen Standards abgesichert werden. |
* Die XML-Signatur der seitens eines IdP übermittelten Daten muss anhand des entsprechenden, für den betreffenden IdP in den Föderationsmetadaten hinterlegten Zertifikats validiert werden. Dies betrifft sowohl die signierte SAML Response als auch die SAML Assertion (Teil der Response, fallweise signiert). | * Passwörter werden nie an Service Provider übermittelt, sie bleiben in der Heimateinrichtung. |
| * Die Autorisierung erfolgt aufgrund von standardisierten, aussagekräftigen Attributen (s.u.). IdP-Betreiber*innen können bei der Konfiguration von Attributfreigaben prüfen, ob sich Dienstanbieter an das Gebot der Datensparsamkeit halten. |
| * Nutzer*innen werden vor jeder neuen Freigabe von Attributen an einen Dienst explizit um Zustimmung gebeten. Der Identity Provider kann diese Information speichern. |
| </callout> |
| * Ein Service Provider, der mit mehr als einer Heimateinrichtung zusammenarbeitet, muss eine Möglichkeit zur **[[de:discovery|Einrichtungsauswahl]]** bereitstellen. |
| * Ein Service Provider muss in der Lage sein, **[[de:common_attributes|gängige Attribute]] in [[https://wiki.shibboleth.net/confluence/display/CONCEPT/SAMLAttributeNaming|standardkonformem Encoding]]** (urn:oid) zu empfangen und zu verarbeiten. Bitte erfragen Sie bei Bedarf bei den Betreiber*innen des jeweiligen IdM die Attributinhalte. (Bsp: Welche Affiliations werden für Mitarbeiter*innen übermittelt?) |
| * Die für die Nutzung des Dienstes erforderlichen Attribute müssen **in den Föderationsmetadaten deklariert** werden |
| * Ein Service Provider muss in der Lage sein, **Föderationsmetadaten regelmäßig herunterzuladen** und aus ihnen nötige Informationen pro EntityID herauszufiltern. |
| * Ein Service Provider muss in der Lage sein, **Attribut-basierte Autorisierung** zu implementieren, sofern nicht alle über einen IdP verfügbare Identitäten auf die betreffenden Ressourcen zugreifen dürfen. Hierbei gilt es zu beachten, dass sich üblicherweise nicht nur Angehörige einer Einrichtung über einen IdP authentisieren können, sondern jede im IdM der Einrichtung geführte Identität. Dies können z.B. auch Gäste, Alumni oder Stadtnutzer einer Bibliothek sein. |
| * Da Shibboleth IdPs Assertions per Default verschlüsseln, wird **dringend empfohlen**, SP-Implementierungen einzusetzen, die in der Lage sind, **verschlüsselte Assertions zu entschlüsseln**. Der SP sollte zudem in der Lage sein, mit zwei Zertifikaten/Schlüsseln umzugehen, da während des Zertifikatstausches vorübergehend verschlüsselte Assertions eingehen, die entweder noch mit dem alten/ablaufenden, oder bereits mit dem neuen Zertifikat verschlüsselt wurden. |
| * Ein IdP übermittelt seine Daten signiert an SPs. Diese **XML-Signatur** muss anhand des Zertifikates **validiert** werden, das für den jeweiligen IdP in den Föderationsmetadaten hinterlegt ist. Dies betrifft sowohl die signierte SAML Response, als auch die SAML Assertion (Teil der Response, fallweise signiert). |
* Provisionierung und Deprovisionierung | * Provisionierung und Deprovisionierung |
* SP-seitige, d.h. dienstlokale Nutzerkonten und -Profile müssen anhand von Attributen erstellt werden, die von den Identity Providern der teilnehmenden Einrichtungen übertragen werden. Provisionierung von Nutzerdaten über andere Kanäle (z.B. CSV-Dateien, Active Directory) ist nicht zulässig | * SP-seitige, d.h. dienstlokale **Nutzerkonten und -Profile** müssen anhand von Attributen erstellt werden, die von den Identity Providern der teilnehmenden Einrichtungen übertragen werden. Provisionierung von Nutzerdaten über andere Kanäle (z.B. CSV-Dateien, Active Directory) ist nicht zulässig |
* Für die Deprovisionierung/Löschung dienstlokaler Nutzerkonten sind geeignete Verfahren zu implementieren. Dies können insbesondere eine automatische Löschung/Deaktivierung eines Nutzerkontos nach einer bestimmten Zeit der Inaktivität oder eine Deprovisionierung via [[de:shibidp3userdepro|SAML AttributeQuery]] sein. | * Für die **Deprovisionierung/Löschung** dienstlokaler Nutzerkonten sind geeignete Verfahren zu implementieren. Dies können insbesondere eine automatische Löschung/Deaktivierung eines Nutzerkontos nach einer bestimmten Zeit der Inaktivität oder eine Deprovisionierung via [[de:shibidp:config-deprovisionierung|SAML AttributeQuery]] sein. |
| |
===== Best Practice Empfehlungen ===== | **Warum sprechen die IdP-Betreiber*innen von [[de:metadata_local|lokalen Metadaten]]?** |
| * Sie haben eine Ressource, die nur von //einer// Hochschule oder Forschungseinrichtung genutzt werden soll, mit einer SP-Software geschützt. Dieser SP wird nicht in die große Föderation aufgenommen, er ist ja nur für eine Einrichtung gedacht. Jetzt möchten Sie diesen SP mit dem //einen// IdP verbinden. |
| * Es ist zwar technisch möglich, dem IdP die SP-Metadaten als einzelne xml-Datei zu geben und umgekehrt. |
| * Es ist jedoch für beide Seiten komfortabler, wenn sie sich über einen **gemeinsamen dynamischen Metadatensatz** kennen. Für genau diesen Fall - die Verbandelung eines IdPs mit den einrichtungsinternen Diensten - gibt es die sogenannten lokalen Metadaten: |
| * Der lokale Metadatensatz lässt sich über die Metadatenverwaltung der DFN-AAI pflegen ([[de:metadata_local|Dokumentation]]). Er enthält immer den IdP und alle hausinternen SPs, die dem Datensatz über die Verwaltung hinzugefügt wurden. |
| * Der lokale Metadatensatz wird dann auf dem IdP und den SPs regelmäßig eingelesen. |
| * Wer Zugriff auf die Metadatenverwaltung hat, kann dort die Metadaten aktualisieren. Steht beim Identity Provider ein Zertifikatswechsel an, dann reicht es, das neue Zertifikat in der Metadatenverwaltung beim IdP einzustellen, damit alle Service Provider in allen Föderationen (DFN-AAI, lokal, international) das Zertifikat binnen weniger Stunden bekommen. Als SP-Betreiber*in können Sie dem IdP ein neues Zertifikat auf demselben Weg bekannt machen - kein Editieren oder Verschicken von xml-Dateien. |
| * Die Zertifikate in lokalen Metadatensätzen werden von uns auf das Ablaufdatum hin überwacht. Die technischen Ansprechpersonen und Metadatenadmins bekommen rechtzeitig eine Erinnerung an das Zertifikatsrollover. Diesen Service können wir natürlich nicht bieten, wenn Sie direkt mit der Gegenstelle xml-Dateien austauschen. |
| ===== Best Practice ===== |
* Single Logout | * Single Logout |
* Sowohl IdP als auch SP sollten Single Logout unterstützen | * Sowohl IdP als auch SP sollten das [[http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf|Single Logout Profile]] unterstützen |
* Die Session einer von einem SP geschützten Anwendung sollte nach Möglichkeit an die SP-Session gekoppelt werden. Siehe hierzu und [[de:shibslo|Single Logout]]. | * Die Session einer von einem SP geschützten Anwendung sollte nach Möglichkeit an die SP-Session gekoppelt werden. Siehe hierzu unter [[de:shibslo|Single Logout]]. |
* Im Sinne einer maximalen, auch internationalen Interoperabilität ([[de:edugain|eduGAIN]]) wird empfohlen, die aktuelle Fassung des [[https://kantarainitiative.github.io/SAMLprofiles/saml2int.html|SAML2 Interoperability Profile (saml2int)]] bestmöglich umzusetzen. Zu den davon abweichenden, in der DFN-AAI gültigen Zertifikatregeln siehe unter [[de:certificates#zertifikate_fuer_die_saml-basierte_kommunikation|Zertifikate]]. | * Im Sinne einer maximalen, auch internationalen Interoperabilität ([[de:edugain|eduGAIN]]) wird empfohlen, die aktuelle Fassung des [[https://kantarainitiative.github.io/SAMLprofiles/saml2int.html|SAML2 Interoperability Profile (saml2int)]] bestmöglich umzusetzen. Zu den davon abweichenden, in der DFN-AAI gültigen Zertifikatregeln siehe unter [[de:certificates#zertifikate_fuer_die_saml-basierte_kommunikation|Zertifikate]]. |