| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung Nächste ÜberarbeitungBeide Seiten der Revision |
| de:requirements [2020/03/26 16:43] – Wolfgang Pempe | de:requirements [2021/03/01 11:04] – [Service Provider] Silke Meyer |
|---|
| * 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 |
| | * Die aktuell gültigen [[de:normative_documents|Policy-Dokumente]] sind zu beachten. |
| * Registrierung der IdP-/SP-Metadaten | * Registrierung der IdP-/SP-Metadaten |
| * Siehe hierzu die [[de:metadata_admin_tool:checklist|Checkliste zur Registrierung der Metadaten]] | * Siehe hierzu die [[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. |
| * 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]] |
| * Die für die Nutzung des Dienstes erforderlichen Attribute müssen in den Föderationsmetadaten deklariert werden | * 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, 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. | * 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. | * 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. |
| * 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). | * 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). |
| * Provisionierung und Deprovisionierung | * Provisionierung und Deprovisionierung |
| * Single Logout | * Single Logout |
| * 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 | * 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]]. |