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 09:09] – [Service Provider] Silke Meyer | en:requirements [2021/11/17 09:33] – Wolfgang Pempe | ||
---|---|---|---|
Line 5: | Line 5: | ||
==== General Requirements ==== | ==== General Requirements ==== | ||
<callout color="# | <callout color="# | ||
- | The following formal, technical and organizational criteria apply equally to Identity Providers (IdP) and Service Providers (SP) | + | The following formal, technical and organizational criteria apply equally to Identity Providers (IdP) and Service Providers (SP). |
</ | </ | ||
===Formal Criteria=== | ===Formal Criteria=== | ||
- | * To participate in the 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 ([[https:// | * Home Organisations / IdP operators: DFN-AAI is a value-added service ([[https:// | ||
* 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: |
- | * 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/ | ||
- | * 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 ==== | ||
<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 44: | ||
</ | </ | ||
- | * 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. | + | * Since Shibboleth IdPs encrypt assertions by default, it is **strongly recommended** to use SP implementations that are able to **decrypt encrypted assertions**. Furthermore, |
- | * The XML signature | + | * IdPs transmit signed data to SPs. This **XML signature** must be validated against the certificate stored in the federation metadata |
* 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 |
- | * Appropriate procedures shall be implemented for deprovisioning/ | + | * Appropriate procedures shall be implemented for **deprovisioning/ |
+ | **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. | ||
+ | * 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/ | ||
+ | * 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. | ||
+ | * 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. | ||
===== Best Practice Recommendations ==== | ===== Best Practice Recommendations ==== | ||
* Single Logout | * Single Logout |