2. High level architectural overview#
Let’s have a high level look at the architecture. We have two diagrams explaining the same elements, and both diagrams are simplified. First we have a look at the participants, and after that we will learn about the action that is taking place.
2.1. Participants#
Fig. 2.1 Overview ID Broker#
- Student / Teacher
The person that wants to login and access resources the service provider offers. To customize the resources, the service provider requires the users name, school and group membership.
- School authority
The entity that manages student data. The school authority also has an IDP to authenticate students, and a school portal for the login link that the student uses. A limited amount of user data is sent to the ID Broker.
- Service provider
The service that contains learning resources, but no student data (for example Bettermarks). Login requests are redirected to the IDP of the school authority the user belongs to.
- ID Broker
The service that brokers student data and login processes. This allows integrating multiple learning resources and making them available to students of multiple school providers, without the service providers and school authorities having to communicate with each other. Service providers can retrieve metadata from the ID Broker about currently logged in users.
2.2. Components#
Now let’s uncover a few details.
Fig. 2.2 ID Broker components#
- UCS@school ID Connector
The UCS@school ID Connector sends selected user data from the school authorities IDM to the Provisioning API on the ID Broker.
- Provisioning API
The Provisioning API receives user data from school authorities and stores it in the ID Brokers IDM in a multi-tenant safe way.
- UCS@school IDP
The IDP of the school authority is the only one to ever see the users credentials. Authenticated users receive a ticket that they send to the SSO Broker.
- SSO Broker
The SSO Broker can validate the school authorities ticket and give the user a ticket to access a resource of the service provider.
- Service Provider
The user send the service provider this ticket, which it uses to retrieve data about the connected user from the Self-disclosure API on the ID Broker.
- Self-disclosure API
The Self-disclosure API provides the service provider with data about the connected user. The Provisioning API had stored that data earlier in the ID Brokers IDM.
- Redis
The Redis cache is used by the Self-disclosure API to increase it’s performance while accessing data about the connected user.