Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

Difference between revisions of "2019-bidding/aai"

From EGIWiki
Jump to navigation Jump to search
Line 105: Line 105:
== Effort (EGI-related activities) ==
== Effort (EGI-related activities) ==


Bids planning a effort of about 12 Person Months/year would allow these services and activities to be addressed appropriately. Effort may be provided as part of either the INFRAEOSC-07 and INFRAEOSC-03 projects.
Bids planning a effort of about 13 Person Months/year should allow these services and activities to be addressed appropriately.  


== Effort (EOSC-related activities) ==
== Effort (EOSC-related activities) ==
Partners are encouraged to submit details of activities and proposed costing of effort for EOSC Hub related activities. This may include activities related to development of new functionality required by EOSC communities in addition to activities delivering services to these communities.
Partners are encouraged to submit details of activities and proposed costing of effort for EOSC Hub related activities. This may include activities related to development of new functionality required by EOSC communities in addition to activities delivering services to these communities.

Revision as of 15:03, 15 November 2019

Main EGI.eu operations services Support Documentation Tools Activities Performance Technology Catch-all Services Resource Allocation Security



EGI Services and Service Management Support menu: Bids Old Bids Performance

Go back to the EGI Services Bidding page.

Service name: Check-in

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.

Technical description

The components and the features of Check-In 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

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
  • Creating an Availability and Continuity Plan and implementing countermeasures to mitigate the risks defined in the related risk assessment
  • Support request for changes through the support unit in the EGI Helpdesk service
  • Support to:
    • Identity providers who are integrated in Check-in, only for issues concerning the Check-in service
    • Attribute providers who are integrated in Check-in, only for issues concerning the Check-in service
    • End users who use Check-in to authenticate in EGI
    • Service providers about the interaction of the services with Check-in proxy

Support

Support hours: eight hours a day (for example 9-17 CE(S)T), Monday to Friday – excluding public holidays of the hosting organization.

Maintenance

  • Requirements gathering
  • Maintenance of probes to test the functionality of the service
  • Documentation

Software Compliance

  • Unless explicitly agreed, software being used and developed to provide the service should:
    • Be licensed under an open source and permissive license (like MIT, BSD, Apache 2.0,...).
      • The license should provide unlimited access rights to the EGI Foundation and EGI federation member organisations.
    • Have source code publicly available via a public source code repository (if needed a mirror can be put in place under the EGI organisation in GitHub.) All releases should be appropriately tagged.
    • Adopt best practices:
      • Defining and enforcing code style guidelines.
      • Using Semantic Versioning.
      • Using a Configuration Management frameworks such as Ansible.
      • Taking security aspects into consideration through at every point in time.
      • Having automated testing in place.
      • Using code reviewing.
      • Treating documentation as code.
        • Documentation should be available for Developers, administrators and end users.

IT Service Management compliance

  • Key staff who deliver services should have foundation or basic level ITSM training and certification.
    • ITSM training and certification could include FitSM, ITIL, ISO 20000 etc.
  • Key staff and service owners should have advanced/professional training and certification covering the key processes for their services.
  • Providers should have clear interfaces with the EGI SMS processes and provide the required information.
  • Providers should commit to improving their management system used to support the services they provide.

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:

  • Monthly Availability, defined as the ability of a service or service component to fulfil its intended function at a specific time or over a calendar month.
    • Minimum (as a percentage per month) for IdP/SP Proxy, IdP Discovery Service: 99%
    • Minimum (as a percentage per month) for Master Portal: 90%
  • Monthly Reliability, defined as the ability of a service or service component to fulfil its intended function at a specific time or over a calendar month, excluding scheduled maintenance periods.
    • Minimum (as a percentage per month) for IdP/SP Proxy, IdP Discovery Service: 99%
    • Minimum (as a percentage per month) for Master Portal: 90%
  • Response to incident records in GGUS within support hours: Medium (see Description page)*

Effort (EGI-related activities)

Bids planning a effort of about 13 Person Months/year should allow these services and activities to be addressed appropriately.

Effort (EOSC-related activities)

Partners are encouraged to submit details of activities and proposed costing of effort for EOSC Hub related activities. This may include activities related to development of new functionality required by EOSC communities in addition to activities delivering services to these communities.