The provision and maintenance of the schools’ master data are one of the most challenging issues in digital school administration. How do you manage to have complete, up-to-date user data available at any time, in any system, without manual and error-prone maintenance? At Univention, we have taken on this challenge and developed the UCS@school ID Connector to synchronize school identities on several independent UCS@school IDMs.
How the ID Connector works
The ID Connector transfers user data, like user names and passwords, in real-time from the main UCS@school instance to any number of other UCS@school instances. That allows for many different application scenarios. This article will focus on the networking of a state administration with several authority systems, each of which has UCS@school installed.
From main to target system
In such a scenario, the main-system is fed, for example, from a nationwide school administration system in which all pupils and teachers list their names, school, and class affiliations. From there, digital identities are automatically transferred to the individual school management systems, reducing administrative efforts. The UCS@school instance of the state has the ID Connector installed, which gains access to the LDAP structures and, thus, to the user data. The connector is configured via an HTTP API.
If new users or groups are created, deleted, or modified in the LDAP, the ID Connector listener – a python script of the ID Connector – is triggered, and a JSON file notes down the ID of the changed object. That forms a lightweight queue which a converter processes. By using the object ID (entryUUID), the converter fetches the current information from the LDAP, creates a JSON representation of the object, and places it in a queue.
Another Python process reads out the JSON documents one by one, fetches further data from the LDAP if necessary, and then decides to which school authority system an object should be transmitted. The data is spit into separate folders for each recipient system. A mapping file – another JSON file in which all schools are assigned to the corresponding carrier – helps with the assignment.
Finally, the Kelvin ID Connector Plugin distributes the data to the carrier instances. For the target instances to receive incoming data, the UCS@school Kelvin API must be in place, which writes the new data to the target system.
Mapping of attributes
You can use configuration files to freely define whether all attributes of one identity are transmitted or only a subset. The same applies to the attributes into which you write information in the target system. Please note that some attributes are mandatory for the Kelvin API, and you must include them. Thus, you can configure different mappings for each school institution, and if you add more institutions, it is possible to add more mapping files at any time.
Conclusion
Using the ID Connector ensures smooth cooperation between states, providers, and schools. The reliable automatic data transfer reduces the potential for errors and the existence of different data sets in the connected systems. The mapping also allows a high degree of customization, which makes many application scenarios possible.
Like many other useful apps, you can download the ID Connector from our App Center. Also, it is included as a product component in the UCS@school subscription. You can find the complete documentation at https://docs.software-univention.de/ucsschool-id-connector/index.html.
In addition, your contact person from our Professional Services team will be happy to advise you on this topic and analyze whether the ID Connector is suitable for your infrastructure.
