Just in time for the yearly Trust and Identity Workgroup meeting the barrier was broken mid May. To celebrate the 700’000th edu-ID user account the trust and identity team had, however, to wait a few more weeks, because several team members were on vacation at that time. But it’s never too late for cake 😀
Lifelong learning benefits from lifelong user accounts. SWITCH edu-ID accounts are such lifelong user accounts. However, lifelong sometimes does not mean forever, which may be a surprise in this context. Why is that so?
Due to data privacy laws a life long account is – like a lifelong prison sentence – not for all eternity. At some point an account is deleted or archived even though its owner is still alive and well.
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.
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.
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?
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 timeagain. 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 “Secrets of the edu-ID passwords”
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 “Two or More Factors for edu-ID”
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?
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.
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 “Apache Access Control Reloaded”