...

• Alignment of user attributes: The attributes used to express user information should follow the REFEDS R&S attribute bundle, as defined in [REFEDS-R&S]
• Alignment of VO/group membership and role information: VO/group membership and role information, which is typically used by relying parties for authorisation purposes, should be expressed according to [AARC-G002]
• Alignment of resource capabilities information: Capabilities, which define the resources or child-resources a user is allowed to access, should be expressed according to [AARC-G027]
• Alignment of affiliation information: Affiliation information, including (i) the user’s affiliation within their Home Organisation, such as a university, research institution or private company, and (ii) affiliation within the Community, such as cross-organisation collaborations, should be expressed according to [AARC-G025]
• Alignment of assurance information: Assurance information used to express how much relying partins can trust the attribute assertions about the authenticating user should follow:
  • REFEDS Assurance framework (RAF) [RAF-version-1.0]
  • Guideline on the exchange of specific assurance information [AARC-G021]
  • Guideline for evaluating the combined assurance of linked identities [AARC-G031]
  • Guideline Expression of REFEDS RAF assurance components for identities derived from social media accounts [AARC-GO41]
  • Guidelines for expressing the freshness of affiliation information, as defined in [AARC-G025]
• Oauth2 token validation across multiple domains: OAuth2 Authorisation Servers (AS) should be able to validate tokens issued by other trusted AS. Extending existing flows, such as the OAuth2 Token Exchange flow [OAuth2-Token-Exchange-draft], are being investigated for enabling the validation of such externally issued tokens. Workaround: Services need to trust all AS that issue tokens, instead of relying on a single infrastructure proxy/AS proxying multiple communities There are use cases requiring a service agent to be able to act autonomously, on behalf of the user, consuming services and resources. If the services consumed by the agent are behind the same proxy, the EOSC-hub AAI architecture works. However, when an agent running on Service A needs to access resources on Service B, which might be connected by a different proxy, then there is no straight-forward solution at the moment. So, currently, services need to trust the same proxy to support those use cases. The AARC community is working on “AARC-G052: Recommendations for OpenID Connect/OAuth2 token-based access across different infrastructures”, which is meant to be a temporary measure until the OIDC Federation Specification is widely available.

The table below lists the identified technical alignment activities and their status. A green checkmark indicates a complete activity, otherwise the expected time of implementation is provided.

Policy-related integration activities

...

Integration of EOSC-hub AAI services

This section presents the integration roadmap of the EOSC-hub AAI services. The status of each of the required integrations or the expected time of implementation is described in the table below. Integrations which have already been established are marked with a check mark. Note that where integration is not considered complete, an amber checkmark is used to indicate the status. The currently identified integration gaps are included in the known issues list.

Known issues

• Multiple user registrations: Users are asked to register with different AAI services as they access resources protected by different infrastructure proxies. The identified technical (e.g. alignment of user attributes) and policy (e.g. alignment of AUPs) harmonisation activities will enable seamless access across different domains .Multiple IdP discovery steps: The EOSC-hub AAI is based on the AARC BPA “community-first” approach, whereby users often need to go through multiple IdP discovery steps: (a) to select their Community AAI and (b) to select their Home Organisation. During this process, users don’t need to re-enter their login credentials as long as their Single Sign-On session is active, however the IdP selection can be frustrating in some cases. The discovery process needs to be simplified by either narrowing down the number of possible IdPs to choose from or by making the actual selection process fully transparent (see also “IdP hinting” protocol proposed in AARC-G049).
• OAuth2 token validation: Existing implementations of OAuth2 Authorisation Servers do not support the validation of tokens issued by a different Authorisation server. As a consequence, a token cannot be used across services connected to different proxies/OAuth2 Authorisation Servers. One workaround is to connect a given service to the different Authorisation Servers that issue tokens, instead of relying on a single proxy. As a long-term solution, we’re investigating the extension of the OAuth2 Token Exchange flow for allowing OAuth2 Authorisation Servers to handle tokens issued by other trusted Authorisation Servers (see also technical activity "Oauth2 token validation across multiple domains") The current EOSC-hub AAI architecture works very well when the user is consuming services directly. However, there are use cases requiring a service agent to be able to act autonomously, on behalf of the user, consuming services and resources. If the services consumed by the agent are behind the same proxy, the current architecture works. For those cases, though, where an agent running on Service A needs to access resources on Service B, which might be connected by a different proxy, then there is no straight-forward solution at the moment. So, currently, services need to trust the same proxy to support those use cases. A solution for dynamically establishing trust in a distributed environment will be provided by the OpenID Connect Federation specification v1.0 (draft). The AARC community is working on “AARC-G052: Recommendations for OpenID Connect/OAuth2 token-based access across different infrastructures” that is investigating an extension of the OAuth2 Token Introspection specification as an interim solution measure until the OIDC Federation Specification is widely available.