Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Update status of Integration of EOSC-hub AAI services



Known issues

  • 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: 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.