There are multiple approaches how an organizational user identity can be linked to the (personal part of the) edu-ID identity. For an organization that has integrated edu-ID - and is no longer operating its own IdP - it is required to establish a bi-directional link.
Organizational and edu-ID identity before linking
The bi-directional link for a user is established if
- the organization "knows" the edu-ID identifier of the user
- edu-ID "knows" the organizational-unique-Identifier of the user
After linking the organizational and the edu-ID identity, the edu-ID service creates a "current" organizational affiliation. The attributes in the current affiliation and the organizational identity are kept in sync - with the organization being the master.
Organizational and edu-ID identity after linking
These linking methods are currently supported by SWITCH edu-ID
- Organizational Registration Page
- Organizational Linking Service with AAI
- Organizational Linking Service without AAI
- SWITCH Linking Service with AAI
- Manual Linking via eMail
With this approach, the organization operates a public registration web page. The basic idea is to make sure users have an edu-ID before they register at the university.
On a public information page, the user is asked to proceed to a edu-ID-protected registration page hosted by the organization. The user gains access to that page by authenticating with the edu-ID. If the user does not already have an edu-ID, it can be created on the fly.
As a result the user is redirected to the registration page and the organization gets the user's edu-ID identifier which can be stored in the local directory.
Later, if/when the user has been admitted, the organization informs the edu-ID service about the new affiliation by calling the edu-ID affiliation REST API.
Check these details about the registration page.
In this approach, the organization operates a linking service (a web page). The basic idea is to have a user authenticate at the organization, and then also at edu-ID. If both authentications succeed the link can be established.
The user is asked to go to a local protected web page hosted by the organization. The user accesses that page by authenticating against the local directory. If the edu-ID identifier is known for the user, the link is already established and the user can stop. Otherwise, the user is informed that the link is missing and that it should be established by authenticating with the edu-ID. Users who don't have an edu-ID yet, it can create one on the fly.
As a result the organization gets the user's edu-ID identifier which can be stored in the local directory. To complete the bidirectional link, the organization informs the edu-ID service about the new affiliation by calling the edu-ID affiliation REST API.
The detailed process of an organizational linking service is described here.
This linking approach is similar to the above organizational linking service. The main difference is that the web page (edu-ID authn) that requires authentication with edu-ID is hosted by SWITCH and not by the organization.
This approach may be advantageous for organizations who do not want operate a Sibboleth SP just for the linking service.
The detailed process how an organization can obtain the edu-ID identifier in this scenario is described here.
SWITCH edu-ID has a built-in linking service that can be used by organization members, who have an organizational SWITCHaai account.
With this method, a user goes to the my edu-ID account page eduid.ch, chooses Create account and the proceeds with a common AAI login on the following page, as shown in the screenshots below. After successful authentication, and after the user has defined an edu-ID password an edu-ID account is created based on the attribute information of the user's AAI account.
To complete a bidirectional link between the organizational account and the edu-ID, a method should be established to send the edu-ID identifiers of linked users to the organization.
In the manual linking approach, an email containing a user's edu-ID identifier is sent to HR, who has to manually add it to the organizational directory. It is divided into the following steps:
- The user is asked to visit a linking web-page, hosted by SWITCH. the invitations may be sent by email, by printed letter or any other means.
- To access the linking page a user needs to log in with his/her edu-ID. An edu-ID may have to be created on the fly, if the user does not already have one.
- The linking page contains some organization-specific explanation text - plus one button.
- By clicking on the button, an email is sent to a pre-defined email address containing the name and the edu-ID identifier of the user. Typically, the email recipient is a service desk at the organization's HR departement.
- The HR department checks incoming emails for their legitimacy.
- If the emal is legit, HR manually copies the user's edu-ID identifier to the user record in the oganizational directory.
- To complete the bidirectional link, the organization informs the edu-ID service about the new affiliation by calling the edu-ID affiliation REST API.
Advantages of this approach:
- of all linking approaches, it requires the least technical extensions.
Drawbacks of this approach:
- it invoves manual interactions and consequently does not scale well and may be prone to human errors
- the registration page is difficult to protect. It could be misused to spam/DOS the email recipient
Linking methods compared
|Applicable to link future members||Applicable to link current members|
|Organizational Registration Page||At registration||-|
|Organizational Linking Service with AAI
|Before day X
After day X
|Organizational Linking Service without AAI||
|Before day X
After day X
|SWITCH Linking Service via AAI||-||Before day X|
|Manual Linking via email||
|Before day X
After day X