Introduction

The CoreOne Authentication Service acts as a Identity Provider (IdP) for it’s Relying Parties (RP). In that role, the CoreOne Authentication Service authenticates the user and issues various tokens to be consumed by the Relying Parties. By default, this process is triggered by the relying party by initiating an authorization request. A user navigates to the desired Relying Party (1), the Relying Party then provides the user with a wide variate of resources such as weg pages. Some of those resources might be available to everyone and some only to authenticated users. As soon as someone tries to access a protected resource, the Relying Party initiates the authorization request (2). The user then authenticates against the IdP (3) and gets redirected back to the relying party at the end (4).

This is a widely simplified and not 100% accurate process description. This is just for illustrating the issue.

In cases with increased security measurements, this might not be enough. Let’s say we have a very sensitive Relying Party that can only be accessed by authenticated users. For security reasons we do not let the user access the Relying Party unless he is authenticated and we therefore need another protective layer in front of the relying party. This layer usually is implemented by a Web Application Firewall (WAF). The Web Application Firewall inspects all calls to the RP and checks, whether or not the user is authenticated. If not, the WAF can initiate a Pre-Authentication.

WAF Configuration with own client_id

To achieve the described pre-authentication, the Relying Party must be behind the WAF and the WAF itself must be registered as an ordinary OIDC client with the IdP. Once an incoming request to the RP is detected (1) the WAF checks if a previoius authentication has been performed by the user. This is typically detected by the presence of a cookie.

If the user is not authenticated, the WAF initiates an own authorization request and redirects the user to the IdP (2). The IdP then authenticates the user (3), issues a token (4) and sends the user back to the WAF by using the callback url. The WAF can now determinate the original request by the user and forwards him to the RP (5). The RP itself can then redirect to the IdP (6) where the user will have SSO and immediately gets an appropriate token (7).

WAF Configuration with dedicated client_id

If each client has a different level of authentication and other settings that depend on the the client_id, it's also possible that the WAF issues the authorization request with the client_id of the actual RP and passes the token directly to the RP after the authentication.