Differences

This shows you the differences between two versions of the page.

--- en:checklist [2022/04/05 13:23] – started to revise content Silke Meyer
+++ en:checklist [2022/04/05 15:11] – [Federations] translation complete Silke Meyer
@@ Line 47: / Line 47: @@
   * Favicons should have a size of 16 x 16 px.
   * A transparent background is recommended.
-  *
 Also see the recommendations in the [[https://shibboleth.atlassian.net/wiki/spaces/SHIB2/pages/2578448519/IdPMDUIRecommendations|Shibboleth Wiki]].
+===== Help Desk =====
+Contact information of your user help desk for the public DFN-AAI directory (e.g. e-mail address, phone number).
-  * Please submit at least four **contacts** per system: An administrative contact, a technical one, a support contact and a security contact. We recommend to use non-personalized email addresses, especially for the security contact which could be your Computer Emergency Response Team. If you do not have anything like that, put in the contact that responds in case of security incidents. Please make sure to keep those email addresses up to date!
+===== Entity Category =====
-  * Have your X.509 **certificate** for SAML-based communication ready. We have an [[en:certificates|information page about certificates]]. The most important items are:
+For Entity Categories resp. Entity Attributes please see our [[en:entity_attributes|Documentation]].
-    * IdPs use DFN-PKI certificates. As of July 2019, only the **second generation of DFN-PKI certificates** will be valid.
-    * SPs can use DFN-PKI certificates (if entitled), certificates issued by established commercial CAs, or self-signed certificates.
+===== Entity Category Support =====
-    * SSL certificates must not exceed a **validity of 39 months**.
+Entity Attribute for an IdP to announce that it transmits all attributes defined in a certain Entity Category to all SPs using that Entity Category.
-    * For security reasons, we do no longer accept certificates that were created with a sha1 **signature algorithm**. Here is how you can check this, e.g. with openssl:
-<code>
+===== Contacts =====
-openssl x509 -in example.org.crt.pem -noout -text | grep "Signature Algorithm" | uniq
+Each entity's metadata should provide contact information for the following roles. If possible, it should not be personal e-mail addresses.
-</code>
+  * administrative: contact information for administrative issues
+  * technical: contact information concerning the operation of the service
+  * support: contact information for end users
+  * security: contact information for security incidents.
+Also see [[https://wiki.refeds.org/display/SIRTFI/Choosing+a+Sirtfi+Contact|Choosing a Sirtfi Contact]].
+===== Scope =====
+Scope of the IdP, mostly the domain of the organization. The organization has to be entitled to use the domain(s). SPs match the transmitted ‚scoped‘ attributes (e.g. eduPersonScopedAffiliation) against this string. See the [[en:normative_documents|Metadata Registration Practice Statement]] for details.
+===== Request Initiator =====
+Service Provider URL that initializes a login process.
+===== Discovery Response =====
+Service Provider URL the initializes IdP discovery.
+===== Certificates =====
+Enter the certificates used to sign resp. encrypt the SAML communication (in pem format). Check the certificate details before hitting the save button. Also see the [[en:certificates|detailed information about certificates]], certificate rollover, and certificate chains.
-  * For Service Providers: If you need your SP to execute **Attribute Queries or Artifact Queries**, your SP certificate should have the client attribute set. If you request your certificate from DFN-PKI, please use the template called "Shibboleth IdP/-SP". If you do not use DFN-PKI certificates, have a look at [[https://www.switch.ch/aai/support/certificates/embeddedcerts-requirements-appendix-a/|our Swiss colleagues' documentation]]. If you do not need any Attribute/Artifact Queries, please deactivate the feature in your SP. With a Shibboleth SP you'd have to remove the element <AttributeResolver type="Query"> and to restart shibd. Moreover, you should remove the Binding URL for Artifact Resolution Services and all SOAP Bindings (Logout). Here is how you check if your certificate has the client attribute set with openssl:
+For Service Providers (optional): If you need your SP to execute **Attribute Queries or Artifact Queries**, your SP certificate should have the client attribute set. If you request your certificate from DFN-PKI, please use the template called "Shibboleth IdP/-SP". If you do not use DFN-PKI certificates, have a look at [[https://www.switch.ch/aai/support/certificates/embeddedcerts-requirements-appendix-a/|our Swiss colleagues' documentation]]. If you do not need any Attribute/Artifact Queries, please deactivate the feature in your SP. With a Shibboleth SP you'd have to remove the element <AttributeResolver type="Query"> and to restart shibd. Moreover, you should remove the Binding URL for Artifact Resolution Services and all SOAP Bindings (Logout). Here is how you check if your certificate has the client attribute set with openssl:
 <code>
 openssl x509 -in example.org.crt.pem -noout -text | grep -A 1 "X509v3 Extended Key Usage"
@@ Line 67: / Line 85: @@
                 TLS Web Client Authentication, TLS Web Server Authentication
 </code>
-  * This is what end points for **Assertion Consumer Services** look like for Shibboleth SPs:<code>Location: https://example.org:8443/Shibboleth.sso/SAML2/POST
+===== Single Logout Services =====
+IdPs and SPs supporting Single Logout Requests have to publish the respective endpoints here.
+Example for Shibboleth IdPs:<code>https://idp.example.org/idp/profile/SAML2/Redirect/SLO
+urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
+https://idp.example.org/idp/profile/SAML2/POST/SLO
+urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
+https://idp.example.org/idp/profile/SAML2/POST-SimpleSign/SLO
+urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign
+https://idp.example.org:8443/idp/profile/SAML2/SOAP/SLO
+urn:oasis:names:tc:SAML:2.0:bindings:SOAP</code>
+Example for Shibboleth SPs:<code>https://sp.example.org/Shibboleth.sso/SLO/SOAP
+urn:oasis:names:tc:SAML:2.0:bindings:SOAP
+https://sp.example.org/Shibboleth.sso/SLO/Redirect
+urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
+https://sp.example.org/Shibboleth.sso/SLO/POST
+urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
+https://sp.example.org/Shibboleth.sso/SLO/Artifact
+urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact</code>
+===== Assertion Consumer Services =====
+Endpoints of an SPs Assertion Consumer Service. Examples:<code>Location: https://example.org:8443/Shibboleth.sso/SAML2/POST
 Binding: urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
 Index: 1</code><code>Location: https://example.org:8443/Shibboleth.sso/SAML2/POST-SimpleSign
@@ Line 76: / Line 124: @@
 Binding: urn:oasis:names:tc:SAML:2.0:bindings:PAOS
 Index: 4</code>
+===== Attribute Consuming Service =====
+List of attributes the SP takes.
+===== Artifact Resolution Services =====
+Example:<code>Location: https://idp.example.org:8443/idp/profile/SAML2/SOAP/ArtifactResolution
+Binding: urn:oasis:names:tc:SAML:2.0:bindings:SOAP
+Index: 1</code>
+===== Single Sign On Services =====
+Single Sign On end points of an IdP. Examples:<code>Location: https://idp.example.org/idp/profile/SAML2/POST/SSO
+Binding: urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
+Location: https://idp.example.org/idp/profile/SAML2/POST-Simple-Sign/SSO
+Binding: urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-Simple-Sign
+Location: https://idp.example.org/idp/profile/SAML2/Redirect/SSO
+Binding: urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect</code>
+===== Attribute Services =====
+IdP end points for Attribute Query via SOAP Requests. Example:<code>
+Location: https://idp.example.org:8443/idp/profile/SAML2/SOAP/AttributeQuery
+Binding: urn:oasis:names:tc:SAML:2.0:bindings:SOAP</code>
+===== NameID Formats =====
+Supported NameID formats. At least ''urn:oasis:names:tc:SAML:2.0:nameid-format:transient'' should be selected. It is active in default installations and is needed for logout to work. Other formats should only be selected if they were explicitly activated in the configuration.
+===== Federations =====
+Here you add your IdP/SP to federations.
+If you submit your provider to DFN-AAI-Test or to local metadata, it is automatically added to the according metadata. Submissions for DFN-AAI and DFN-AAI-Basic are first checked by the DFN-AAI team. Admission is granted within a working day, unless the metadata form displays errors. Please fix these errors first! You can only add your IdP/SP to the international federation eduGAIN after it has been accepted to either DFN-AAI or DFN-AAI-Basic. You can find our policies in the [[en:join|documentation]]
+Information regarding the Degrees of Reliance:
+IdP:
+  * Depending on the criteria your IdP fulfills add it to either DFN-AAI or DFN-AAI-Basic.
+  * In addition, an IdP can be registered in DFN-AAI-Test and in local metadata. Keeping a productive IdP in the test federation is not recommended.
+  *
+SP:
+  * Choose the degree of reliance that an IdP (!) must fulfill to grant access to their users. In DFN-AAI only users of the 'Advanced' degree of reliance can access the SP. In DFN-AAI-Basic the users of all IdPs in the federation can access it.
+  * Additionally, the SP can be registered in DFN-AAI-Test. A productive SP should not be in the test federation to prevent logins from test IdPs.
+  * Local metadata can only be selected if neither DFN-AAI nor DFN-AAI-Basic is selected. The option is available for organizations that have signed an IdP contract with us and have registered at least an IdP.
   * Put your new system into our **test federation** DFN-AAI-Test. Use our [[en:functionaltest|public test systems]] to check if the transfer of attributes works correctly.
 {{:en:metadata_admin_tool:test-en.png?600|}}

needs-update