Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Next revisionBoth sides next revision | ||
en:requirements [2021/03/02 10:34] – [Service Provider] Silke Meyer | en:requirements [2022/09/26 11:20] – 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, | ||
- | * 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 | + | * 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/ | + | * Appropriate procedures shall be implemented for **deprovisioning/ |
**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/ | + | * 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 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. |