* 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.
