Back in 2016, Daniel Lutz showed how the Shibboleth IdP can offer a real SSO feeling by reusing an already existing authentication token on domain-joined windows clients. SWITCH has now extended this concept in order to offer it to all organisations that have migrated to the SWITCH edu-ID.
Today, with the going live of SLSP we have seen quite a few thousands SWITCH edu-ID accounts being created. This amount was considerably more than we have seen in the past. While the SWITCH edu-ID infrastructure kept working for those who had created their account already before, some users who created their account today before noon, had to wait a couple of minutes until their account was ready to be used to log into swisscovery.
We apologise for this inconvenience and ask our customers to try again.
Starting from around 12:10 today, operation goes smoothly again, meaning that newly created accounts can be used for login right away.
Here’s a couple of pictures to show what actually happened:
We thank our customers for their patience within this period of time. In case someone created more than one account – while assuming that a second one might work better – we strongly recommend to merge these two accounts back again.
Do you have question? Please contact us at email@example.com
Two and a half weeks before the semester start, a message went through the SWITCH internal chat saying that the 250’000th SWITCH edu-ID account had just been created! We actually assumed that this would happen only a few weeks later. However, apparently many new students from universities that have already adopted the SWITCH edu-ID, recently created their proper edu-ID account. This went so smooth that we didn’t even notice it, at least not from the number of tickets in our end user support queue, which showed only a minimal increase.
But this was not the only record to celebrate. On the second day of the new semester, 1594 new accounts were created within 24 hours. This number is 40% higher than the old record from exactly one year ago.
We have indeed been very busy in these last weeks increasing the scalability of the SWITCH edu-ID service and its components. The most important component is the IdP, as it has to be up and running 24×7, regardless of the load that the end users bring when logging in to their services. I’m very happy and relieved that this service could be put behind a load balancer, and that it received a twin worker node to start with. More such worker nodes can from now on easily be added if necessary. With this scalability increase, our infrastructure was able to stand the load increase that came along with the semester start, see the figure:
We are hoping that our service will continue to run so smoothly and we will do whatever is necessary in order to keep up with the increasing demands of our user.
eduroam is the well known and widely used, worldwide high-performance wifi access service from GÉANT. Eduroam profiles for a large variety of end user devices are now also available on the eduroam.ch portal.
Today, on 1st December 2019, the eduroam.ch service enters its pilot phase. Within the four months to come, SWITCH will find out whether this enduser-friendly service actually responds to a need of the Universities or not. eduroam.ch uses your SWITCH edu-ID for authentication, and lets you download a profile for each of your devices in a user-friendly way. These profiles are somewhat special in that they solve a typical BYOD problem. Today’s profiles obtained by eduroam.ch won’t connect you to inner V-LANs, but only to a generic or “guest” V-LAN, as on any other Campus.
Two Universities joined the pilot already right at the beginning. Others, as well as further organisations like e.g. Alumni associations, may join during the whole pilot phase until 31. March 2020. Participation in the pilot is free, and Universities can use this service in parallel to their specific existing eduroam profiles and infrastructure.
Organisation wanting to join, contact us at firstname.lastname@example.org. The same contact point answers also all further questions you may have about the service.
Less than 8 months after reaching 100’000 accounts, the SWITCH edu-ID can already celebrate its 150’000st account! Of course, we got a cake (again!) and of course, we took a picture (again!). Around the start of the semester in September, we have seen days where more than 1000 persons registered their SWITCH edu-ID!
In the late evening of February 25th, a prospect student registered at ZHAW and thus created a personal SWITCH edu-ID account. This account turned out to be number 100’000 !
The SWITCH edu-ID team is very happy to see an increasing uptake of this new service. It is user-centric and centrally managed. It is assisting the universities and their IT departments in their daily work.
On every day in the past few months, about 200 new edu-ID accounts have been created on average. About 40% of the users actually link their edu-ID with their AAI account provided by university.
Btw: the prospect student has not yet responded to our call, so we couldn’t share this cake with her yet.
This is a core promise of the SWITCH edu-ID: An individual should be able to use one single digital identity to authenticate, while at the same time being able to choose the appropriate organisational role – or, using a more technical and precise term, the appropriate affiliation – in which to enter a service.
For members of organisations which have already adopted the SWITCH edu-ID, this concept has now arrived in the real SWITCH edu-ID world. The module called “affiliation chooser” is now executed right after authentication. It lets the user choose the appropriate affiliation, before consenting to attribute release and service access.
The affiliation chooser is intended as an intelligent replacement for the well-known discovery service (WAYF). The good thing about the affiliation chooser is that it knows when to show a choice at all. Unlike the WAYF, it only bothers the end user with its question when it really needs to. If e.g. the end user has only one affiliation, then there’s no real choice. Most edu-ID users have just one single affiliation to an organisation, if at all, which is then the one to present to the service. On the other hand, if the service allows only one affiliation, then again, this is the one to check against, even in the rare case when the user has more of them. In a more complex scenario, the affiliation chooser would actually do some set operation. The intersection of all affiliations the service is intended for, with all affiliations that an end user has, may actually contain zero, one, or more items:
- If no affiliation remains, then the user, although correctly authenticated, cannot be admitted to the service, as none of his affiliations would fit. This check is now being done by the edu-ID IdP, before the user is sent to the service.
- If there remains exactly one out of this intersection, then it’s the one to choose. No need to bother the end user with a choice if there’s just one item to choose from.
- If multiple affiliations remain, then this is where the end user actually sees something. A dialog box similar to the one in figure 1 is shown, and the end user has to choose the affiliation – given by a certain set of attributes – to present to the service. Based on these attributes, the service can then assign the appropriate privileges and access rights.
Figure 1: The Affiliation Chooser
What’s in for the end user?
Once the organizations the users are affiliated with adopt the SWITCH edu-ID, the end users will see much fewer possible choices in the affiliation chooser than they currently see in the discovery service. At the point of writing this article, only SWITCH has adopted the SWITCH edu-ID, therefore this currently only applies to SWITCH staff members.
What’s in for the services?
When registering with the federation, services declare their “intended audience”, and thus give an upfront indication about which organizations users must have an affiliation with, in order to be allowed on the service. This indication is picked up by the affiliation chooser which then puts it into an intelligible form and thus helps in pre-filtering the users arriving at the service.
Certain services allow for “private identities”, i.e. without any affiliation to an organisation. In that case, the affiliation chooser flags this possibility separately. Figure 1 shows this as “Private Person” option.
Future services might be able to cope with more than just one affiliation at a time, as the “extended attribute model” in the Swiss edu-ID Architecture suggests. For such services, the affiliation chooser won’t be needed, as no affiliation would have to be chosen at that point.
Are you running a Microsoft Windows Service (e.g. Sharepoint) with non-public content connected to your organisational Active Directory (AD)? Do you want to make content available to specific external users, e.g. users with a SWITCH edu-ID? This article is for you.
While Windows Authentication remains based on Active Directory Servers, the gap between the Windows and the Shibboleth world has become bridgeable, thanks to new features in ADFS 2016.
Imagine yourself running some Microsoft Windows service such as a Sharepoint instance. You probably need to configure external authentication. This is, and always was, straightforward if you can attach Active Directory Servers to the Sharepoint instance. However, it used to turn out a bit more cumbersome if you wanted to base your external authentication on a non-Windows service like e.g. a Shibboleth IdP. In short, supporting regular SWITCHaai was difficult for Windows services.
Thankfully, this has changed. ADFS 4.0, being a part of Windows Server 2016 has improved interoperability with SAML 2.0, which allows for use of a Shibboleth IdP when serving authentication requests from Windows services.
Peter M. Studer, one of the Identity Management (IdM) specialists at the University of Bern, has recently posted a blog (in German), which explains in detail how to deploy an ADFS server as a proxy to an IdP within SWITCHaai, in particular as a proxy to the SWITCH edu-ID IdP.
We find this step-by-step tutorial extremely helpful and will set up an appropriate proof of concept locally. This may be a first step towards integration of SWITCH edu-ID authentication for Windows services. If you are interested in learning more about the proof of concept, please contact us!
 IdP: Identity Provider
P.S.: There’s – at least – one more thing that has to be sorted out before such an idea can go into production: the metadata signature check. Any resource in a federation needs to properly link into the trust chain, something which is well prepared for resources based on Shibboleth software, but can be hard for others – yet.
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