Requirements EOSCENR-115 and EOSCENR-116 asked for the capability to onboard “National Catalogues and Registries” and “National, Regional or Thematic Aggregators” in an automated way” to the EOSC Portal.

The requirements were analysed and led to a pilot implementation to onboard to the EOSC Portal  Regional or Thematic Portals with multiple providers and their resources and to synchronize the metadata between the EOSC Portal and the MPRTPs.

The first pilot was implemented with the NI4OS project. The implementation of the NI4OS pilot revealed several technical and policy-related aspects for the onboarding of Aggregators/Multi-Provider Portals to the EOSC Portal that need to be further examined and resolved.

These aspects include the deduplication of records, the bidirectional synchronization of records, the administration rights for the Providers and Resources registered at both Portals, the need of a framework or customised agreement for each of the Portals to be integrated into EOSC Portal, etc.

One of the major updates of the EOSC Portal Interoperability Framework made for addressing some of the aforementioned issues, is the introduction of a new Profile for the EOSC Portal Multi-Provider Catalogue and the relevant updates of EOSC Portal Provider and Resource Profiles (introduction of a new attribute “Catalogue” to link to the MPRTP)

Bidirectional synchronisation should be allowed in the future. In this case, the prevailing metadata to overwrite the other will be the one lastly updated (based on timestamp) and therefore the Authorized representative(s) of a Provider must be aware that any change introduced to metadata in one Portal will be communicated to the other one as well.

This is a requirement that will be handed over to EOSC Future.

Furthermore, the onboarding of an MPRTP should have as a prerequisite to sign an agreement with the EOSC Portal to abide by the EOSC Rules of Participation, EOSC Portal Onboarding Process and\or any other assumptions to allow for representing and managing the resources of its providers in the EOSC portal. This is also handed over to EOSC Future.

Τhe Onboarding Process v4.00 for the MPRTP  is very similar to the Onboarding Process of the Single Provider and includes 5 Phases and 19 distinct Stages.

An updated version of the EPOP for an MPRTP v4.00 must be developed once all previously mentioned issues are fully resolved.

The 5 Phases of the MPRTP EPOP v4.00 are:

  • Phase 1: An Authorised Representative of MPRTP registers into the EOSC Portal.
  • Phase 2: The Authorised and Authenticated Representative of an MPRTP (AARM) onboards the Providers registered at the MPRTP.
  • Phase 3: The AARM onboards the Resources registered at the MPRTP.
  • Phase 4: The AARM onboards the Options/Offerings of Resources offered by the Providers registered at the MPRTP.
  • Phase 5: The AARM and the EPOT maintain the quality of the Profiles.

The 19 Stages of the MPRTP EPOP v4.00 are:

  • Stage 1: The Representative of the MPRTP (RM) visits the EOSC Portal.
  • Stage 2: The RM registers with the EOSC Portal using an existing identity from a supported Social or Academic AAI mechanism.
  • Stage 3: The Authenticated Representative of the MPRTP (ARM) logs into the EOSC Portal.
  • Stage 4: The ARM asserts he/she is an Authorized Representative of an MPRTP.
  • Stage 5: The Authenticated and Authorized Representative of an MPRTP (AARM) apply to onboard the MPRTP.
  • Stage 6: The EOSC Portal Onboarding Team (EPOT) reviews the newly onboarded MPRTP.
  • Stage 7: The AARM gets access to the Portal Dashboard.
  • Stage 8: The AARM logs into the API Token Portal.
  • Stage 9: The AARM selects to Get the Value of the Access Token.
  • Stage 10: The AARM selects to Create a Refresh Token.
  • Stage 11: The AARM selects to Manage all Access/Refresh Tokens.
  • Stage 12: The AARM onboards the MPRTP Providers into the EOSC Portal using the Token acquired.
  • Stage 13: The AARM onboards the Resources of the MPRTP Providers on the EOSC Portal with the token acquired.
  • Stage 14: The EPOT reviews the onboarded MPRTP Providers and Resources.
  • Stage 15: The AARM or the MPRTP Provider Managers may onboard Options/Offerings of the Resources of the MPRTP Providers.
  • Stage 16: The EOSC Portal Onboarding or Ordering Team reviews the Resource Options/Offerings of the MPRTP Providers’ Resources.
  • Stage 17: The EPOT creates a Review and Feedback Report.
  • Stage 18: Upon Request of MPRTPs the EPOT can provide best practices, feedback, and consultation to MPRTPs.​
  • Stage 19: Profiles on the EOSC Portal are updated by MPRTPs and periodically audited by the EPOT.

The following table provides further details of the actions that take place in the workflow Stages 8-13.

Stage

Title

Actions

Reference

B8

The AARM logs into the API Token Portal

A AARM [1] visits the Providers API Token Portal by entering the following URL in a browser: https://aai.eosc-portal.eu/providers-api and clicks on “Authorise”.

[1] it is assumed that the Representative of the MPRTP (to be confirmed via an agreement to be established):

·        There is a common onboarding process/method applied to both portals ('trusted') complying to the EOSC Portal Interoperability Framework, including the EOSC Portal Profiles, code lists, taxonomies and controlled values, Onboarding Process and RoP.

·        Providers registered at the MPRTP have agreed on the Terms of Use and Privacy Policy of EOSC Portal

·        Providers will update their Resources only at the MPRTP and not the EOSC Portal (unidirectional synchronization).

·        Resources and Providers in the EOSC Registry are linked to the original hosting catalogue.

·        There is a unique ID for Providers which must be common in both portals.

B9

The AARM selects to Get the Value of the Access Token

After successful authentication, the AARM is redirected to the Providers API token portal. Then she/he will be able to perform the following actions in the “My Access Token” tab [2]:

·        Get the value of the Access Token (Go to step B5a)

·        Create a Refresh Token (Go to step B5b).

·        Manage all Access/Refresh Tokens obtained by the EOSC Portal AAI.

The Representative of the MPRTP can Get the value of the Access Token and use it directly in an API call:

Click on the “Copy” button under the “Access Token” label and then add it to your HTTP request.

[2] New Access Tokens expire in 1 hour, but the Token Portal also allows for obtaining Refresh Tokens which are valid for approximately 13 months. A Refresh Token is a special kind of token used to obtain a renewed Access Token. Fresh Access Tokens can be requested using a Refresh Token until that token expires or gets revoked.

Example: Make a request from Terminal


$ export access_token=<access_token_value>
$ curl \
--header "Authorization: Bearer $access_token" \
--header "Content-Type: Application/json" \
--data "$escapedJson" \
https://sandbox.providers.eosc-portal.eu/api/provider

B10

The AARM selects to Create a Refresh Token

The AARM can Create a Refresh Token by clicking on the “Create Refresh Token” button. Then 2 new fields will appear with the following actions:

·        Get the value of the Refresh Token.

·        Request the token endpoint to generate an Access Token using the Refresh Token.

The Representative of the MPRTP shall then click on the “Copy” button under the “To generate access tokens from this refresh token use the following curl command” label and paste the command in the terminal.

B11

The AARM selects to Manage all Access/Refresh Tokens

The AARM can Manage all Access/Refresh Tokens that have been obtained by the EOSC Portal AAI by following the link: https://aai.eosc-portal.eu/oidc/manage/user/services.

In the “My Refresh Tokens” tab the Representative of the MPRTP can see all active Refresh Tokens that have been created by this portal.

The Representative of the MPRTP can copy the value of the refresh Token or “deactivate” the Token by clicking on the “Revoke” button. This action is irreversible.

B12

The AARM registers the MPRTP Providers into the EOSC Portal using the Token acquired

Upon successful completion of step B4, the Representative of the MPRTP registers the MPRTP Provider(s) via the API using the token acquired:

curl \

--header "Authorization: Bearer $token" \

--header "Content-Type: Application/json" \

--data "$escapedJson" \

https://sandbox.providers.eosc-portal.eu/api/provider

A FLAG is created in which the Provider(s) submitted the first resource as Resource Organisation.


B13

The AARM registers the Resources of the MPRTP Providers on the EOSC Portal with the token acquired

Following the successful completion of step B7, the Representative of the regional/thematic portal may onboard subsequent Resources, as per step B7 above.

Subsequent resources are automatically approved, but there is a flag that these are transferred from another catalogue. This is a filterable characteristic for EPOT (filter catalogue transfers, filter by specific catalogue). EPOT will audit these records periodically.





  • No labels

Privacy Policy