| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung |
| de:requirements [2023/01/12 17:15] – [Identity Provider] Wolfgang Pempe | de:requirements [2025/01/31 08:19] (aktuell) – Wolfgang Pempe |
|---|
| * 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]]. |
| | **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. |
| |
| ==== Identity Provider ==== | ==== Identity Provider ==== |
| * Der Teilnehmer muss über ein funktionierendes Identity Management (System) verfügen, das mindestens die [[de:aai:assurance_idp#erste_schritte_und_voraussetzungen|Conformance Criteria des REFEDS Assurance Frameworks]] 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 |
| * 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]]?** |