Difference between revisions of "2016-bidding/CheckIn"

From EGIWiki
Jump to: navigation, search
m (moved 2015-bidding/Phase 3 CheckIn to 2016-bidding/CheckIn: Corrected the address to be in line with the previous format)
(Support)
 
(22 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{Template:Op menubar}}{{Core_services_menubar}} {{TOC_right}}  
+
{{Template:Op menubar}}{{Core_services_menubar}} {{TOC_right}} '''Go back to the [[EGI Core Activities Bidding#PHASE_II_May_2016-December_2017|EGI Core Activities Bidding page]].'''  
'''Go back to the [[EGI_Core_Activities_Bidding#PHASE_II_May_2016-December_2017|EGI Core Activities Bidding page]].'''  
 
  
* Service name: Message brokers
+
*Service name: CheckIn
  
 +
<br>
  
 +
= Introduction  =
  
= Introduction =
+
The CheckIn service is the AAI Platform for the EGI infrastructure. The CheckIn service provides the following capabilities:
The message broker network is a fundamental part of the operations infrastructure ensuring message exchange for monitoring, the operations dashboard and accounting. As such it is a critical core infrastructure platform service component whose continuity and high availability configuration must be ensured.
 
  
= Technical description =
+
*Integration of IdPs (from eduGAIN and individual institutions) with the EGI services through an IdP/SP proxy
The EGI Production Messaging Infrastructure serves as a backend infrastructure for EGI operational tools that need to use a brokering functionality for message communications purposes (i.e. SAM infrastructure, APEL, the Operations Portal). The service component to be provided needs to provide scalability and redundancy with its  topology in order to keep up with the message load produced by the operations tools .
+
*Credential translation service:
The scalability of the service should be adjusted to support the amount of monitoring and accounting data produced by the sites that are part of the EGI Federation of High Throughput Computing, storage and cloud services.
+
**SAML2 &lt;--&gt; SAML2
Currently the number of services is about 5,000 and the number of resource centres is about 350 .
+
**SAML2 &lt;--&gt; OIDC
 +
**SAML2/OIDC --&gt; X.509 through the connection with the RC Auth online-CA
 +
*Attribute harmonization and policy enforcing
  
== Coordination==
+
The activity supports as well some legacy services for the authorization and authentication of users in EGI:
This activity is responsible for  
+
* Classic catch-all CA
* the coordination of the system operations and upgrade activities with those partners that are in charge of operating other systems that depend on it to ensure continuity of the service.
+
* Catch-all and for dteam VO VOMS
* requirements gathering.
 
  
== Operations ==
+
= Technical description  =
*Daily running of the system in high availability configuration
 
*A test infrastructure to verify interoperability and the impact of software upgrades on depending systems
 
*Maintenance of probes to test the functionality of the service
 
  
== Support ==
+
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 bid should include availability and continuity plan(s) for the technical service(s).  
Support of message production, exchange and consumption process through the EGI helpdesk.  
 
  
Support is provided to the operators of systems that rely on the EGI Message Broker Network capability.
+
The components and the features of CheckIn are the following (developed and integrated in the EGI-Engage project):
  
'''Support hours''': eight hours a day (for example 9-17 CE(S)T), Monday to Friday – excluding public holidays of the hosting organization.
+
*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.
 +
*Catch-all X.509 certification authority for homeless users
 +
 
 +
== Coordination  ==
 +
 
 +
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  ==
 +
 
 +
*Operations in high-availability of all the 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:
  
= Service level targets =
 
The deployment of the services must ensure:
 
 
*Minimum availability/reliability: 99%/99%  
 
*Minimum availability/reliability: 99%/99%  
*Response to incident records in GGUS within support hours: Medium (see [https://wiki.egi.eu/wiki/FAQ_GGUS-PT-QoS-Levels#Medium_service Description page])  
+
*Response to incident records in GGUS within support hours: Medium (see [https://wiki.egi.eu/wiki/FAQ_GGUS-PT-QoS-Levels#Medium_service Description page])
 +
 
 +
= Effort  =
  
= Effort =
+
Bids planning a effort between 12 and 18 Person Months/year would allow these services and activities to be addressed appropriately.
Bids planning a effort between 2 and 3 Person Months/year would allow these services and activities to be addressed appropriately.
 

Latest revision as of 09:44, 25 October 2016

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. 
  • Service name: CheckIn


Introduction

The CheckIn service is the AAI Platform for the EGI infrastructure. The CheckIn service provides the following capabilities:

  • Integration of IdPs (from eduGAIN and individual institutions) with the EGI services through an IdP/SP proxy
  • Credential translation service:
    • SAML2 <--> SAML2
    • SAML2 <--> OIDC
    • SAML2/OIDC --> X.509 through the connection with the RC Auth online-CA
  • Attribute harmonization and policy enforcing

The activity supports as well some legacy services for the authorization and authentication of users in EGI:

  • Classic catch-all CA
  • Catch-all and for dteam VO VOMS

Technical description

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 bid should include availability and continuity plan(s) for the technical service(s).

The components and the features of CheckIn are the following (developed and integrated in the EGI-Engage project):

  • 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.
  • Catch-all X.509 certification authority for homeless users

Coordination

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

  • Operations in high-availability of all the 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.