As a child of the 80’s, of course I have seen the movie “Highlander”. In our “clone wars” (referencing Star Wars) against edu-ID duplicate accounts, I therefore remember the famous high lander quote “there can be only one”. Slightly adapted, this quote fits: “There can be only one edu-ID account per person”. Thanks to the automatic merging process described in this article, we now have the weapon in our hands to reach this goal.
Duplicate user accounts on a single system are sooner or later causing a nightmare. One ambition of the SWITCH edu-ID has always been the prevention of duplicate user accounts. However, only a few weeks after the edu-ID launch in 2015 we already found indications for a couple of duplicate accounts. How did that come about and what can we do to prevent duplicate accounts?
In a previous blog post we presented how AAI Service Provider (SP) administrators can customize the edu-ID registration and login pages individually for their service. However, an SP administrator can not only brand the edu-ID pages with a custom logo or custom text but he can also influence the process itself used when users register, login or when they complete their account data. Examples of such process modifications are:
- To send a user automatically to a specific URL after registration or login
- To make a user first provide a specific verified or unverified attribute (e.g. mobile number or home postal address) and then send him back to the service
Both of these example scenarios have been used for instance by the Swissbib service for several months. Swissbib users sometimes have to provide a verified mobile number and/or postal address before they get access to national license content, which – by agreement – should be only available to residents of Switzerland.
So, how can an AAI SP administrator customize the edu-ID processes to implement the above and more scenarios? All that is needed is to send the user on the right path, or rather to the right URL. For all those not wanting to get familiar with the technical details of how these URLs have to be composed to achieve a certain process change, we have created a useful tool that makes the URL generation very easy: The edu-ID Login Link Composer.
The edu-ID Login Link Composer consists of a form with several inputs that are used to generate a link which triggers the requested behaviour. The user then just has to be sent to the generated URL to start the process.
Try out the edu-ID Login Link Composer with your own AAI service.
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.
At its meeting on 22 February 2017, the Swiss Federal Council opened a consultation on legislation on electronic identification (E-ID law, see announcements: DE, FR, IT). The consultation ended 29 May 2017.
SWITCH participated in this consultation and confirms the importance of a well-functioning and generally accepted E-ID. The identity service SWITCH edu-ID/SWITCHaai could potentially benefit from such an E-ID legislation: either to start offering an E-ID function itself, or by consuming E-ID services. Such use cases – from SWITCH and from other parties – may become important drivers for the spread of E-ID beyond pure e-government applications and for the emergence of an general-purpose E-ID ecosystem.
After evaluating the proposed delivery model in the draft E-ID-law, SWITCH proposes its revision. To ensure swift implementation and to reduce risks and complexity, SWITCH urges that the proposed market model be abandoned in favour of an implementation by the Swiss Confederation itself or by mandating it to a third party.
If the market model is to be pursued nevertheless, SWITCH proposes the use of a multi-stakeholder expert group to resolve the many open questions arising from the draft. If this group can not achieve its objectives, the market model is to be abandoned once and for all in favour of the proposed government-driven implementation model for an E-ID.
You are invited to read the full answer of SWITCH to the consultation (in German): 20170529 Vernehmlassungsantwort SWITCH E-ID-Gesetzesentwurf.
About 27,000 people have got mailing from the SWITCH edu-ID team April 19:
Instead of their former Cloud ID account, SWITCH edu-ID would be used as from 1st May 2017 in order to access the services SWITCHdrive and SWITCHengines.
But how should the vast majority of those users, who did not already have a SWITCH edu-ID account, come to such an identity?
Changeover without effort for 98% of users
The usual way to generate a SWITCH edu-ID account is self-registration – this in line with the principle of user centrism. However, in this case the new accounts were generated automatically in order to spare users effort.
Users who have linked their SWITCH edu-ID account with their existing AAI account(s) have substantially facilitated proper account assignment and account aggregation during conversion. Continue reading
SWITCHaai has a long and successful history in enabling access to hundreds of mainly academic web resources by reusing the authentication mechanisms at the heart of participating organisations.
When joining the SWITCHaai team a couple of years ago, I noticed two things about trust: a) it was just there, and b) no one talked about it. “Trust is established when no one talks about it anymore” someone said. It made me wonder how such a unique construction could be there and just work. There must have been many detailed questions that had to be resolved to get to that point! My curiosity was piqued, so, I started delving into this fascinating topic. How come all of these many service providers, identity providers, end users, organisations and federation partners, commercial or not, just do what the others would expect from them and don’t break trust?
Let’s start with an overview of the roles within an identity federation and their particular expectations towards each other and the federation as a whole. Continue reading