Date: Fri, 29 Mar 2024 01:36:16 +0100 (CET) Message-ID: <727107598.46.1711672576280@czmuims02.ops.egi.eu> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_45_1087108010.1711672576280" ------=_Part_45_1087108010.1711672576280 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The EOSC Core Infrastructure Proxy is connecting the EOSC Core and= EOSC Support Services to the EOSC Federated AAI.
Services that are eligible for connecting to the EOSC Core Infrast= ructure Proxy are:
Each service is required to provide the following information:
Service Providers supporting the SAML protocol MUST comply with th= e 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 SA= ML 2.0 Interoperability Deployment Profile [SAML2int] and the recommendations f= or upstream metadata produced by eduGAIN participants [eduGAIN-Metadata-Recommendations= ].
Entity Identifier Format
For Service Providers supporting the SAML protocol, the entity ide= ntifier is the SAML entityID attribute. Values of the entityID attribute re= gistered MUST be an absolute URI using the http, https or urn schemes. = ;
https-scheme URIs are RECOMMENDED for all entities. = p>
http-scheme and https-scheme URIs used for entityID values MUST co= ntain a host part whose value is a DNS domain.
Scope Format
Service Providers supporting the SAML protocol MUST NOT validate t= he scope of scoped attribute values released by the EOSC Core Infrastructur= e IdP Proxy.
Metadata
Relying parties supporting OpenID Connect SHOULD retrieve the EOSC= Core Infrastructure Proxy configuration based on the Issuer information us= ing the [OIDC-Discovery= span>] specification.
Grant types
OpenID Connect relying parties utilising the authorization grant t= ype SHOULD use PKCE [RFC7636] i= n conjunction with the authorisation server in order to detect and prevent = attempts to inject (replay) authorisation codes into the authorisation resp= onse. The PKCE challenges must be transaction-specific and securely bound t= o the user agent in which the transaction was started. OpenID Connect relyi= ng parties MAY use the "nonce" parameter of the OpenID Connect authenticati= on request as specified in [OI= DC-Core] in conjunction with the corresponding ID Token cl= aim 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 abou= t 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 Redir= ection URI to which authentication responses from the EOSC Core Infrastruct= ure Proxy will be sent. The EOSC Core Infrastructure Proxy utilises exact m= atching of the redirect URI specified in an authentication request against = the pre-registered URIs [OAuth2-BCP], with the matching performed as describ= ed in [RFC3986] (Simple String = Comparison). Redirection URIs MUST use the schemata defined in Section 3.1.= 2.1 of the [OIDC-Core= a>] specification