General Requirements

  • MUST apply privacy by design and privacy by default principle as expressed in art. 25 GDPR [GDPR-ART-25].
  • MUST not require manual creation of user accounts on the service side.
  • MUST NOT require manual management of access rights on the service side. 
  • MUST provide contact information of the following types:
    • Technical and/or Helpdesk/Support contact information 
    • Security/incident response
  • MUST have a logo recognisable by the end users. The logo SHALL:
    • use a transparent background where appropriate to facilitate the usage of logos within a user interface
    • use PNG, or GIF (less preferred), images
    • use HTTPS URLs in order to avoid mixed-content warnings within browsers
    • have a size smaller than 50000 characters when encoded in base64
  • SHOULD create local account mappings  just-in-time, when the user first interacts with the service using the user information provided by the GEANT AAI Service. In the case that the service requires the local accounts and mappings to be pre-provisioned, then it must provide a documented API, which can be used for the provisioning of the accounts.
  • Access management should be performed based on the groups and roles made available by the GEANT AAI Service.  In the case that the service requires the access management to happen on the service side, then it must provide a documented API, which can be used to manage the access rights of the users.
  • Users must be identified using one of the User Identifier claims described in [GN-Attrs-UserID] 

For SAML Service Providers

SAML Service Providers:

  • MUST comply with the SAML WebSSO profile:  [SAML-Profile-2.0] 
  • MUST comply with [SAML2int], namely section 2 “Common Requirements” and section 3 “Service Provider Requirements” and the recommendations for upstream metadata produced by eduGAIN participants [eduGAIN-Metadata-Recommendations].
  • MUST use entityID attributes that are absolute URIs using one of the http, https or urn schemes.
    • https-scheme URIs are RECOMMENDED for all entities.
    • http-scheme and https-scheme URIs used for entityID values MUST contain a host part whose value is a DNS domain.
  • MUST be able to use attributes from the latest version of the eduPerson Schema [REFEDS-eduPerson]
  • MUST be able to use attributes from the latest version of the SCHAC Schema [REFEDS-Schac]
  • MUST be able to use attributes from the latest version of the voPerson Schema [REFEDS-voPerson]
  • MUST support the attributes that the GÉANT AAI Service is making available to relying parties [GN-Attrs]
  • MUST identify users using one of the User Identifier attributes described in [GN-Attrs-UserID]
  • MUST NOT validate the SAML scope of scoped attribute values released by the GEANT AAI Service.
  • MUST support the REFEDS Assurance Framework [RAF], if they require to evaluate user assurance levels
  • MUST support [REFEDS-MFA], if they require to signal the requirement for multi-factor authentication (MFA)

For OpenID Connect (OIDC) Clients

OIDC clients:

  • MUST support for OpenID Connect Core 1.0 [OIDC-Core]
  • MUST support retrieving the Identity Provider’s configuration based on the Issuer information using the OIDC-Discovery specification [OIDC-Discovery]
  • MUST support the relevant scopes and claims that the GÉANT AAI Service is making available  [GN-Attrs] 
  • MUST identify users using one of the User Identifier claims described in [GN-Attrs-UserID].
  • Grant access rights and authorise users based on the group and role information made available to the service from the GEANT AAI Service during the authentication of the user using the Group attribute: [GN-Attrs-Groups]
  • utilising the authorization grant type SHOULD use PKCE [RFC7636] in conjunction with the authorisation server in order to detect and prevent attempts to inject (replay) authorisation codes into the authorisation response. The PKCE challenges must be transaction-specific and securely bound to the user agent in which the transaction was started. OpenID Connect relying parties MAY use the "nonce" parameter of the OpenID Connect authentication request as specified in [OIDC-Core] in conjunction with the corresponding ID Token claim for the same purpose.
  • SHALL NOT use the implicit grant and any other response type causing the authorization server to issue an access token in the authorization response.
  • MUST comply with one or more of the relevant security configurations described in [GN-OIDC-Client-Conf-Options]
  • MUST support requesting Claims about the End-User and the Authentication event using specific scope values as described in [OIDC-Core]. Claims which are not part of the standard set of claims defined in [OIDC-Core] SHOULD be requested following the mapping recommendations described in [GN-Attrs]
  • MUST provide one or more Redirection URI to which authentication responses from the GEANT AAI Service will be sent. The GEANT AAI Service utilises exact matching of the redirect URI specified in an authentication request against the Redirection URIs [OAuth2-BCP], with the matching performed as described in [RFC3986] (Simple String Comparison). Redirection URIs MUST use the schemata defined in Section 3.1.2.1 of the [OIDC-Core] specification.
  • MUST support the REFEDS Assurance Framework [RAF], if they require to evaluate user assurance levels
  • MUST support [REFEDS-MFA], if they require to signal the requirement for multi-factor authentication (MFA)