| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung |
| de:requirements [2021/05/03 13:12] – ↷ Links angepasst weil Seiten im Wiki verschoben wurden 66.249.79.137 | de:requirements [2026/10/07 11:56] (aktuell) – Wolfgang Pempe |
|---|
| ===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, d.h. als Voraussetzung für die Teilnahme an der DFN-AAI muss die betreffende Einrichtung einen [[https://dfn.de/wp-content/uploads/2022/01/Entgeltordnung-DFNInternet-und-Dienst-Paket-2_0721.pdf|DFNInternet-Anschluss oder das 'Dienst-Paket']] buchen sowie den zugehörigen Rahmenvertrag unterzeichnen - hierfür wenden Sie sich bitte an [[dfn-internet@dfn.de|dfn-internet@dfn.de]]. Ergänzend hierzu ist eine Dienstvereinbarung für die Teilnahme an der DFN-AAI abzuschließen. Diese enthält auch Vereinbarungen für den SP-Betrieb. |
| * Dienstanbieter / SP-Betreiber: SP-Agreement (englisch) – keine sonstigen Voraussetzungen | * **Dienstanbieter / SP-Betreiber:** SP-Agreement (englisch) – der betreffende Dienst muss inhaltlich für die an der DFN-AAI teilnehmenden Heimateinrichtungen relevant sein und zumindest perspektivisch von mehr als einer Heimateinrichtung genutzt werden. Ansonsten kann der Service-Provider ohne vertragliche Vereinbarung mit dem DFN-Vereinin den lokalen Metadaten der betreffenden Heimateinrichtung registriert werden (siehe unten). Ausnahmen hiervon müssen einvernehmlich geregelt werden. |
| * Die aktuell gültigen [[de:normative_documents|Policy-Dokumente]] sind zu beachten. | * Die aktuell gültigen [[de:normative_documents|Policy-Dokumente]] sind zu beachten. |
| * Registrieren Sie die IdP-/SP-Metadaten über unsere [[https://www.aai.dfn.de/verwaltung|Metadatenverwaltung]] | * 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]]. | * Hier finden Sie dafür eine [[de:checklist|Checkliste zur Registrierung der Metadaten]]. |
| ===Technische und organisatorische Kriterien=== | **Hinweis:** Auch Dienste, die ausschließlich OpenID Connect unterstützen, können an die DFN-AAI angebunden werden. Kontaktieren Sie hierzu bitte das [[de:aai:contact|DFN-AAI Team]]. |
| | |
| | === 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. |
| * 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 | * 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 |
| * 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 ==== |
| * Der Teilnehmer muss über ein funktionierendes Identity Management (System) verfügen, das mindestens die Anforderungen der [[de:degrees_of_reliance|Verlässlichkeitsklasse]] 'Basic' erfüllt. Nutzer*innen und -Gruppen, für die diese Anforderungen nicht erfüllt sind, müssen von der Nutzung der DFN-AAI ausgeschlossen werden. | * Der Teilnehmer muss über ein funktionierendes Identity Management (System) und einen Identity Provider verfügen, die mindestens die [[de:aai:assurance_idp#erste_schritte_und_voraussetzungen|Conformance Criteria des REFEDS Assurance Frameworks]] erfüllen. Nutzer*innen und -Gruppen, für die diese Anforderungen nicht erfüllt sind, müssen von der Nutzung der DFN-AAI ausgeschlossen werden. |
| * Ein Identity Provider **sollte** in der Lage sein, die [[de:common_attributes|wichtigsten Attribute]] zu produzieren. Diese Attribute **müssen** in [[https://wiki.shibboleth.net/confluence/display/CONCEPT/SAMLAttributeNaming|standardkonformem Encoding]] (urn:oid) an Service Provider übertragen werden (sofern im Einzelfall zur Erbringung des Dienstes erforderlich und datenschutzrechtlich zulässig) | * Ein Identity Provider **sollte** in der Lage sein, die [[de:common_attributes|wichtigsten Attribute]] zu produzieren. Diese Attribute **müssen** in [[https://wiki.shibboleth.net/confluence/display/CONCEPT/SAMLAttributeNaming|standardkonformem Encoding]] (urn:oid) an Service Provider übertragen werden (sofern im Einzelfall zur Erbringung des Dienstes erforderlich und datenschutzrechtlich zulässig) |
| * Die Signatur eines von einem SP gesendeten Authentication Requests muss anhand des entsprechenden, für den betreffenden SP in den Föderationsmetadaten hinterlegten Zertifikats validiert werden | * Die Signatur eines von einem SP gesendeten Authentication Requests muss anhand des entsprechenden, für den betreffenden SP in den Föderationsmetadaten hinterlegten Zertifikats validiert werden |
| * Ist für einen IdP in den Föderationsmetadaten ein Zertifikat mit ''use="encryption"'' hinterlegt, muss der IdP in der Lage sein, anhand dieses Zertifikats verschlüsselte SAML Messages eines SP (i.d.R. Logout Requests) zu entschlüsseln. | * Ist für einen IdP in den Föderationsmetadaten ein Zertifikat mit ''use="encryption"'' hinterlegt, muss der IdP in der Lage sein, anhand dieses Zertifikats verschlüsselte SAML Messages eines SP (i.d.R. Logout Requests) zu entschlüsseln. |
| |
| ==== Service Provider ==== | ==== Service-Provider ==== |
| <callout color="#ff9900" title="Warum wollen Hochschulen und Forschungseinrichtungen föderiertes Web Single Sign-On?"> | <callout color="#ff9900" title="Warum wollen Hochschulen und Forschungseinrichtungen föderiertes Web Single Sign-On?"> |
| * Nutzer*innen haben mit Web-SSO nur noch //eine// Nutzerkennung und //ein// Passwort - nicht eins pro Dienst. | * 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, **[[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?) | * 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 | * 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, **[[de:metadata|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. | * 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. | * 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). | * 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 | * 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. |
| * 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:shibidp:config-deprovisionierung|SAML AttributeQuery]] sein. | |
| |
| **Warum sprechen die IdP-Betreiber*innen von [[de:metadata_local|lokalen Metadaten]]?** | **Warum sprechen die IdP-Betreiber*innen von [[de:metadata_local|lokalen Metadaten]]?** |