Date: Tue, 19 Mar 2024 08:07:05 +0100 (CET) Message-ID: <839162192.5227.1710832025623@wiki01p.surfnet.nl> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_5226_2120553598.1710832025623" ------=_Part_5226_2120553598.1710832025623 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
With OpenID Connect the trust is established out-of-band. This means tha=
t a network or channel separate from the primary network supplies the Servi=
ce Provider with a username and a secret. All the necessary technical infor=
mation such as endpoints, supported algorithms and supported claims can be =
found at the .well-kown
endpoint: https://connect.surfconext.nl/.well-known/openid-configur=
ation
SURFconext connects the SP and the IdP based on specific rules. Note tha= t SURFconext itself does not authenticate users: this is done by the connec= ted Identity Providers. This authentication flow in OpenID Connect is depic= ted below. Let's dive into this.
The schematic is a representation of the login flow of the SURFconext Op= enID Connect proxy.
A User accesses a Service Provider (Relying Party) and clicks "login= via SURFconext"
The Relying Party (SP) generates an OpenID Connect Authorize request= and
Redirects user to the OpenID Connect Authorization endpoint
OpenID Connect server receives request and prepares a SAML redirect = to authenticate the user
In order to determine where to send the user for authentication, SUR= Fconext shows the user a "Where Are You From?" (WAYF) page with all Identit= y Providers that have access to the service. The user chooses the instituti= on that is his Identity Provider.
the IdP generates a SAML response and redirects the user back t= o SURFconext with a response message, saying that the user is authenticated= . The message also contains the attributes from the user.
SURFconext validates the response message and if OK makes some alter= ations, e.g. rewriting the user's identifier and adding or modifying attrib= utes and sends the SAML response to the OpenID Connect gateway. According t= o the attribute release policy applied, SURFconext determines the attribute= s that are allowed through to the Service Provider.
The OpenID connect gateway verifies the response, generates a code, = and redirects the user to the Relying Party (SP) with the code
The Relying Party (SP) receives the authorization code
The Relying Party (SP) prepares a backchannel request to exchan= ge the token for an access and ID token
The OpenID connect gateway receives the token and checks the validit= y
The OpenID connect gateway generates an access and ID token
To get a feeling of how things work in reality, you can play around with= our playground: https://oidc-playground.surfconext.nl/<= /a>.