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|
|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
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 email@example.com (this or next week)
- [ ] Nicolas, Christos, Peter to investigate the introduction of a new ePEntitlement to be used by RCAuth
- [ ] Peter, Christos prepare the [[document for enrolling the master portal]]
- [ ] Peter, Christos to prepare the [[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: firstname.lastname@example.org (need also mail address and phone number. Should it be EGI.eu contact details?)
- CSIRT PGP key (Is there one for email@example.com ?)
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 [[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.