Service Transition from AAI to edu-ID
The introduction of the SWITCH edu-ID service brings some fundamental changes:
- organizational IdPs are combined into one single IdP, and
- users manage their own personal identity.
On the other hand, everything else remains unchanged like the basic architecture of the SWITCHaai identity federation and the way how services are operated.
Bear in mind this guiding principle:
It's not the SPs that are switched to edu-ID, it's the IdP!
Don't panic - 99% of the services are not affected
Day-X is the moment when an organization switches off its own IdP and edu-ID takes over its function. Here's what remains the same before and after day-X:
- After clicking the login button, the WAYF (list of organizations) appears
- The user chooses the organization from the list (and not edu-ID)
- The service gets exactly the same SAML assertion from the edu-ID IdP, with the same attribute values
- Also direct login URLs continue to work without change
Consequently, a service does not have to change its configuration when an organisation switches to edu-ID.
The only change is what a user experiences when he/she accesses a service. When a user has selected the organisation in the WAYF
- the user gets the login window of the organization - before day-x
- the user gets the edu-ID login window - after day-x
How is it possible that a service operator does not have to do anything to switch from aai to edu-ID? The answer lies in the fact that a properly configured SP regularly updates the federation metadata. On day-X the service location of an organizational IdP is updated by SWITCH so that it points to edu-ID platform. Usually within one hour, all SPs in the federation have reloaded the new metadata and they will direct users to the correct IdP.
Aspects to consider
Here are some aspects that should be checked for an SP which is accessed by users from an organization with edu-ID integration.
- Make sure that the SP is properly configured, in particular that it automatically reloads the federation metadata once per hour.
- Some login buttons at SPs are labelled "AAI Login". This is technically correct, also for users who have an edu-ID. However, in the transition phase around day-x the organization's communication will often tell people to "create an edu-ID account" and use it henceforth. To avoid confusion for users, it might be a good idea to rename a login button to "AAI / edu-ID Login". Check the design guideline.
- SP operators and their helpdeks should be informed when day-X takes place. They should identify login problems and redirect users to the organizational helpdesk or to SWITCH edu-ID support.
- Some SPs embed the AAI login window in an iframe. This is bad practice from a security perspective and has therefore been disabled in edu-ID. A good alternative is to embed the discovery service/WAYF in the SP
- An SP has to be SAML 2 compliant according to the saml2int profile.
- This is optional: if an SP is mainly used by users of only one organization, the edu-ID login window can be customized with the logo of the organization and some explanations.
Testing if an SP will still work after day-x is a bit tricky.
Before day-x, an SP can be accessed with an edu-ID account only as private user, but not as member of an organization. In other words, before Tag-X the IdP cannot use an affiliation to identify a person as a member of an organization towards a classic SP. This is also why an organization typically cannot gradually move from AAI to edu-ID by switching one SP after the other from AAI to edu-ID over a longer period of time.
To test an SP with edu-ID before day-X, SWITCH can set up a staging IdP. In this scenario, selected users (who have to tweak their /etc/hosts file) can access a production SP with a production edu-ID account which is linked to a production organizational affiliation before day-X.
And the remaining 1% that is affected?
All that we said above applies to services using the classic attribute model - which is the compatibility mode of SWITCH edu-ID with traditional AAI IdPs. However, SWITCH edu-ID introduces many new features like the extended attribute model. To use some of the new features, an SP needs to change the implementation and configuration. The SWITCH edu-ID team happily supports SP developers and operators.
If an SP is not fully compliant with SAML or the SWITCHaai federation, adjustments will be required. One possible solution approach might be a proxy. Please contact the edu-ID team in such cases.