Become Part of our Team and Push Digital Sovereignty
- Teamleader IT / Project Manager (m/f/x)
- IT Consultant (m/f/x)
- Outbound Sales Represantative (m/f/x)
On May 11, 2022, we released the new Univention ID Broker to simplify the integration of educational portals and educational SaaS services (Software as a Service) in schools’ IT environments. The broker acts as intermediary service and connects UCS@school (serving as identity management system at school boards, states, and individual schools) with different external services, like learning management systems, digital media, and other educational offers. As a result, students and teachers can log in with their usual credentials to access their personalized and familiar environment. Here they get immediate access to all connected and enabled services (single sign-on).
The ID Broker’s special feature: it pseudonymizes user IDs and can, among other things, prevent real names and passwords from being passed on to the service provider. The new interface thus enables the use of digital education services in compliance with data protection laws. Nothing changes for the users—the broker works in the background and doesn’t affect them.
In this article, I’m going to give a detailed introduction to the Univention ID Broker, showing the advantages for educational institutions as well as for providers of school and learning software.
Many learning services and applications are available as Software as a Service (SaaS), which means that the respective service provider is hosting the service on its own servers. To make these educational services easily accessible for users in the identity management systems of portals and school boards is quite a challenge. On the one hand, there are numerous identity management systems (identity providers, IdPs) and, on the other hand, there are many educational services (service providers, SPs). To link them all together, each IdP must be configured with each SP. Connecting all parts is not only time-consuming, but also prone to errors and, in the case of some learning systems, not even possible at all.
The so-called learning context poses another problem, i.e., the users’ roles and their membership in learning groups. The respective educational portal defines the learning context, and it is essential that the service providers receive that information. A complete transfer of all personal data, however, contradicts applicable data protection regulations—only information of users who actually make use of the offer may be transmitted.
Of course, a new account with the correct rights and group memberships/roles could be created for each service. However, all accounts would then have to be maintained in multiple places—this is inefficient, requires a lot of additional effort, and results in a poor user experience.
Therefore, a successful integration requires that the respective learning context of the users is also provided:
The General Data Protection Regulation (GDPR) defines the processing of personal data. Among other things, it stipulates that only data actually required by the educational institutions may be transferred to the providers of the learning software. This means that data is only transferred when a user or teacher actually calls up the offer.
It is also important to ensure that unique identifiers for accounts and learning groups aren’t linked across different services. They have to be replaced by corresponding pseudonyms. It goes without saying that only relevant data may be exchanged in the process: if a learning software doesn’t benefit from information about learning groups, for example, then it shouldn’t receive it in the first place. In any case, educational institutions like schools, states, or school boards have to be in complete control.
As part of the single sign-on process, a broker takes care of the application-specific pseudonymization. It’s a separate, public service with its own hosting. The broker is connected to the single sign-on of the educational institutions’ portals. All other interfaces which exchange data with connected learning services can make use of that pseudonymization.
So, let’s talk about the technical implementation. The next section explains the ID Broker’s design in more detail.
Let’s take a closer look at the Univention ID Broker. It basically includes these two features:
Users log in to the educational institution’s portal once and are then granted access to all connected services and learning systems (single sign-on). The broker also takes care of the pseudonymization of user and group IDs. In addition, it provides standardized APIs for learning software providers. After successful authentication by the end users, learning contexts are transmitted.
The ID Broker transfers data to the service providers of educational software—but the educational institutions decide which data is passed on and processed. For example, this could be the user IDs (login), the first and last name, and the role; passwords or password hashes are not transmitted at any time. In addition, the broker receives information about the (learning) groups, i.e. the group identifier (name) and its members. As far as the schools are concerned, the school identifiers and the assignment of user accounts and learning groups are transferred.
Access to the educational offers is granted after the interfaces have been released by the educational institutions and only for users who actually log in. Nothing changes for the users: they log in to the respective portal as before, and after that they are offered access to services and applications.
At present, the bettermarks learning system is the first educational software connected to the Univention ID Broker. In summer 2022, the land of Bremen (as education provider) is planning to put the ID Broker into operation to provide teachers and students with easy access to bettermarks. Talks are already under way with other educational offers and educational institutions.
The German FWU (Institut für Film und Bild in Wissenschaft und Unterricht, Institute for Film and Image in Science and Education) is also working on a broker service. Its goal is to link existing identity management solutions operated by the German federal states with providers of digital material and services. The VIDIS project, Vermittlungsdienst (proxy service) for the Digital Identity Management in Schools, plans to provide a similar single sign-on service as the ID Broker. Univention is therefore collaborating closely with the VIDIS project and aims to migrate functions like the single sign-on to VIDIS, as soon as that system goes into operation. The ID Broker is also supplying information such as group memberships etc.—an additional benefit for the joint use with VIDIS.
Finally, I would like to address the issue of (de)anonymization. In future, it should be possible to integrate educational offers which are hosted in data centers outside the European judicial area. In that case, no user data at all may be transferred. All APIs of the Univention ID Broker have to make sure that only pseudonyms are transmitted to the educational offers, so the data is anonymized. Optionally, a HTTP proxy can mask the users’ IP addresses. For de-anonymization, another interface enables the users’ end devices (browsers) to obtain plain data (names). The respective web browser contacts the ID broker and receives the information from here—no provider will be able to process the data.
Educational institutions like school boards, states, and schools, as well as providers of learning solutions benefit from the Univention ID Broker: