ID Broker architecture

Download PDF

School authority components

3. School authority components#

In this chapter the components that communicate with the ID Broker system are described.

Service providers use the ID Broker for authentication and to retrieve information about logged in users. School authorities do the actual authentication and send their users data to the ID Broker. The ID Broker system provides interfaces for multi tenant authentication, user data storage and retrieval.

Interaction of components.

3.1. School authorities / schools#

Analogous to the ID broker system, the UCS@school platform also forms the basis at the school authority, on which various sub-components implement the required interfaces. The use of the UCS@school platform is a mandatory requirement.

The following UCS@school sub-components are relevant for the communication with the ID broker:

3.1.1. Identity management#

Together with other UCS core components such as UMC and UDM, OpenLDAP forms the identity management (IDM) at the school authority. All relevant school objects, such as schools, users and group memberships, are administered via the IDM.

3.1.2. Identity provider#

The identity provider (IDP) is also a module of UCS@school, which is responsible for the authentication of users. For this purpose, multiple authentication mechanisms such as OpenID Connect or SAML are supported by the IDP. The IDP can usually be accessed from the outside in order to connect external services to the UCS@school domain of the school board. In this scenario, the ID broker assumes the role of an external service, and makes appropriate authentication requests to the IDP. In order to answer the authentication requests, the IDP accesses the local user data of the IDM.

3.1.3. UCS@school ID Connector#

For the provisioning of the ID broker, another component is required, which is also part of the UCS@school platform. The UCS@school ID Connector offers the possibility to connect a UCS@school domain to another UCS@school domain (here the ID Broker system) and to provision it with user data.

To use the UCS@school ID Connector in conjunction with the ID Broker, the ID Connector Plugin is required.

3.1.3.1. ID Connector Plugin#

This plugin for the UCS@school ID Connector is triggered by changes in the school authorities IDM (LDAP), i.e. creation, modification and deletion, of all UCS@school users and school groups which are configured to be connected to the ID Broker.

Note

With version 1.3.18 of the package id-broker-id-connector-plugin the tool manage_schools_to_sync.py can be used to or and remove schools from the ID Broker. The new default is be that new schools have to be added manually. The old behavior, i.e. all current and future schools are synchronized, still works after the upgrade.

If a change is detected, the plugin uses the Provisioning API to modify the user data on the ID Broker. If an object is part of a school, which is not yet existing on the ID Broker, this school is created automatically on the ID Broker.

The plugin for the UCS@school ID Connector sends the following data from the school authority to the Provisioning API:

  • Users: Only UCS@school users are sent, “normal” users are ignored. The attributes sent are: entryUUID (a unique object ID in the IDM of the school authority), firstname, lastname, username and context. Where context is a structure that contains the names of the schools the user is a member of, the groups in those schools and the users role (student, teacher, staff) in them.

  • School classes and Workgroups: Only the school groups of users that should by synchronized are sent. The attributes sent are: name, description (display name), school and members.

  • Schools: Only the schools of users that should by synchronized are sent. The attributes sent are: name and displayName.

UCS\@school ID Connector and Provisioning API plugin.

Fig. 3.1 UCS@school ID Connector and Provisioning API plugin#

On this page