Voraussetzungen und Best Practices

Die folgenden Voraussetzungen gelten gleichermaßen für Identity Provider (IdP) und Service Provider (SP)

• Zur Teilnahme an der DFN-AAI ist eine vertragliche Vereinbarung mit dem DFN-Verein erforderlich. Zur Anforderung der Vertragsunterlagen siehe unter 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 (DFNInternet ab I02), erforderlich sind Rahmenvertrag und Dienstvereinbarung. Letztere enthält auch Vereinbarungen für den SP-Betrieb.
  • Dienstanbieter / SP-Betreiber: SP-Agreement (englisch) – keine sonstigen Voraussetzungen
• Registrierung der IdP-/SP-Metadaten
  • Siehe hierzu die Checkliste zur Registrierung der Metadaten

• Unterstützung des 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. Shibboleth oder SimpleSAMLphp. Der DFN-Verein ist Mitglied im Shibboleth-Konsortium und bietet für diese Software Support, Workshops und Schulungen an.
• Föderationsmetadaten
  • müssen mindestens einmal täglich heruntergeladen werden
  • die Signatur der Metadaten muss anhand des jeweils gültigen, von der DFN-AAI bereitgestellten Zertifikats validiert werden
• Betriebssicherheit
  • Die eingesetzte Software muss aktuell gehalten und Security Updates/Patches zeitnah eingespielt werden
  • Bei der Registrierung der Metadaten muss ein Kontakt für Sicherheitsfragen angegeben werden
• 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 Zertifikate
• Sonstiges
  • Orientieren Sie sich bitte an den weiteren, unter Teilnahme aufgelisteten Schritten

• Der Teilnehmer muss über ein funktionierendes Identity Management (System) verfügen, das mindestens die Anforderungen der Verlässlichkeitsklasse 'Basic' erfüllt.
• Ein Identity Provider sollte in der Lage sein, die wichtigsten Attribute zu produzieren. Diese Attribute müssen in 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
• 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.

• Ein Service Provider muss in der Lage sein, gängige Attribute in standardkonformem Encoding (urn:oid) zu empfangen und zu verarbeiten.
• 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, 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.
• Die XML-Signatur der seitens eines IdP übermittelten Daten muss anhand des entsprechenden, für den betreffenden IdP in den Föderationsmetadaten hinterlegten Zertifikats validiert werden. Dies betrifft sowohl die signierte SAML Response als auch die SAML Assertion (Teil der Response, fallweise signiert).
• 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
  • 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 SAML AttributeQuery sein.

• Im Sinne einer maximalen, auch internationalen Interoperabilität (eduGAIN) wird empfohlen, die aktuelle Fassung des SAML2 Interoperability Profile (saml2int) bestmöglich umzusetzen. Zu den davon abweichenden, in der DFN-AAI gültigen Zertifikatregeln siehe unter Zertifikate.