2019-bidding/aai
Main | EGI.eu operations services | Support | Documentation | Tools | Activities | Performance | Technology | Catch-all Services | Resource Allocation | Security |
EGI Core services menu: | Services PHASE I • | Services PHASE II • | Services PHASE III • | Bids • | Payments • | Travel procedure • | Performance |
Go back to the EGI Core Activities Bidding page.
TO UPDATE
to add requirements on software licenses and fitsm traning&certification
to clarify the effort
Service name: CheckIn
Introduction
The Check-in service is the AAI Platform for the EGI infrastructure. The Check-in service enables the Integration of external IdPs (from eduGAIN and individual organizations) with the EGI services through the Check-in IdP/SP proxy component, so that users are able to access the EGI services (web and non-web based) using credentials from their home organizations or other external IdPs. The proxy supports credential translation from SAML2 to SAML2, OIDC and X.509v3 and from OIDC/OAUTH2 to SAML2, OIDC and X.509v3. The Check-in Service enables the users to manage their accounts from a single interface, to link multiple accounts/identities together and to access the EGI services based on their roles and VO membership rights. For VOs, the Check-in Service provides an intuitive interface to manage their users and their respective roles and group rights. For VOs, operating their own Group/VO Management system, the Check-in service has a comprehensive list of connectors that allows to integrate their systems as externally managed Attribute Authorities. This is not meant to be an exhaustive list of the functionality of the Check-in Service. More information can be found on the EGI Check-in Service web pages (https://wiki.egi.eu/wiki/AAI).
The CheckIn service is a critical component of the EGI infrastructure, in many workflows it will be a central service that enables access to users to the distributed services offered by EGI resource centres. It is therefore important that the CheckIn service is deployed and operated in a distributed and high available architecture.
The activity supports as well some legacy services for the authorization and authentication of users in EGI:
- Catch-all and for dteam VO VOMS
Technical description
The components and the features of CheckIn are the following:
- Idp/SP Proxy based on SimpleSAMLphp
- Connectors for IdP supporting: SAML, ODIC, OAuth2, OpenID, X.509
- Connectors for attribute authorities supporting: SAML 2.0 SAMLAttributeQuery, REST, LDAP
- Connectors for SP supporting: SAML, OIDC, OAuth2
- Secure GUI for the registration and management of OIDC clients
- Rules engine
- Rule based LoA mappings
- Rule based SP specific entitlements
- Centralised IdP Discovery Service
- Support for SP specific IdP filtering
- User enrollment service based on CoManage
- Support for user consent for the release of the attributes
- Acceptance of the terms of use of EGI
- Delegated administration
- Web based control panel for creating custom enrolment flows
- REST API
- Account linking
- Back-end database for the storage of user information and user profiles
- Database cluster supporting streaming replication and Point-in-Time Recovery (PITR) for a period of six months (minimum)
- Master portal for the integration with the RC Auth online CA
- Master portal is the access point to online X.509 credentials for all EGI services
Other services not related to CheckIn:
- Catch-all VO membership management for small research teams and the long tail of science, as well as for infrastructure VOs including DTEAM: a VOMS service for the X509 credentials and other attribute authorities to support user grouping with other authentication technologies.
Coordination
This activity is responsible for the coordination of the system operations in collaboration with those partners that are in charge of operating other systems that depend on the EGI AAI infrastructure. For instance, the following activities of coordination are necessary for the provisioning of the activity:
- With the IdP/SP for the integration in CheckIn
- With the EGI Operations for the policy and operational requirements
- With the Research Infrastructure, VREs and other e-infrastructure where harmonization activities are required
Operations
- Daily running of the system
- Operations in high-availability of all the Check-in components described at the beginning of this section
- Minimum monthly availability must be: 99%
- Support request for changes through the GGUS support unit
Support
Provide support to:
- Identity providers who are integrated in CheckIn, only for issues concerning the CheckIn service
- Attribute providers who are integrated in CheckIn, only for issues concerning the CheckIn service
- End users who use CheckIn to authenticate in EGI
- Service providers about the interaction of the services with CheckIn proxy
Maintenance
- Requirements gathering
- Documentation
Software as a service
In the bid, please provide also information about the possibility to provide the service to external consumers as a Software as a Service. If the provisioning of the activity as a SaaS implies additional effort or other costs, please report these costs separately, not as part of the overall budget of the bid.
Service level targets
The deployment of the services must ensure:
- Minimum availability/reliability: 99%/99%
- Response to incident records in GGUS within support hours: Medium (see Description page)
Effort
Bids planning a effort between 12 and 18 Person Months/year would allow these services and activities to be addressed appropriately.