ID Broker manual for school authorities

Download PDF

In-depth

2. In-depth#

In section Authentication and user data retrieval we have a look at the steps, that users follow when they access a service registered at the ID Broker. The section SSO Broker covers the role and access points of the SSO Broker.

2.1. Authentication and user data retrieval#

One design goal of the ID Broker architecture is that the users of multiple school authorities can securely access the resources of multiple service providers, so that the school authorities and the service providers don’t have to communicate with each other. Users only login at their school authority. The service providers don’t store any user information.

When a user wants to access a resource of one of the service providers, they need to authenticate themselves. The service provider requires some data about the users to provide an individualized service.

_images/id_broker_overview.svg

Fig. 2.1 ID Broker - connections#

Fig. 2.1 above shows the connections between a student, the service provider, the school authority and the ID Broker. It redirects the user to the ID Broker, which in turn redirects the user to the IDP of its school authority.

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

The following Fig. 2.2 covers the interactions between the components in more depth.

_images/overview_sequence.svg

Fig. 2.2 ID Broker sequence: authentication and user data retrieval sequence#

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 is redirected to the service provider. This redirection makes the combination of SAML and OpenID Connect possible - the ID Broker must know which SAML backend needs to be used.

3. request login

The student requests a login at the service provider’s page, and is redirected to the ID Broker.

4. auth request

The ID Broker doesn’t login the student and instead redirects the student to the school authority, which has an IDP (SAML) provider.

5. SAML auth

The actual SAML authentication of the user happens. The student receives 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 is redirected to the service provider.

7. auth_code, request content

The user passes the auth_code to the service provider while asking for the content. The service provider exchanges the auth_code for an access_token and an id_token (this step is left out of the diagram for clarity reasons). The id_token contains the pseudonyms for the requested data, as well as, for the requesting user.

8. request student details

Using the access_token and the pseudonyms inside the id_token, the service provider can now request pseudonymized user data from the ID Broker.

7b. content page

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

2.2. SSO Broker#

In this section you learn about the architecture with focus on the SSO Broker and the single sign-on part of the ID Broker. The software Keycloak provides the functionality for the SSO Broker.

The main job of the SSO Broker component is to handle multiple-tenant authentication, using pseudonyms. This involves the student doing the login and passing authentication tokens back and forth.

SSO Broker communications

Fig. 2.3 SSO Broker communications#

The SSO Broker participates in the following communications:

  • The school portal redirects the student to the SSO Broker upon first login. This first step is part of the OpenID Connect (OIDC) flow. The SSO Broker redirects the student to the school authority’s IDP for SAML authentication. The student authenticates with a real user identifier. The student returns the SAML ticket to the SSO Broker, which they received in the authentication step.

  • The ID Broker IDM system provides a service provider specific pseudonym for the SSO Broker. The pseudonym also includes other user data from the school authority. The student receives an auth_code that is valid for the service provider specific pseudonym. The student sends the auth_code to the service provider.

  • The service provider exchanges the auth_code for both an access_token and an id_token at the SSO Broker. The service provider processes the id_token that contains the pseudonym. It uses the access_token to request more data about the student through the pseudonym at the Self-Disclosure API.

The SSO Broker is available:

  • for OIDC at https://FQDN/auth/realms/SERVICE PROVIDER ID/protocol/openid-connect

  • for SAML at https://FQDN/auth/realms/SERVICE PROVIDER ID/broker/saml

On this page