5. Interactions between components

The ID Broker architecture has been designed in a way that allows the users of multiple school authorities to securely access the resources of multiple service providers, without the school authorities and service providers having to communicate with each other. The users password is only send once to the IDP of its school authority. The service providers do not have to store any user information.

5.1. Authentication and user data retrieval

When a user wants to access a resource of one of the service providers, she needs to authenticate herself and the service provider requires some data about the user to provide an individualized service.

Fig. 5.1 ID Broker - connections

The service provider however does not do the authentication itself. It does not even know the name of the school authority the user belongs to or the address of its IDP. So the service provider redirects the user to the ID Broker which in turn redirects the user to the IDP of its school authority.

The ID Broker can verify the signature of the school authorities IDP and give the user a ticket. The user passes that ticket to the service provider, which can now retrieve data about the user from the ID Broker.

Fig. 5.2 ID Broker sequence: authentication and user data retrieval sequence (simplified visualization)

1. student data

The school authority syncs student data to the ID Broker.

2. request service provider login at school authorities portal page

The student clicks a link on the school authorities portal page, and gets redirected to the service provider. This redirection is necessary to make the combination of SAML and OpenID Connect possible - the ID Broker needs to know which SAML backend should be used.

3. request login

The student requests a login at the service providers page, and gets redirected to the ID Broker.

4. auth request

The ID Broker does not do the actual login, instead the student gets redirected to the school authority, which has an IDP (SAML) provider.

5. SAML auth

Here, the actual SAML auth happens, the student gets a SAML ticket, and is redirected to the ID Broker.

6. request auth_code

Using the SAML ticket, the user requests an auth_code from the ID Broker. The user gets redirected to the service provider.

7. auth_code, request content

The user passes on the auth_code while asking for the actual content page(s). The auth_code is exchanged by the service provider for an access token (this step is left out of the diagram for clarity reasons, but takes place in reality).

8. request student details

Using the access token, the service provider can now request user data from the ID Broker.

7b. content page

This is the continuation of step 7 - the student gets the requested content from the service provider.