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.
Challenges in connecting 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:
- If an educational offer requires a personalized login, it should be done via single sing-on at the respective educational institution (school, state, school board), e.g., at the school portal.
- If additional account information is required, such as name, role, school, or contact information, the identity management system of the educational institution should pass on that information.
- If the educational offer requires information about the learning group (name/description of the group, group members, etc.), then these should also be transferred by the educational institution.
Consider Data Protection and Data Economy
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.
ID Broker: Design and Components
Let’s take a closer look at the Univention ID Broker. It basically includes these two features:
- Single sign-on with pseudonymization
- Interfaces (APIs) to transfer the learning contexts
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.