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

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

Introduction

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 abuse@egi.eu (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 EGI.eu
• Incident response contact: abuse@egi.eu (need also mail address and phone number. Should it be EGI.eu contact details?)
• CSIRT PGP key (Is there one for abuse@egi.eu ?)
• Privacy Policy URL: There should be a generic policy text linked from www.egi.eu

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.