As a university member you usually have a unique role – you are either student, or teacher, or staff. In not so rare cases, however, a person has several roles at the same time, e.g. as a student and employee. How do universities deal with this situation today in SWITCHaai, and how is it covered in SWITCH edu-ID?
At universities, two typical approaches have been adopted to deal with people who have more than one role. In the first approach, people are given a single account in which all role information is grouped together. Alternatively, a university can issue several accounts to one person – one per role.
SWITCHaai perfectly supports both approaches. In the merged-roles approach the organizational IdP always issues an attribute set that expresses all roles using multi-valued attributes. In the separate-roles approach a user accessing to a service explicitly chooses one role by entering the corresponding credentials at the IdP.
By the way, there is no best approach. The merged-roles approach is easier to use because only one password has to be remembered, but services have to correctly choose the relevant role. The separate-roles approach is more transparent for the user who chooses the correct role depending on the context. It is also easier to implement for services. A recently conducted survey has revealed that both approaches seem to be equally popular at universities.
And how about edu-ID?
For SWITCH edu-ID it doesn’t matter which approach a university has chosen. It works well with both.
But how does it look for a user? A user who has merged all roles in a single account simply logs in with the edu-ID and is then redirected to the service. In the separate-roles approach the user also logs in to edu-ID but then the affiliation chooser kicks in, where the user selects the role to be used for the service.
Again the question: which approach is better?
Changing the way to deal with multiple roles is usually costly for an organization. When a university adopts SWITCH edu-ID at the organizational level it is therefore recommended to stick with the established model. It seems, however, that the separate-roles approach has the same advantages as in the SWITCHaai setup – without having its disadvantages. The user does not have to remember different passwords for different roles because all roles are linked to one edu-id identity. The affiliation chooser helps to pick the suitable role. With integrated edu-ID, the separate-roles model might be advantageous for organizations.
One word of caution for the separate-roles approach: SWITCH edu-ID needs to be able to distinguish the roles using the unique-ID which is defied by the organization. Special measures have to be taken to integrate the edu-ID at organizations which associate the same unique-ID to multiple roles.
To summarize: Universities have established identity management processes for their members who are wearing more than one hat. SWITCH edu-ID is able to support most of the existing processes. And finally, the integration of SWITCH edu-ID may be a good opportunity for a university to reconsider their role management processes, and make optimizations if necessary.