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:22] – [General Requirements] Silke Meyer | en:requirements [2021/05/03 19:59] – ↷ Links angepasst weil Seiten im Wiki verschoben wurden 40.77.167.40 | ||
---|---|---|---|
Line 15: | Line 15: | ||
=== Technical and Organizational Criteria=== | === Technical and Organizational Criteria=== | ||
* Support of the [[https:// | * Support of the [[https:// | ||
- | * [[en: | + | * [[en: |
- | * must be downloaded **at least** once a day. | + | * Federation metadata |
- | * The signature of the metadata must be validated against the currently valid certificate provided by the 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/ | ||
Line 29: | Line 29: | ||
* 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 ==== | ||
<callout color="# | <callout color="# | ||
* With Web SSO, users only have //one// user identifier and //one// password - instead of one per service. | * With Web SSO, users only have //one// user identifier and //one// password - instead of one per service. | ||
- | * After //one// login with the IdP they are logged in to //all// services for a configurable amount of time (with their browser). | + | * After //one// login with the IdP their browser is logged in to //all// services for a configurable amount of time. |
* The central login page can be secured with state-of-the-art measures by IdP operators. | * The central login page can be secured with state-of-the-art measures by IdP operators. | ||
* Passwords are never transmitted to Service Providers. | * Passwords are never transmitted to Service Providers. | ||
Line 42: | Line 42: | ||
</ | </ | ||
- | * A Service Provider must offer a way to select a home institution (**Discovery**). | + | * A Service Provider |
- | * 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 provision | + | * The attributes required for the provisioning |
* 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 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' | * 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. |