Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
en:requirements [2021/11/17 09:33] – Wolfgang Pempeen:requirements [2023/01/12 19:41] (current) – [Identity Provider] 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:registration|registration]]. The type of contractual agreement depends on the type of participation in the DFN-AAI:   * To participate in DFN-AAI, a contractual agreement with the DFN-Verein is required. To request the contract documents, see [[en:registration|registration]]. The type of contractual agreement depends on the type of participation in the DFN-AAI:
-    * Home Organisations / IdP operators: DFN-AAI is a value-added service ([[https://www.dfn.de/dienstleistungen/dfninternet/entgelte/|DFNInternet at least I02]]), DFN Framework Agreement and DFN-AAI Service Agreement are required. The latter also contains clauses covering SP operation.+    * Home Organisations / IdP operators: DFN-AAI is a value-added service which requires [[https://dfn.de/wp-content/uploads/2022/01/Entgeltordnung-DFNInternet-und-Dienst-Paket-2_0721.pdf|DFNInternet or the so-called 'Dienst-Paket']] plus the DFN Framework Agreement *and* the DFN-AAI Service Agreement. The latter also contains clauses covering SP operation.
     * 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://www.aai.dfn.de/verwaltung | Metadata Administration Tool]]   * Registration of the IdP/SP Metadata via our [[https://www.aai.dfn.de/verwaltung | Metadata Administration Tool]]
Line 29: Line 29:
  
 ==== Identity Provider ==== ==== Identity Provider ====
-  * 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.+  * The participant must have an operational Identity Management system (IdM) and Identity Provider (IdP) that at least meet [[de:aai:assurance_idp#erste_schritte_und_voraussetzungen|Conformance Criteria of the REFEDS Assurance Framework]]. 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) when transmitted 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
Line 47: Line 47:
   * 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 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 [[en:metadata|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'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**. Furthermore, an SP should be able to deal with two certificates/keys in parallel: During certificate rollover it will receive assertions that are encrypted either with the old/expiring certificate or with the new one.   * Since Shibboleth IdPs encrypt assertions by default, it is **strongly recommended** to use SP implementations that are able to **decrypt encrypted assertions**. Furthermore, an SP should be able to deal with two certificates/keys in parallel: During certificate rollover it will receive assertions that are encrypted either with the old/expiring certificate or with the new one.
  • Last modified: 3 years ago