Scope

The EOSC Core Infrastructure Proxy is connecting the EOSC Core and EOSC Support Services to the EOSC Federated AAI.

Requirements

Eligibility

Services that are eligible for connecting to the EOSC Core Infrastructure Proxy are:

  • EOSC Core Services operated in the context of the EOSC-Future project. 
  • EOSC Support Services operated in the context of the EOSC-Future project
  • EOSC Support Services operated by the EOSC Secretariat and/or the EOSC Association

Technical and Policy

Each service is required to provide the following information:

  • Service name (in English and optionally in other languages supported by the entity)
  • Service description
  • Website URL for information about the service; the content found at the URL SHOULD provide more complete information than what is provided in the description
  • Information about the organization (Service Owner) information including:
    • Name of the organisation
    • Display name of the organisation used for user-facing interfaces
    • Website URL for information about the organisation
  • Organization contact information of the following types:
    • Technical and/or Helpdesk/Support contact information (for redirecting users)
    • Security/incident response (see also Sirtfi)
    • Administrative (optional)
  • Service contact information of the following types: (if different from the organisation’s contact information)
    • Technical and/or Helpdesk/Support contact information (for redirecting users)
    • Security/incident response (see also Sirtfi)
    • Administrative (optional)
  • Whether a Logo URL is provided (for showing in catalogues); if provided, logos SHOULD:
    • 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
  • Link to the privacy policy
  • Link to the Acceptable Use Policy / Terms of Use based on the WISE AUP Baseline template [WISE-Baseline-AUP]
  • The entity is compliant with the GEANT Code of Conduct version 1 [GEANT-DPCoCo] or any other code of conduct compatible with legislation and guidelines on data protection and privacy including GDPR
  • Whether the service is compliant with the REFEDS Research & Scholarship Entity Category [REFEDS-R&S]
  • The service adheres to the EOSC Security Baseline [EOSC-SecOps-Base]
  • The federated protocol(s) the service is supporting
  • Other technical information related to the supported federated protocol(s)

SAML entity technical requirements

Service Providers supporting the SAML protocol MUST comply with the SAML2int SAML 2.0 Interoperability Deployment Profile [SAML2int].

Metadata

Service Providers supporting the SAML protocol MUST provide a SAML 2.0 Metadata document representing its entity according to the SAML2int SAML 2.0 Interoperability Deployment Profile [SAML2int] and the recommendations for upstream metadata produced by eduGAIN participants [eduGAIN-Metadata-Recommendations].

Entity Identifier Format 

For Service Providers supporting the SAML protocol, the entity identifier is the SAML entityID attribute. Values of the entityID attribute registered MUST be an absolute URI using 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. 

Scope Format

Service Providers supporting the SAML protocol MUST NOT validate the scope of scoped attribute values released by the EOSC Core Infrastructure IdP Proxy.

OpenID Connect / OAuth entity technical requirements

Metadata

Relying parties supporting OpenID Connect SHOULD retrieve the EOSC Core Infrastructure Proxy configuration based on the Issuer information using the [OIDC-Discovery] specification.

Grant types

OpenID Connect relying parties 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. OpenID Connect relying parties SHALL NOT use the implicit grant and any other response type causing the authorization server to issue an access token in the authorization response.

Claims

OpenID Connect relying parties 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 [OIDC-REFEDS].

Redirection URIs

OpenID Connect relying parties MUST pre-register one or more Redirection URI to which authentication responses from the EOSC Core Infrastructure Proxy will be sent. The EOSC Core Infrastructure Proxy utilises exact matching of the redirect URI specified in an authentication request against the pre-registered 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

  • No labels

Privacy Policy