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

Decide about:

  • 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:

  1. Identity management (IdM) responsibles, administrators of Shibboleth IdP (mandatory)
  2. decision makers (heads of IT, administrative director etc.)
  3. IT staff (involved collaborators and integration stakeholders)
  4. service providers (administrators)
  5. security officer
  6. support staff / helpdesk
  7. departemente, study programme managers etc.
  8. human resources department
  9. traning managers (continuing education etc.)
  10. library officers
  11. 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
  • e-mail
  • newsletter
  • 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

2a) Decide about the approach to onboard the different user groups at your organisation

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.

Note: that onboarding processes for different user groups can be combined with different linking methods. See Examples.

2b) Decide about the attribute exchange interface

  • 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.

2c) Offboarding considerations

  • are email addresses of leaving members potentially recyceled for new users? Disable such email addresses in edu-ID accounts.

2d) Current IdP configuration

  • 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

When What Who How To whom Remarks
date work/task, content/main messages
responsibility, sender
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

general info

purpose of edu-ID

intention of university


contact person

further information

 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 email 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.

contact person

link to further information

 IT  email  SP admins  
X - 1 week 2. reminder: instructions for linking, ev. extract of FAQs , information link, ev. contact person IT email 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

     SP admins  
X - 2 days 3. reminder: instructions for linking, information link, support link  IT, Marketing  email end users without linked account  
day X

information about successful migration


description of ev. problems and solving

contact in case of future questions about edu-ID, configuration of service etc.

    SP admins  
 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.

Sign up at
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:

  1. to give short, unambiguous, uniform (preferably valid for all groups of persons and courses of study) and step-by-step instructions
  2. 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)
  3. indicate help contacts for content and technical questions (both contacts to the organization) on each page of the registration, if possible
  4. set only one (single) prominently placed link to the customized registration page

Do not list additional links (e.g. on 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 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
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