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.
How to ensure that only staff members of my group in my organisation can access team documents via the web and only if they are connected via the organisation’s office network? And how to implement this without writing code? Thanks to Apache, Shibboleth and a SAML-based federation like SWITCHaai, these not so uncommon real life requirements are easy to implement. At least, once one has understood how user attributes can be used for access control. This blog entry demonstrates how to create such access control rules. Continue reading
Have you ever wanted to show the organisation name of an authenticated AAI user in the web application protected by a Shibboleth Service Provider? For example on an event registration web page in order to see from which organisations users registered or – like in the screenshot below – to show the authenticated user himself with which – of potentially many – AAI account he has logged in?
AAI is not only used within Switzerland. As of today there are 44 production and 17 pilot identity federations like AAI known around the world. 34 of the production federations are also part of the interfederation service eduGAIN, which interconnects these federations and allows AAI users of Interfederation-enabled Swiss institutions to access AAI services operated in other eduGAIN federations. Vice versa, AAI services in SWITCHaai (e.g. operated at CERN) now also be easily opened to and accessed by users from other eduGAIN federations.
Using AAI across national borders is in particular useful for research projects whose participants often come from different countries in the world. How research can benefit from eduGAIN and how SWITCH in the context of the GÉANT project is helping research projects to make use of AAI internationally is described in a new SWITCH story called “The recipe for cutting-edge international research“.
“Why isn’t it possible to easily identify all log messages belonging to particular user that authenticated at a Shibboleth Identity Provider?” This question was asked at the SWITCH Shibboleth Training in June 2015. Many other Shibboleth Identity Provider (IdP) administrators acknowledged they miss such a useful feature too. It would make debugging Shibboleth login issues easier since parallel user logins at the IdP result in many log entries that become a challenge to analyze. By default, the IdP does not provide enough log information to identify all related log entries for a particular login attempt.
The answer to this question is: This is possible! It’s in Shibboleth already and it’s easy to use but it is a bit hidden. There are two key ingredients needed to activate this.