This page contains service description outlining how and where service should be used, targeted users, service delivery model and service elements and topology. RESPONSIBLE: Information provided in this page is initially populated by the development team (during the transition phase), and revised based on the need or in a yearly service check by eduroam Managed IdP Service Manager, with exception of CBA which remains the responsibility of business development team. |
The product eduroam Managed IdP enables eligible institutions to outsources the technical setup of eduroam IdP functions to the eduroam Operations Team. eduroam IdP administrators use the service system to replace the local authentication infrastructure and identity management. The system service includes:
The non-technical aspects of an eduroam IdP remain in the responsibility of the eduroam IdP administrator, and are subject to the eduroam Service Definition.
eduroam Managed IdP is a multi-level multi-tenant system with several stakeholder groups:
eduroam NRO administrators recruit small R&E institutions in their NRO region. They offer eduroam account management with eduroam Managed IdP to these institutions, and enable add these institutions them to use the service system by the web-based institution management interface available to on their NRO administrators interface. Multi-tenancy on this level means that each NRO has its own compartment in the system - an NRO administrator only sees his own institutions, and can manage his own NRO's properties and subscription. The number of tenants is limited by the number of DNS country-code top-level domains on the planet.
***Marina comment to Stefan: are we limiting the institutions to the small ones ? (first sentence in previous paragraph and title in next paragraph) Also, who can use this service - I think only the GEANT partners (last sentence). Also we need to mention that there is a limit of 10000 accounts per NREN.
eduroam IdPs sign up ***(in the sence of sign in to web interface or sign up to use the service?) to the service system to provision, modify and remove individual users from eduroam. They do this entirely on a non-technical level using a web interface, and are spared from all technical details usually associated with being an eduroam IdP.
Multi-tenancy on this level means that the IdP admin has his own compartment for his organisation in the system - he only sees his own institution, and can manage only his own institution's properties and users. The number of users she/he can manage is limited by his NRO admin (or, failing an explicit setting by the NRO admin, there is a default of 200 as fallback in the system). The limitation in terms of number of users is arbitrarily chosen and can be modified during deployment time. *** needs to be updated when deployed, but better to refer to a place where we can define config parameters
eduroam users get an eduroam account simply by redeeming invitation tokens which were previously generated by their IdP admin. With that account, they use eduroam for as long a time as the administrator has sanctioned the use. The users can view and manage their account status at all times. Multi-tenancy on this level means that the user only ever sees his own eduroam account and associated credentials.
| Service Manager | Deputy Service Manager | L1 support | L2 support | L3 support |
|---|---|---|---|---|
| Miroslav Milinović | eduroam IdPs are required to enter helpdesk details for their tenancy level. This is the L1 support for their end users; all questions about account expiry, revocation of login permissions etc. is handled inside the IdP. Likewise, the eduroam NRENs are providing the L1 support to the eduroam IdPs. help@eduroam.org is first level contact provided by GEANT, and primarily targeting NROs (same like for the eduroam service) ***however - if there is a problem with the authentication - what is the flow for the support to the users - I think that we need to define this process thought the questionnaire |
Add explanation about organisation of service delivery
Service Elements, with brief description and links to products, resource instances and software stack of the service, indicating the software components types - if they are internally (in-house) developed, OSS or commercial off-the-shelf software. Service elements can be grouped in two following categories:
Add list and description of products and resources used to deliver main functionalities of the service. Add service technical architecture - i.e. its good to have a conceptual architectural diagram and topology diagram.
Add list and descriptions of products and resources used to deliver supporting services such as specialized monitoring and measuring systems, configuration management system, issue/ticket reporting system, etc.)
CBA Document, Payback Schedule