Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
de:requirements [2021/03/02 08:50] – [Allgemeine Voraussetzungen] Silke Meyerde:requirements [2023/01/12 17:15] (aktuell) – [Identity Provider] Wolfgang Pempe
Zeile 4: Zeile 4:
 ==== Allgemeine Voraussetzungen ==== ==== Allgemeine Voraussetzungen ====
 <callout color="#ff9900" title="Für IdPs und SPs"> <callout color="#ff9900" title="Für IdPs und SPs">
-Die folgenden formalen, technische und organisatorischen Voraussetzungen gelten für Identity Provider (IdP) und Service Provider (SP).+Die folgenden formalen, technische und organisatorischen Voraussetzungen gelten gleichermaßen für Identity Provider (IdP) und Service Provider (SP).
 </callout> </callout>
 ===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. Ergänzend hierzu ist eine Dienstvereinbarung für die Teilnahme an der DFN-AAI abzuschließenDiese 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.   * Die aktuell gültigen [[de:normative_documents|Policy-Dokumente]] sind zu beachten.
Zeile 19: Zeile 19:
     * Die Signatur der Metadaten muss anhand des jeweils gültigen, von der DFN-AAI bereitgestellten Zertifikats validiert werden.     * Die Signatur der Metadaten muss anhand des jeweils gültigen, von der DFN-AAI bereitgestellten Zertifikats validiert werden.
   * 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: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]].
 +  * 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
Zeile 41: Zeile 43:
   * Nutzer*innen werden vor jeder neuen Freigabe von Attributen an einen Dienst explizit um Zustimmung gebeten. Der Identity Provider kann diese Information speichern.   * Nutzer*innen werden vor jeder neuen Freigabe von Attributen an einen Dienst explizit um Zustimmung gebeten. Der Identity Provider kann diese Information speichern.
 </callout> </callout>
-  * Ein Service Provider muss eine Möglichkeit zur **[[de:discovery|Einrichtungsauswahl]]** bereitstellen.+  * Ein Service Provider, der mit mehr als einer Heimateinrichtung zusammenarbeitet, muss eine Möglichkeit zur **[[de:discovery|Einrichtungsauswahl]]** bereitstellen.
   * 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.
Zeile 50: Zeile 52:
   * Provisionierung und Deprovisionierung    * Provisionierung und Deprovisionierung 
     * 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      * 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:shibidp3userdepro|SAML AttributeQuery]] sein.+    * 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]]?**
  • Zuletzt geändert: vor 3 Jahren