Adoption detailed checklist with templates and examples
The adoption of SWITCH edu-ID should be thoroughly planned. The main parts of the plan should include
- The collaboration with stakeholders at an organization involved with identity management processes
- Measures for the communication with the end-users of edu-ID identities
- The technical integration concept and implementation plan.
Universities vary in size and organisation, and therefore their integration plans also differ. The following are just some indications of measures and work packages that may be necessary. Depending on the situation at universities and chosen integration scenarios the planning needs to be adjusted.
The typical time frame for the entire adpotion of the edu-ID at an organization from the first workshop to the final debriefing meeting is typically 6 to 18 months.
In the descriptions below, day X refers to the day of the actual migration when organisation switches from their own Shibboleth IdP to the SWITCH edu-ID IdP. From this day on users get the edu-ID login screen when they use a linked edu-ID account to access services formerly accessed with their SWITCHaai account.
1. Concept and planning
day X - 12 months
- start date for planning phase (preferrably before 2020)
- if you would like to apply for third party funding
The communication concept should be completed at the end of the planning phase, but first measures should be taken directly after the decision to start a planning project and a first meeting with the SWITCH edu-ID team.
1a) Define the stakeholder groups to inform / involve
Communication starts with planning ...
Potential stakeholder groups to involve in planning or to inform about:
- Identity management (IdM) responsibles, administrators of Shibboleth IdP (mandatory)
- decision makers (heads of IT, administrative director etc.)
- IT staff (involved collaborators and integration stakeholders)
- service providers (administrators)
- security officer
- support staff / helpdesk
- departemente, study programme managers etc.
- human resources department
- traning managers (continuing education etc.)
- library officers
- alumni organisation leaders
... and continues with the introduction:
All end users of an edu-ID identity should be informed:
12. staff members (existing / future)
13. students (existing / future)
14. continuing education students and other target groups who need an edu-ID such as guests, auditors, etc.
1b) Evaluate the communication channels
Which information channels are used in your organisation?
- internal meetings
- website (intranet, extranet)
- social media
- flyer / poster
- information boards / screens
1c) Decide which channels to use for the different stakeholder groups
Download this table as .xlsx
|Stakeholder||Management||IT Services||SP Admins||Help-desk||HR||Continuing education||Library||Alumni||other|
|Goals||What is my main goal for each group? (Awarness, acceptance, participation, support, ...)|
|Strategy||Which strategy do I pursue with the communication to this group?
(1. contact, 2. inform, 3. participate, 4. decide)
|Message||What is my main message to the respective stakeholder group?|
|Expectations||What expectations do different stakeholder groups probably have of SWITCH edu-ID?|
|Channels||Which channels are particularly suitable and should be used? (for what purpose, which group?)|
|Procedure||What concrete communicative measures are being taken? (meetings, presentations, newsletter articles, e-mail, etc.)|
2. Choose the technical integration approach
day X minus 10 months
This step requires profound knowledge of the processes to register/onboard new members at an organization and how they are deprovisoned/offboarded when they leave the organization. Organizational members usually are students, staff, teachers and professors. Other groups like alumni, further education students, guests, researchers, auditors may also be official organizational members.
- evaluate onboarding processes for current existing members and the linking methods
- evaluate onboarding processes for new future members and the linking methods
Note: that onboarding processes for different user groups can be combined with different linking methods. See Examples.
- To synchronize memberships and attributes from the organisation to the edu-ID service choose the attribute push or pull API.
- evaluate the effort and describe the implementation steps.
- are email addresses of leaving members potentially recyceled for new users? Disable such email addresses in edu-ID accounts.
- are there special configurations on your IdP as local attributes? Please provide the /opt/shibboleth-idp/conf/services.xmnl file. The directory contains the references of the configuration files loaded by the IdP.
- Future members: use regular channels to provide information about SWITCH edu-ID, i.e. within the framework of the registration (onboarding) and deprovisioning (offboarding) process, as well as within the framework of the organisation's support services.
- Existing members: provide additional information on the transition from SWITCHaai to SWITCH edu-ID - particularly with regard to linking edu-ID with the local identity.
- Leaving members: explain to users that they can continue to use an edu-ID (i.e. to access alumni services, to make subscription at other universities, to access other services that are open to former university students). Request users to add a private email address to their account.
Provide information about SWITCH edu-ID to end users at least at
- help desk pages
- registration pages
3. Describe your implementation tasks & communicative measures
day X minus 8 months
After the decisions about scenarios and linking methods you will be able to plan the necssary work and communicative measures in detail.
Download this table as .xlsx
|date||work/task, content/main messages
||method, technical description, form/channel||recipient of product or message, target group(s)||What to think about?
|start of planning or decision to adopt edu-ID||
purpose of edu-ID
intention of university
|IT, Marketing||internal newsletter, intranet||staff & students, different stakeholders|
|X - 6 months||intention of university to adopt edu-ID, benefit, roadmap, contact person, next information (when, where)||IT, Marketing||newsletter, website||end users, all potential target groups|
|X - 4 months||instructions for linking, ev. extract of FAQs , information link, ev. contact person||IT, Marketing||newsletter, e-mail, website, help desk, poster||end users|
|X - 1 month||1. reminder: instructions for linking, ev. extract of FAQs , information link, ev. contact person||IT||end users without linked account|
|X - 1 month||
change of IdP end point at day X
manual reload of metadata for services without regular updates as recommended to grant instant access.
adaptation on IdP necessary if services do not load metadata.
test attribute exchange API, on/off-boarding processes, IdP migration.
link to further information
|X - 1 week||2. reminder: instructions for linking, ev. extract of FAQs , information link, ev. contact person||IT||end users without linked account|
|X - 2 days||
change of IdP end point at day X with exact timeframe
check of access to service after change of end point by SP admin (especially in case of missing automatci metadata reload)
contact in cae of problems/questions
|X - 2 days||3. reminder: instructions for linking, information link, support link||IT, Marketing||end users without linked account|
information about successful migration
description of ev. problems and solving
contact in case of future questions about edu-ID, configuration of service etc.
|X + 1 month|
4. Implement onboarding processes and attribute exchange
day X minus 3 months
Depending on the chosen onboarding approach(es):
- Implement and configure the respective linking or registration services
- Inform the edu-ID team and request API credentials if necessary
- Test the onboarding service together with the edu-ID team
Depending on the chosen attribute exchange approach:
- Implement the chosen attribute exchange API
- Inform the edu-ID team and exchange API credentials
- Test the attribute exchange together with the edu-ID team
A customized login/registration page of the edu-ID offers the possibility to integrate, logo, organisation name, links to help pages, phone numbers - those are important hints for users that they are moving in the right context.
as soon as you have set up a registration page with edu-ID (also for test purposes)
and send us the information for customizing!
If many users of an organisation use a certain service regularly, this can be provided with a reference to edu-ID or even be switched in advance to exclusive access with SWITCH edu-ID, in order to trigger the linking of many users before day X.
The good guidance of the users through the registration processes is very important.
When you are giving instructions on how to register, make sure that:
- to give short, unambiguous, uniform (preferably valid for all groups of persons and courses of study) and step-by-step instructions
- to make individual web pages so clear and understandable that they are understood even when taken out of context (target group etc.), and to specify a sequence for several pages (e.g. by numbered steps)
- indicate help contacts for content and technical questions (both contacts to the organization) on each page of the registration, if possible
- set only one (single) prominently placed link to the customized registration page
Do not list additional links (e.g. on edu-id.ch) which could confuse users! (except for user groups, which actually have to register directly there)
If links to background information about the edu-ID are set, these should be less prominent and should follow the instructions. Background information on the edu-ID should be available on a public website of the university (there you can also link to SWITCH edu-ID pages).
Example of a registration page with manual at FHNW
5. Organize support
day X minus 2 months
End-user support is a shared task between the university and SWITCH.
For end users, it is not always clear whether they have to contact the university or SWITCH for every problem. This can be partly intercepted by information on each page called up, but not completely.
It is therefore important for enquiries between the university and SWITCH to be forwarded to the right place in each case.
Requests to firstname.lastname@example.org or +41 44 268 1510 will be accepted by the SWITCH Helpdesk and, if necessary, distributed within SWITCH or forwarded to the addresses universities have indicated.
Further contact options for administrators will be added at a later date.
For this reason, please let us know which contacts are responsible for your organisation's support requests:
a) For the forwarding of end user enquiries which we receive but cannot process (application-specific if necessary)
b) For enquiries regarding technical problems in connection with SWITCH edu-ID (e.g. regarding your IdM, notifications, registration applications, etc.)
Questions concerning integration can be sent to email@example.com.
Once an organisation has been adopted SWITCH edu-ID, users will see in the SWITCH edu-ID web application which support office(s) they should contact if, for example, attributes of an affiliation are incorrect and need to be changed (these contacts must be entered in the Resource Registry).
6. Cleanup and debriefing
day X plus 1 month