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:30] – [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:// | ||
- | * [[en: | + | * [[en: |
* 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/ | * 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 29: | Line 31: | ||
* The participant must have an operational Identity Management system (IdM) that at least meets the requirements of [[en: | * The participant must have an operational Identity Management system (IdM) that at least meets the requirements of [[en: | ||
* An Identity Provider **should** be able to produce the [[de: | * An Identity Provider **should** be able to produce the [[de: | ||
- | * The signature of an Authentication Request sent by an SP must be validated against the corresponding certificate, | + | * The signature of an Authentication Request sent by an SP must be validated against the corresponding certificate, |
- | * If a certificate with '' | + | * If a certificate with '' |
==== 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: | * 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 | + | * IdPs transmit |
* 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. |