In December and January two new features were silently introduced for edu-ID organisation administrators. One provides graphical statistics and one allows restricting technical accounts to certain services. This blog post provides a short overview on what is new.Continue reading
Like described in the blog post Sending Users on the Right Path, it sometimes is in everybody’s interest to guide end-users on a certain path to achieve a goal. Such helpful nudges are also used during account creation when end-users choose how to create their SWITCH edu-ID account.Continue reading
In SWITCH edu-ID the e-mail addresses play a crucial role not only for communication with an edu-ID user but also for authentication. Every e-mail address associated to an edu-ID account also serves as login name. An e-mail address can also be used to reset the password of an edu-ID account. And unless Two-Step login is activated, this would be sufficient to gain control of an account.
Unfortunately, many e-mail addresses don’t belong permanently to the same person. When a student finishes her studies, she will loose her university e-mail address after some time. When a staff member changes jobs, he won’t keep his company e-mail address either.
In case of popular names, some organisations re-assign e-mail addresses to persons with the same name, hopefully only after a long grace-period. If such a “recycled” e-mail address is still associated to a user account of the original holder of this address in a system like SWITCH edu-ID, this might cause severe security problems.
Therefore, SWITCH edu-ID has some automated mechanisms to detect, remove, replace and inform about e-mail addresses that no longer work. How do these processes work?
As we have announced in our blog post “SWITCH edu-ID as door opener for libraries”, SLSP officially launches its new library service in December 2020, which relies on SWITCH edu-ID for user authentication and user management. With several hundred thousand expected users it is likely that the SLSP service will become one of the most widely used services with edu-ID/AAI in Switzerland. Therefore, the SWITCH edu-ID team is actively supporting the SLSP colleagues to optimally integrate it with edu-ID.
In this blog post we describe a few technical details and extensions that the edu-ID team implemented with and for SLSP. Last but not least, there is also a hint on what organisations can do to facilitate access to the SLSP service for their users.
Since a few months now, edu-ID users can secure their account with multi-factor authentication (Two-Step Login). However, currently 99.5% of all edu-ID accounts still rely exclusively on username and password authentication. It is unlikely to quickly change soon in the near future, despite the death of the password has been announced time and time again. The password remains the easiest, best known and – in many cases – the cheapest authentication solution. Therefore, the edu-ID team invests a lot of effort into assisting users to choose a strong password and to store it securely. Continue reading
Since December 2018 the edu-ID login has supported multi-factor authentication in form of a two-step login that relies on SMS codes. However, receiving one-time SMS codes requires a mobile phone. Not all users want to add a mobile phone number to their edu-ID account. Furthermore, SMS messages generally cannot be securely sent. There is always the risk that somebody else intercepts SMS messages. Some edu-ID users also want to use multi-factor authentication for all their edu-ID logins but without entering a one-time code several times per day.
To address the above issues reported by the community, we extended the edu-ID two-step login in the following three areas…
The edu-ID is a user-centric system in which users generally manage their account data themselves. And yet, some data relates to and is thus asserted by organisations like universities. Therefore, the edu-ID system provides several APIs for organisations so that they can manage data about users they are authoritative for. A new way to manage this data is the edu-ID administration interface for organisations, which is presented in this blog post.
A representative from a larger higher education organisation in Switzerland recently stated that they identify roughly 40 compromised user accounts on average per month. Extrapolating this number for all Swiss AAI users, this number would grow to more than 1’000 compromised accounts per month. Many of them are probably not even detected. Many of them probably belong to young students who may not always take proper care of their credentials. But every now and then, also staff members and professors learn about the nightmares of impersonation of their digital identity. So, how can edu-ID support SWITCHaai services to enhance authentication security? Continue reading
Have you ever invited professional burglars to break into your home to steal your valuables? For the edu-ID service we have done exactly that, and we even paid for it. The valuables in our case is identity data from all edu-ID users. However, the “professional burglars” were actually very kind, professional and skilled security experts from Compass Security.
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“.