In everyday university life we frequently encounter a wide range of different software. Most institutions work with several services to make day-to-day tasks easier for staff and students and to make the most of their digital teaching provision. Now imagine we needed separate login details for each of these services. We would have one password for Opencast, another for BigBlueButton, one for LEIHS and yet another for our university’s LMS. Each of these services would have its own user management system. It’s confusing – and it quickly leads to sticky notes on monitors, giving anyone walking past access to sensitive areas.
From a technical perspective, things also become difficult when numerous different logins exist in parallel. Consistently implementing central requirements – such as mandatory two-factor authentication – becomes virtually impossible.
That’s precisely what central login services are for. They ensure that authentication is carried out in one central place, with the connected services receiving the information they need from there. This means users only have to log in once via the central identity provider. They can then access all linked applications without having to sign in again – and only need to remember a single password.
A two-factor authentication system can also be activated centrally and used across all connected services. In addition, services that use the same central login can be integrated far more easily from a technical standpoint. How this works in practice and the specific advantages it offers are explored in more detail below.
Anyone working in universities or educational institutions is most likely to encounter Shibboleth when it comes to central login services. It is not a login method in itself, but a software suite that implements standards such as SAML 2.0 Web Single Sign-On . Within the German-speaking higher education context, Shibboleth is one of the most widely used systems.
To use central login services, university IT centres operate a so-called Identity Provider (IdP). This IdP is the essential prerequisite for connecting services such as Opencast, Stud.IP, or other applications via Shibboleth. Most universities already have an IdP in place, which significantly simplifies the integration of new services.
Of course, Shibboleth is not the only SSO solution universities can use. There is also the Central Authentication Service (CAS), for example, which has been in use at some universities for years – although it is less common in the German-speaking region.
Also relevant is OpenID Connect (OIDC), an authentication layer based on OAuth 2.0. This combination is often used in modern web applications and can also provide SSO functionality.
Due to Shibboleth’s widespread use in the higher education context, we have chosen to focus on this solution in this article.
Few topics are as important in the context of login services as data protection. How secure are central login services – and Shibboleth in particular? After all, the authentication processes for many services run through a single central point.
Let’s walk through a practical example to make this clearer: A user logs in for the first time to a connected service via Shibboleth. The service recognises that it doesn’t yet know the user and redirects the login process to the Identity Provider. There, the user authenticates – for example, using a username and password plus two-factor authentication. Crucially, the password is never shared with the service. Instead, the IdP sends a token containing selected attributes, such as the university ID, email address, or other authorised information.
Which attributes the service receives is configured centrally and provided only to the extent necessary. Many universities also use a consent feature, allowing users to approve the sharing of certain attributes – though this is optional and depends on the individual institution.
Shibboleth is based on the open standard SAML 2.0 (Security Assertion Markup Language). This standard was specifically developed for federated, cross-domain Single Sign-On. Users authenticate once with the Identity Provider and can then access additional services using this verified authentication.
In the Shibboleth context, there are two key components: the Identity Provider (IdP) and the Service Provider (SP).
There are two typical ways to log in:
The switch between the service and the IdP happens via redirects – most users barely notice this, as the process is designed to be fast and seamless.
A major advantage: a single Identity Provider can serve multiple services – and individual services can, in turn, support multiple IdPs. This makes it possible, for example, for an Opencast server to accept users from different universities.
For universities, there is also the DFN-AAI Federation (Authentication and Authorization Infrastructure). It is not a central login point, but a federated trust framework. Universities register their IdPs and SPs there, allowing services and institutions to access each other’s trusted metadata. This is what makes seamless use of cross-university services possible.
Authentication does not automatically imply authorisation. Shibboleth itself handles authentication and the provision of attributes. Actual authorisation – that is, which rights and roles a user has within a particular service – is determined by the Service Provider or the respective application system.
During authentication, the IdP verifies that the user is who they claim to be. The service then sees the provided attributes (e.g., role, status, or group membership) and assigns the corresponding rights. For instance, students have different permissions in Opencast than teaching staff – but this assignment occurs within the service, not centrally in Shibboleth.
