EGI-Engage:TASK JRA1.1 RC Auth integration steps and actions

From EGIWiki
Jump to: navigation, search
EGI-Engage project: Main page WP1(NA1) WP3(JRA1) WP5(SA1) PMB Deliverables and Milestones Quality Plan Risk Plan Data Plan
Roles and
WP2(NA2) WP4(JRA2) WP6(SA2) AMB Software and services Metrics Project Office Procedures


This wiki pages collects the actions and steps to lead to a full integration of RC Auth in the production infrastructure of EGI.

Recorded actions during meetings

Phone call Sep 2016

  • [X] WAYF in edugain.
  • [ ] LoA definition
  • [X] RCAuth CA needs a new update, that is basically done
  • [ ] Update the master portals in order to connect them with the real RCAuth.
  • [X] [Action, Mischa]; check with David if GRNET deployment of master portals is ok
  • [ ] [Action, Mischa]: check with Tom the feasibility of the PUSP
  • [ ] Privacy Policy
  • [X] Terms of Use (is it OK to use standard (Grid) Acceptance Use Policy?)

F2F Meeting during DI4R

  • [ ] The master portal operated on ~Okeanos probably needs to be updated. There is no

need to re-install the service.

  • [ ] Nicolas to follow up via e-mail with Mischa and Tomasz in order to co-ordinate the update and provide Client ID (next week or the week after)
  • [ ] Dave to check with Sven if EGI CSIRT has a general PGP key for (this or next week)
  • [ ] Dave to prepare the privacy policy (next week)
  • [ ] Nicolas, Christos, Peter to investigate the introduction of a new ePEntitlement to be used by RCAuth
  • [ ] Peter, Christos prepare the [[1][document for enrolling the master portal]]
  • [ ] Peter, Christos to prepare the [[2][document for the legacy IdP]]

Further notes to complete the actions above

Document for enrolling the master portal

  • Will be signed by
  • Incident response contact: (need also mail address and phone number. Should it be contact details?)
  • CSIRT PGP key (Is there one for ?)
  • Privacy Policy URL: There should be a generic policy text linked from

Document for the legacy IdP

  • Same as for the previous document
  • We need to investigate the registration of the EGI AAI IdP component in RE:EP
  • We need to provide the EntityID of the IdP component
  • Released name attributes: [ ] Display name [ ] givenName & sn [ ] commonName

How to identify eligible entities

  • Eligible entities need to be identified either by ePEntitlement (preferred) or by ePAssurance or AuthnContextClassRef. Eligible entities must meet the [[3][baseline LoA]]. This effectively means that we need to allow only R&S compliant IdPs (which gives us proper identifiers).
  • There was a discussion about ensuring timelessness of the user accounts. Technically this can be implemented on the EGI CheckIn service side by requesting that all users resign the AUP every year. But is this needed, if we require R&S?
  • So the question here is whether the CheckIn service will provide the LoA to the downstream service and the downstream service takes a decision OR the EGI CheckIn services "computes" the ePEntitlement and passes that to RCAuth. The latter is preferred. This will required a specific configuration for RCAuth on the EGI AAI CheckIn service.