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/03/02 10:37] – [Service Provider] Silke Meyeren:requirements [2023/01/12 19:41] (current) – [Identity Provider] Wolfgang Pempe
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, no further requirements
   * 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:metadata_admin_tool:checklist|Checklist for Registering Metadata]]+    * See the [[en:checklist|Checklist for Registering Metadata]]
 === Technical and Organizational Criteria===  === Technical and Organizational Criteria=== 
   * Support of the [[https://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf|SAML 2 Standard]] (in future alternatively OpenID Connect, date will be announced). The use of self-implementations is strongly discouraged. Instead, IdP/SP software should be used for which long-term support and further development by the community is guaranteed, e.g. [[https://www.shibboleth.net/products/|Shibboleth]] or [[https://simplesamlphp.org/|SimpleSAMLphp]]. DFN-Verein is a member of the [[https://www.shibboleth.net/|Shibboleth Consortium]] and offers [[https://doku.tid.dfn.de/de:aai:portfolio|support, workshops and trainings]] for this software.    * Support of the [[https://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf|SAML 2 Standard]] (in future alternatively OpenID Connect, date will be announced). The use of self-implementations is strongly discouraged. Instead, IdP/SP software should be used for which long-term support and further development by the community is guaranteed, e.g. [[https://www.shibboleth.net/products/|Shibboleth]] or [[https://simplesamlphp.org/|SimpleSAMLphp]]. DFN-Verein is a member of the [[https://www.shibboleth.net/|Shibboleth Consortium]] and offers [[https://doku.tid.dfn.de/de:aai:portfolio|support, workshops and trainings]] for this software. 
Line 20: Line 20:
   * Operational Safety   * Operational Safety
     * The software implemented must be kept up-to-date and security updates/patches must be applied in a timely manner.     * The software implemented must be kept up-to-date and security updates/patches must be applied in a timely manner.
-    * When [[en:metadata_admin_tool:checklist|registering the SP/IdP metadata]], a contact for security issues must be provided. +    * When [[en:checklist|registering the SP/IdP metadata]], a contact for security issues must be provided. 
   * 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.
Line 51: Line 53:
   * Provisioning and Deprovisioning    * Provisioning and Deprovisioning 
     * Local, i.e. SP-side **user accounts and profiles** must be created using attributes transmitted by the Identity Providers of the participating Home Organisations. Provisioning of user data via other channels (e.g. CSV files, Active Directory) is not permitted.     * Local, i.e. SP-side **user accounts and profiles** must be created using attributes transmitted by the Identity Providers of the participating Home Organisations. Provisioning of user data via other channels (e.g. CSV files, Active Directory) is not permitted.
-    * Appropriate procedures shall be implemented for **deprovisioning/deleting** such local user accounts. These may include automatic deletion/deactivation of a user's account after a certain period of inactivity or deprovisioning via [[de:shibidp3userdepro|SAML Attribute Query]].+    * Appropriate procedures shall be implemented for **deprovisioning/deleting** such local user accounts. These may include automatic deletion/deactivation of a user's account after a certain period of inactivity or deprovisioning via [[de:shibidp:config-deprovisionierung|SAML Attribute Query]].
  
 **Why do IdP operators talk about local metadata?** **Why do IdP operators talk about local metadata?**
Line 57: Line 59:
   * Technically it is possible to feed the IdP the single extra xml metadata file of an SP and vice versa.   * Technically it is possible to feed the IdP the single extra xml metadata file of an SP and vice versa.
   * It is much more comfortable though to use a **common dynamic metadata file**. This is exactly the use case for local metadata - to introduce an IdP to all local/internal services:   * It is much more comfortable though to use a **common dynamic metadata file**. This is exactly the use case for local metadata - to introduce an IdP to all local/internal services:
-    * Local metadata are configurable via DFN-AAI's metadata administration tool. It always contains the IdP and all in-house SPs that were added. +    * Local metadata are configurable via DFN-AAI's metadata administration tool ([[en:metadata_local |documentation]]). It always contains the IdP and all in-house SPs that were added. 
-    * The local metadata file get generated per institution and can be fetched regularly by IdPs and SPs just like federation metadata.+    * The local metadata file gets generated per institution and can be fetched regularly by IdPs and SPs just like federation metadata.
     * Metadata admins can update the metadata of the participating entities in one place. If a new IdP certificate is added to the IdP's metadata all SPs in all federations (DFN-AAI, local, international) will get the new certificate within a few hours. SP operators can make their new certificates known the same way - no need to edit or send xml files.     * Metadata admins can update the metadata of the participating entities in one place. If a new IdP certificate is added to the IdP's metadata all SPs in all federations (DFN-AAI, local, international) will get the new certificate within a few hours. SP operators can make their new certificates known the same way - no need to edit or send xml files.
     * The expiration dates of all certificates in local metadata are monitored by us. The technical contacts and the metadata admins get a reminder for certificate rollover. We cannot offer this service for systems that were connected outside the metadata administration tool.     * The expiration dates of all certificates in local metadata are monitored by us. The technical contacts and the metadata admins get a reminder for certificate rollover. We cannot offer this service for systems that were connected outside the metadata administration tool.
  • Last modified: 3 years ago