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:30] – [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. 
-  * [[en:metadata|Federation Metadata]] contain all necessary information for the communcation between an IdP and an SP, e.g. EntityIDs (the systems' identifiers), service endpoints, contact information and certificates.+  * [[en:metadata|Federation metadata]] contain all necessary information for the communcation between an IdP and an SP, e.g. EntityIDs (the systems' identifiers), service endpoints, contact information and certificates.
     * Federation metadata must be downloaded **at least** once a day.     * Federation metadata must be downloaded **at least** once a day.
     * The signature of the metadata must be validated against the currently valid certificate provided by DFN-AAI.      * The signature of the metadata must be validated against the currently valid certificate provided by DFN-AAI. 
   * 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 
-  * If a certificate with ''use="encryption"'' is stored in the Federation Metadata for an IdP, the IdP must be able to decrypt encrypted SAML messages of an SP (usually Logout Requests) using this certificate. +  * If a certificate with ''use="encryption"'' is stored in the federation metadata for an IdP, the IdP must be able to decrypt encrypted SAML messages of an SP (usually Logout Requests) using this certificate. 
  
 ==== Service Provider ==== ==== Service Provider ====
Line 44: Line 46:
   * A Service Provider working with more than one home institution must offer a way to select a home institution (**Discovery**).   * A Service Provider working with more than one home institution must offer a way to select a home institution (**Discovery**).
   * 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.
-  * IdPs transmit their data to the SP signed. This **XML signature** must be validated against the certificate stored in the Federation Metadata for the IdP in question. This applies both to the signed SAML Response and the SAML Assertion (part of the Response, signed on a case-by-case basis).   +  * IdPs transmit signed data to SPs. This **XML signature** must be validated against the certificate stored in the federation metadata for the IdP in question. This applies to both the signed SAML Response and the SAML Assertion (part of the Response, signed on a case-by-case basis).   
   * 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?**
   * Let's say you protected a resource that shall be used by //a single// university or research institute with an SP software. This SP will not join the big federation. You just want to connect it to //one// IdP.   * Let's say you protected a resource that shall be used by //a single// university or research institute with an SP software. This SP will not join the big federation. You just want to connect it to //one// IdP.
   * 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 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