| Both sides previous revision Previous revision Next revision | Previous revision |
| en:requirements [2021/05/03 19:59] – ↷ Links angepasst weil Seiten im Wiki verschoben wurden 40.77.167.40 | en:requirements [2023/01/12 19:41] (current) – [Identity Provider] Wolfgang Pempe |
|---|
| ===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. |
| * 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 |
| * 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. |