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. |
Service description
Product Description on the eduroam wiki space
Users
eduroam Managed IdP is a multi-level multi-tenant system with several stakeholder groups:
eduroam National Roaming Operator (NRO) administrators
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 add these institutions to the system on their NRO 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.
eduroam small institution administrators (IdPs)
eduroam IdPs sign up to the 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 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.
eduroam end users
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.
Contacts
| Service Manager | Deputy Service Manager | L1 support | L2 support | L3 support |
|---|---|---|---|---|
| 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. |
Service delivery model
Add explanation about organisation of service delivery
Service Elements
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:
Technology infrastructure
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.
Supporting infrastructure
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.)