What does it take for a university to adopt the SWITCH edu-ID? This is the question SWITCH and seven partners (EPFL, FHNW, UNIFR, UNIGE, UNIL, UNISG and ZHAW) are addressing in the project “Swiss edu-ID Deployment Step 1” as part of swissuniversities’ program «Scientific information». The project advanced nicely and would justify an article on its own. But let’s draw your attention to an interesting side product of this project: we learned how electronic identities are managed in our community – and how the approaches are evolving over time and why.
Many of today’s IdM systems in our community were designed more than a decade ago. SWITCHaai went formally live in 2005 and required each university linking up to the federation to provide up to date information about all accounts in one system. But students and staff were usually managed by separate units in separate, isolated systems. They needed to be brought together. Additionally, the information provided needed to be reasonably up to date. This required some rethinking.
The approach chosen in most cases was to aggregate the relevant information directly from authoritative sources, i.e. the user management systems, into a single meta-directory in this way:
Let’s call this the “Meta-Directory” approach. It did not require substantial changes to the existing systems and processes and was therefore relatively simple to implement. This approach was a huge success and is probably the single most important success factor of the SWITCHaai as we know it today.
The downsides were well acceptable in the beginning and only started to hurt later on:
- Individuals with multiple roles (e.g. employees, who are also students) end up with two independent identities in the Meta-DB: the system is role-centric, not user-centric
- Individuals changing roles (e.g. from student to employee) loose their old identity and need to get re-registered to get their new one: again a lack of user-centrism, but also a lack of persistency
- Tracking individuals through multiple roles is difficult: the system lacks persistency
Well, we oversimplified a bit: Students and staff are usually the biggest groups, but we did not mention that there are more user groups out there to care about: How about continued education, guests, externals?
These shortcomings were definitely motivating the work eventually leading to the creation of the Swiss edu-ID concept and later on to the SWITCH edu-ID service. But are there ways to make the internal IdM-system itself more user-centric and persistent to overcome the shortcomings above?
Several universities address this in internal projects in an evolutionary or sometimes even revolutionary way by reversing the logic: instead of registering people in decentralised systems first (e.g. student and staff systems), they need now to get registered into the central leading system first and subsequently provisioned to the individual management systems. Only after that step can they be managed in the decentralised systems:
Let’s call this the “Leading System” approach. The leading system keeps track of all individuals and their changing roles over time: in doing so, it adds persistency and user-centrism.
But there is another incentive beyond persistency and user-centrism to go down that route: it has to do with agility and efficiency. To demonstrate this, let’s have a look at how business systems need to integrate when following the “Meta-Directory” approach:
The “Meta-Directory” approach leaves the bulk of work up to the business applications and user management systems when sorting out how to interconnect. It does not provide substantial added value. Let’s compare with business application integration in the case of a “Leading System” approach:
The “Leading System” acts as single point of contact towards both the business applications and the user management systems – thus reducing their “n times m” problem to an “n plus m” problem, when n user management systems need to interact with m business applications. This is a huge gain in agility, as it simplifies drastically the effort needed to add new, replace existing or decommission old business applications or user management systems. It is also more efficient to run, as the number of system-to-system interfaces is reduced and the knowledge can be pooled centrally around the provisioning engine. As a surplus, it empowers the central IT in their capacity as an integration orchestrator.
And what is the contribution of the SWITCH edu-ID? There is good news for organisations adopting the SWITCH edu-ID, whether they stay with the “Meta-Directory” approach or prefer the “Leading System” approach. And since the world is not just black and white, it will also work for all shades in between:
- Since all entries in the “Meta-Directory” will contain the SWITCH edu-ID identifier, it becomes very easy to spot entries belonging to the same individual. Since the SWITCH edu-ID is informed about those clashes as well, it will ask the individual – when required – with which role he or she wishes to connect to a given service.
- Since the entries in the “Leading System” of a partner are persistent, it is easy to recognise returning individuals, also after a long while. The SWITCH edu-ID took care of identity management tasks in the meantime.
- And as a bonus in both cases: Firstcomers might already be in possession of a SWITCH edu-ID and make onboarding much simpler: for the organisation, but also – and this should matter even more – for the user.