The TLS protocol secures the communication between a user’s web browser and a server running a web application. The user recognises a secured communication by the lock visualised in the web browser or the https prefix in a link.
The security protocols TLSv1.0 and TLSv1.1 are outdated and no longer rated as secure. Therefore, web server administrators should plan to properly protect their services by updating their web server configuration to require at least TLSv1.2.
To apply this security improvement to SWITCHaai including SWITCH edu-ID, SWITCH announces the upgrade in two phases.
Category: How-Tos
ZHdK starts the year 2020 with SWITCH edu-ID
Right at the start of the year on 8 January 2020, the Zurich University of the Arts (ZHdK) switched over to SWITCH edu-ID.
Smooth changeover thanks to good preparation and a high ‘linking’ success rate
Technically, everything was threaded perfectly and the changeover of the IdP went off without a hitch. After initialization and planning in 2018, the work could be started at the beginning of 2019 with the development of the connector, followed by the setup of the linking service and the migration of the IdP. The fact that everything went so smoothly was partly due to the fact that a large number of users had linked their accounts in time for the migration:
| Target group | Target value |
Success rate |
| Students | 60 % | 67.4 % |
| Lecturers | 60 % | 68.5 % |
| Midlevel faculty | 70 % | 83.1 % |
| Staff | 70 % | 79.1 % |
| Externes | 0 % | 5.3 % |
The communication measures were very successful with all target groups.
These consisted of a post in the Rectorate newsletter, a poster at the helpdesk, multiple e-mails sent to people without a linked account (maximum of three follow-ups and a final e-mail to users of the three most frequently used services), a message in the Rectorate newsletter shortly before the changeover, and detailed instructions on how to create and link the edu-ID account. E-mails were sent to the different groups of people in a staggered manner. This meant that support before and after the changeover to SWITCH edu-ID was uncomplicated and that the work involved was predictable and manageable.
Continue reading “ZHdK starts the year 2020 with SWITCH edu-ID”
NOT for university members only
FHNW e-media offering for teachers uses Shared Attribute API
In principle open
Openness is one of the promises made by SWITCH edu-ID. In recent years, universities have increasingly opened up to additional user groups such as continuing education students or MOOC participants. Cooperation with external parties is becoming increasingly important overall, be it with other universities, research institutions or partners from the private sector. Academic institutions are expanding their offerings, and not every person who makes use of university services has to become an official member of the university.
But that’s why you let everyone in?
However, most service providers do not simply want to blindly trust a self-declared identity that users bring with them (i.e. a “naked” edu-ID).
There are many reasons why one wants to protect applications and content from unauthorized access, e.g. to prevent data theft or manipulation or to comply with data protection or license regulations. And if abuse has taken place despite all precautions, one wants to be able to find out who one can hold liable for damages. Of course, this can be difficult with unchecked identities, even if the majority of users behave correctly and have provided the correct personal data for their digital identity. So is this a reason not to trust edu-ID identities?
Continue reading “NOT for university members only”
Trust & Identity WG Meeting / SWITCH edu-ID Update Event 2019
SWITCH invites you on Wed, 15 May 2019 to the 2nd Trust & Identity WG Meeting combined with the SWITCH edu-ID Update Event in Berne.
Registration is open until Tue, 7. May 2019 and required for logistical reasons.
Refer to the registration page for the draft agenda and schedule.
A longer section of the event is dedicated to SWITCH edu-ID. The heads of IT of University of Lucerne and Distance University will talk about their adoption experience.
Administrators of either an Identity Provider or Service Provider registered in SWITCHaai as well as the SWITCHpki registration authority operators and all persons involved in (future) planning and adoption of SWITCH edu-ID are invited to participate.
What’s the SWITCH Trust & Identity WG?
The SWITCH Trust & Identity WG comprises representatives of all SWITCHaai Participants and SWITCHpki Participants in the SWITCH Community and the Extended SWITCH Community.
This group is informally involved with the further development of SWITCHaai/edu-ID and SWITCHpki and has the opportunity to provide feedback if there are questions or changes upcoming.
Distance University too uses now edu-ID
On 6 March 2019, Distance University became the second university to switch to SWITCH edu-ID for authentication and access to its services. Here is an extract from their experience:
IT as a driving force
The project was primarily carried out by the IT department – supported by Marketing. All information had to be written in German and French. Student managers, who act as the first contact persons for teachers and students, were trained in advance by IT.
It took about 1.5 years from the initial discussions with SWITCH to the completion of the project. Distance University IT spent in total one man-month developing and testing the technical implementation. In addition, project management and communication were particularly time-consuming.
Information campaign as key
The Distance University launched an information campaign in the summer of 2018, thus persuading 75% of the university members to create an edu-ID account. The scenario “Linking before day X” was used for current users. The creation/linking of the account was simple and user acceptance correspondingly high.
Continue reading “Distance University too uses now edu-ID”
Two or More Factors for edu-ID
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”
There Can Be Only One!
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.
Sending Users on the Right Path
This blog post describes the edu-ID Login Link composer that allows initiating certain processes that an edu-ID user goes through to login, register or complete his user attributes.
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.
Apache Access Control Reloaded
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”
How to get the Organisation Display Name of an AAI User as “Free” Attribute
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?
Continue reading “How to get the Organisation Display Name of an AAI User as “Free” Attribute”
Simplify Shibboleth IdP Debugging: Quickly Identify Related Log Entries
“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.
Continue reading “Simplify Shibboleth IdP Debugging: Quickly Identify Related Log Entries”