| Both sides previous revision Previous revision Next revision | Previous revision Next revisionBoth sides next revision |
| en:requirements [2020/04/03 17:28] – Wolfgang Pempe | en:requirements [2020/04/03 17:42] – Wolfgang Pempe |
|---|
| * See the [[en:metadata_admin_tool:checklist|Checklist for Registering Metadata]] | * See the [[en:metadata_admin_tool:checklist|Checklist for Registering Metadata]] |
| === Technical and Organizational Criteria=== | === Technical and Organizational Criteria=== |
| * Support of [[https://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf|SAML 2 standard]] (in future alternatively OpenID Connect, date will be announced). The use of self-implementations is strongly discouraged. Instead, IdP/SP software should be used for which long-term support and further development by the community is guaranteed, e.g. [[https://www.shibboleth.net/products/|Shibboleth]] or [[https://simplesamlphp.org/|SimpleSAMLphp]]. DFN-Verein is a member of the [[https://www.shibboleth.net/|Shibboleth consortium]] and offers [[https://doku.tid.dfn.de/de:aai:portfolio|support, workshops and trainings]] for this software. | * Support of the [[https://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf|SAML 2 Standard]] (in future alternatively OpenID Connect, date will be announced). The use of self-implementations is strongly discouraged. Instead, IdP/SP software should be used for which long-term support and further development by the community is guaranteed, e.g. [[https://www.shibboleth.net/products/|Shibboleth]] or [[https://simplesamlphp.org/|SimpleSAMLphp]]. DFN-Verein is a member of the [[https://www.shibboleth.net/|Shibboleth Consortium]] and offers [[https://doku.tid.dfn.de/de:aai:portfolio|support, workshops and trainings]] for this software. |
| * [[en:metadata|Federation metadata]] | * [[en:metadata|Federation Metadata]] |
| * must be downloaded **at least** once a day | * must be downloaded **at least** once a day |
| * 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 the DFN-AAI |
| * Operating safety | * Operational Safety |
| * The software used must be kept up-to-date and security updates/patches must be applied in a timely manner | * The software implemented must be kept up-to-date and security updates/patches must be applied in a timely manner |
| * When [[en:metadata_admin_tool:checklist|registering the SP/IdP metadata]], a contact for security issues must be provided | * When [[en:metadata_admin_tool:checklist|registering the SP/IdP metadata]], a contact for security issues must be provided |
| * Certificates for SAML-based communication | * Certificates for SAML-based communication |
| * The SAML software used must allow uninterrupted key rollover when changing the key material. Information and further notes can be found under [[en:certificates#zertifikate_fuer_die_saml-basierte_kommunikation|certificates]]. | * The SAML software used must allow for seamless key rollover when changing the key material. Information and further notes can be found under [[en:certificates#zertifikate_fuer_die_saml-basierte_kommunikation|Certificates]]. |
| * Other | * Other |
| * Please follow the further steps listed under [[en:join|Joining the DFN-AAI Federation]]. | * Please follow the further steps listed under [[en:join|Joining the DFN-AAI Federation]]. |
| |
| ==== Identity Provider ==== | ==== Identity Provider ==== |
| * The participant must have a functioning identity management (system) that at least meets the requirements of [[en:degrees_of_reliance|the Degree of Reliance]] 'Basic'. User and groups for which these requirements are not met must be excluded from using the DFN-AAI. | * The participant must have an operational Identity Management system (IdM) that at least meets the requirements of [[en:degrees_of_reliance|the Degree of Reliance]] 'Basic'. User and groups for which these requirements are not met must be excluded from using the DFN-AAI. |
| * An Identity Provider **should** be able to produce the [[de:common_attributes|most important attributes]]. These attributes **must** be encoded in [[https://wiki.shibboleth.net/confluence/display/CONCEPT/SAMLAttributeNaming|standard-compliant encoding]]. (urn:oid) to Service Providers (if required for the provision of the respective service and permissible under data protection law) | * An Identity Provider **should** be able to produce the [[de:common_attributes|most important attributes]]. These attributes **must** be encoded in [[https://wiki.shibboleth.net/confluence/display/CONCEPT/SAMLAttributeNaming|standard-compliant encoding]] (urn:oid) when transmitted to Service Providers (if required for the provision of the respective service and permissible under data protection law) |
| * The signature of an Authentication Request sent by an SP must be validated against the corresponding certificate, which has been stored for this SP in the Federation Metadata | * The signature of an Authentication Request sent by an SP must be validated against the corresponding certificate, which has been stored for this SP in the Federation Metadata |
| * If a certificate with ''use="encryption"'' is stored in the Federation Metadata for an IdP, the IdP must be able to decrypt encrypted SAML messages of an SP (usually logout Requests) using this certificate. | * If a certificate with ''use="encryption"'' is stored in the Federation Metadata for an IdP, the IdP must be able to decrypt encrypted SAML messages of an SP (usually Logout Requests) using this certificate. |
| |
| ==== Service Provider ==== | ==== Service Provider ==== |
| * A Service Provider must be able to receive and process [[de:common_attributes|common attributes]] in [[https://wiki.shibboleth.net/confluence/display/CONCEPT/SAMLAttributeNaming|standard-compliant encoding]]. (urn:oid). | * A Service Provider must be able to receive and process [[de:common_attributes|common attributes]] in [[https://wiki.shibboleth.net/confluence/display/CONCEPT/SAMLAttributeNaming|standard-compliant encoding]]. (urn:oid). |
| * The attributes required for the use of the service must be declared in the Federation Metadata | * The attributes required for the provision of the service must be declared in the Federation Metadata |
| * 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 an institution can authenticate themselves via an IdP, but also every identity listed in the institution's IdM. These can also be guests, alumni or users of a city library, for instance. | * 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's IdM. These can also be guests, alumni or users of a city library, for instance. |
| * 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. |
| * The XML signature of data submitted by an IdP must be validated against the corresponding certificate stored in the Federation Metadata for the IdP in question. This applies both to the signed SAML Response and the SAML Assertion (part of the Response, signed on a case-by-case basis). | * The XML signature of data sent by an IdP must be validated against the corresponding certificate stored in the Federation Metadata for the IdP in question. This applies both to 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/deleting such local user accounts. These may include automatic deletion/deactivation of a user's account after a certain period of inactivity or deprovisioning via [[de:shibidp3userdepro|SAML Attribute Query]]. | * Appropriate procedures shall be implemented for deprovisioning/deleting such local user accounts. These may include automatic deletion/deactivation of a user's account after a certain period of inactivity or deprovisioning via [[de:shibidp3userdepro|SAML Attribute Query]]. |
| * Single Logout | * Single Logout |
| * Both IdP and SP implementations should support the [[http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf|Single Logout Profile]] | * Both IdP and SP implementations should support the [[http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf|Single Logout Profile]] |
| * If possible, the session of an application protected by an SP should be linked to the SP session. See about this at [[de:shibslo|Single Logout]]. | * If possible, the session of an application protected by an SP should be linked to the SP session. See about this under [[de:shibslo|Single Logout]]. |
| * In the sense of maximum, also international interoperability ([[de:edugain|eduGAIN]]) it is recommended to implement the current version of the [[https://kantarainitiative.github.io/SAMLprofiles/saml2int.html|SAML2 Interoperability Profile (saml2int)]] in the best possible way. For deviating, DFN-AAI-specific certificate policies,please refer to [[en:certificates#zertifikate_fuer_die_saml-basierte_kommunikation|Certificates]]. | * In the sense of maximum, also international interoperability ([[de:edugain|eduGAIN]]) it is recommended to implement the current version of the [[https://kantarainitiative.github.io/SAMLprofiles/saml2int.html|SAML2 Interoperability Profile (saml2int)]] in the best possible way. For deviating, DFN-AAI-specific certificate policies, please refer to [[en:certificates#zertifikate_fuer_die_saml-basierte_kommunikation|Certificates]]. |
| |