Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
en:requirements [2021/07/20 10:01] – updated link to check list Silke Meyeren:requirements [2026/10/07 12:01] (current) – Wolfgang Pempe
Line 1: Line 1:
 ~~NOTOC~~ ~~NOTOC~~
 ====== Requirements and Best Practices ==========  ====== Requirements and Best Practices ========== 
-{{INLINETOC 2}}+
 ===== Requirements for Participation in the DFN-AAI ===== ===== Requirements for Participation in the DFN-AAI =====
 ==== General Requirements ==== ==== General Requirements ====
Line 9: Line 9:
 ===Formal Criteria=== ===Formal Criteria===
   * To participate in DFN-AAI, a contractual agreement with the DFN-Verein is required. To request the contract documents, see [[en:registration|registration]]. The type of contractual agreement depends on the type of participation in the DFN-AAI:   * To participate in DFN-AAI, a contractual agreement with the DFN-Verein is required. To request the contract documents, see [[en:registration|registration]]. The type of contractual agreement depends on the type of participation in the DFN-AAI:
-    * Home Organisations / IdP operators: DFN-AAI is a value-added service ([[https://www.dfn.de/dienstleistungen/dfninternet/entgelte/|DFNInternet at least I02]]), DFN Framework Agreement and DFN-AAI Service Agreement are required. The latter also contains clauses covering SP operation. +    * **Home Organisations / IdP operators:** DFN-AAI is a value-added service which requires [[https://dfn.de/wp-content/uploads/2022/01/Entgeltordnung-DFNInternet-und-Dienst-Paket-2_0721.pdf|DFNInternet or the so-called 'Dienst-Paket']] plus the DFN Framework Agreement *and* the DFN-AAI Service Agreement. The latter also contains clauses covering SP operation. 
-    * Service Provider / SP operator: SP agreement (English) - free of charge, no further requirements+    * **Service Provider / SP operator:** SP agreement (English) - free of charge. The service in question must be relevant to Home Organisations participating in the DFN-AAI and must, at least in the medium term, be used by more than one Home Organisation. Otherwise, the Service Provider may be registered in the local metadata (see below) of the relevant Home Organisation without a contractual agreement with the DFN-Verein. Any exceptions to this must be agreed upon by mutual consent.
   * Registration of the IdP/SP Metadata via our [[https://www.aai.dfn.de/verwaltung | Metadata Administration Tool]]   * Registration of the IdP/SP Metadata via our [[https://www.aai.dfn.de/verwaltung | Metadata Administration Tool]]
     * See the [[en:checklist|Checklist for Registering Metadata]]     * See the [[en:checklist|Checklist for Registering Metadata]]
Line 23: Line 23:
   * Certificates for SAML-based communication   * Certificates for SAML-based communication
     * The SAML software used must allow for seamless key rollover when changing the key material. Information and further notes can be found under [[en:certificates#certificates_for_saml-based_communication|Certificates]].     * The SAML software used must allow for seamless key rollover when changing the key material. Information and further notes can be found under [[en:certificates#certificates_for_saml-based_communication|Certificates]].
 +  * https for Binding URLs
 +    * All endpoints registered in the federation metadata must be secured via TLS
   * Other   * Other
     * Please follow the further steps listed under [[en:join|Joining the DFN-AAI Federation]].     * Please follow the further steps listed under [[en:join|Joining the DFN-AAI Federation]].
  
 ==== Identity Provider ==== ==== Identity Provider ====
-  * The participant must have an operational Identity Management system (IdM) that at least meets the requirements of [[en:degrees_of_reliance|the Degree of Reliance]] 'Basic'. User and groups for which these requirements are not met must be excluded from using the DFN-AAI.+  * The participant must have an operational Identity Management system (IdM) and Identity Provider (IdP) that at least meet [[de:aai:assurance_idp#erste_schritte_und_voraussetzungen|Conformance Criteria of the REFEDS Assurance Framework]]. User and groups for which these requirements are not met must be excluded from using the DFN-AAI.
   * An Identity Provider **should** be able to produce the [[de:common_attributes|most important attributes]]. These attributes **must** be encoded in [[https://wiki.shibboleth.net/confluence/display/CONCEPT/SAMLAttributeNaming|standard-compliant encoding]] (urn:oid) when transmitted to Service Providers (if required  for the provision of the respective service and permissible under data protection law)   * An Identity Provider **should** be able to produce the [[de:common_attributes|most important attributes]]. These attributes **must** be encoded in [[https://wiki.shibboleth.net/confluence/display/CONCEPT/SAMLAttributeNaming|standard-compliant encoding]] (urn:oid) when transmitted to Service Providers (if required  for the provision of the respective service and permissible under data protection law)
   * The signature of an Authentication Request sent by an SP must be validated against the corresponding certificate, which has been stored for this SP in the federation metadata   * The signature of an Authentication Request sent by an SP must be validated against the corresponding certificate, which has been stored for this SP in the federation metadata
Line 45: Line 47:
   * A Service Provider must be able to receive and process **[[de:common_attributes|common attributes]] in [[https://wiki.shibboleth.net/confluence/display/CONCEPT/SAMLAttributeNaming|standard-compliant encoding]]** (urn:oid).   * A Service Provider must be able to receive and process **[[de:common_attributes|common attributes]] in [[https://wiki.shibboleth.net/confluence/display/CONCEPT/SAMLAttributeNaming|standard-compliant encoding]]** (urn:oid).
   * The attributes required for the provisioning of the service must be **declared in the federation metadata**.   * The attributes required for the provisioning of the service must be **declared in the federation metadata**.
-  * A Service Provider must be able to **download federation metadata regularly** and filter their content per EntityID.+  * A Service Provider must be able to **download [[en:metadata|federation metadata]] regularly** and filter their content per EntityID.
   * A Service Provider must be able to implement attribute-based authorization unless all identities available via an IdP are allowed to access the resources in question. It should be noted that usually not only members of a Home Organisation can authenticate themselves via an IdP, but also every identity listed in this institution's IdM. These can also be guests, alumni or users of a city library, for instance.     * A Service Provider must be able to implement attribute-based authorization unless all identities available via an IdP are allowed to access the resources in question. It should be noted that usually not only members of a Home Organisation can authenticate themselves via an IdP, but also every identity listed in this institution's IdM. These can also be guests, alumni or users of a city library, for instance.  
   * Since Shibboleth IdPs encrypt assertions by default, it is **strongly recommended** to use SP implementations that are able to **decrypt encrypted assertions**. Furthermore, an SP should be able to deal with two certificates/keys in parallel: During certificate rollover it will receive assertions that are encrypted either with the old/expiring certificate or with the new one.   * Since Shibboleth IdPs encrypt assertions by default, it is **strongly recommended** to use SP implementations that are able to **decrypt encrypted assertions**. Furthermore, an SP should be able to deal with two certificates/keys in parallel: During certificate rollover it will receive assertions that are encrypted either with the old/expiring certificate or with the new one.
  • Last modified: 5 years ago