Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- de:requirements [2022/05/27 11:30] – Wolfgang Pempe
+++ de:requirements [2025/01/31 08:19] (aktuell) – Wolfgang Pempe
@@ Zeile 8: / Zeile 8: @@
 ===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:
-    * Heimateinrichtungen / IdP-Betreiber: DFN-AAI ist ein Mehrwertdienst ([[https://dfn.de/wp-content/uploads/2022/01/Entgeltordnung-DFNInternet-und-Dienst-Paket-2_0721.pdf|DFNInternet oder 'Dienst-Paket']]), 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. 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
   * 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]]
     * Hier finden Sie dafür eine [[de:checklist|Checkliste zur Registrierung der Metadaten]].
+**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.
@@ Zeile 29: / Zeile 31: @@
 ==== 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)
   * 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
@@ Zeile 50: / Zeile 52: @@
   * 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
+  * 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]]?**