| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung |
| de:requirements [2026/04/24 11:58] – Wolfgang Pempe | 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, 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. | * **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]] |
| **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]]. | **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=== | === 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 |
| * 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) 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. | * 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) |
| * 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. |