This page describes the future plans for the EOSC-hub AAI. These include alignment activities across the EOSC-hub AAI services which can be classified into technical and policy-related activities.
Technical alignment activities
The following technical alignment activities have been identified:
...
| Activity | B2ACCESS | Check-in | eduTEAMS | INDIGO-IAM |
|---|---|---|---|---|
| Alignment of user attributes | ✓ | ✓ | ✓ | M24 |
| Alignment of VO/group membership and role information | ✓ | ✓ | ✓ | M24 |
| Alignment of resource capabilities information | ✓ | ✓ | ✓ | M24 |
| Alignment of affiliation information | M24 | M24 | M24 | M24 |
| Alignment of assurance information (including freshness of affiliation information) | PY3 | PY3 | PY3 | PY3 |
| Oauth2 token validation across multiple domains (multi-proxy connection workaround) | ✓ | ✓ | ✓ | ✓ |
| Oauth2 token validation across multiple domains (initial implementation) | M24 | M24 | M24 | M24 |
| Oauth2 token validation across multiple domains | PY3 | PY3 | PY3 | PY3 |
Policy-related integration activities
The following policy-related alignment activities have been identified:
...
| Activity | B2ACCESS | Check-in | eduTEAMS | INDIGO-IAM |
|---|---|---|---|---|
| Alignment of privacy statements | ✓ | M24 | ✓ | ✓ |
| Alignment of operational security and incident response policies | ✓ | ✓ | ✓ | ✓ |
| Alignment of Acceptable Use Policies (AUPs) | M24 | M24 | ✓ | ✓ |
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.
| EUDAT | EGI | GEANT | INDIGO-IAM | |
|---|---|---|---|---|
| B2ACCESS | ✓ | |||
| Check-in | ✓ | ✓ | ||
| eduTEAMS | M18 | M18 | PY3 | |
| INDIGO-IAM | PY3 | PY3 | PY3 |
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").