Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revisionLast revisionBoth sides next revision | ||
en:requirements [2021/03/02 15:27] – [Service Provider] Silke Meyer | en:requirements [2022/09/26 11:21] – 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: | * To participate in DFN-AAI, a contractual agreement with the DFN-Verein is required. To request the contract documents, see [[en: | ||
- | * Home Organisations / IdP operators: DFN-AAI is a value-added service | + | * Home Organisations / IdP operators: DFN-AAI is a value-added service |
* 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:// | * Registration of the IdP/SP Metadata via our [[https:// | ||
- | * See the [[en: | + | * See the [[en: |
=== Technical and Organizational Criteria=== | === Technical and Organizational Criteria=== | ||
* Support of the [[https:// | * Support of the [[https:// | ||
Line 20: | Line 20: | ||
* Operational Safety | * Operational Safety | ||
* The software implemented must be kept up-to-date and security updates/ | * The software implemented must be kept up-to-date and security updates/ | ||
- | * When [[en: | + | * When [[en: |
* 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: | * The SAML software used must allow for seamless key rollover when changing the key material. Information and further notes can be found under [[en: | ||
+ | * 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: | * Please follow the further steps listed under [[en: | ||
Line 45: | Line 47: | ||
* A Service Provider must be able to receive and process **[[de: | * A Service Provider must be able to receive and process **[[de: | ||
* 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 |
* 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' | * 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' | ||
* Since Shibboleth IdPs encrypt assertions by default, it is **strongly recommended** to use SP implementations that are able to **decrypt encrypted assertions**. Furthermore, | * Since Shibboleth IdPs encrypt assertions by default, it is **strongly recommended** to use SP implementations that are able to **decrypt encrypted assertions**. Furthermore, | ||
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/ | + | * Appropriate procedures shall be implemented for **deprovisioning/ |
**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/ | * 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/ | ||
- | * Local metadata are configurable via DFN-AAI' | + | * Local metadata are configurable via DFN-AAI' |
* The local metadata file gets 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. |