Integrations - OpenID Connect Provider

Introduction

This article explains how the OpenID Connect Provider (OIDC) works, how to set up the workflow, and ways to test it. This information is useful to all clients and members. 

How the OIDC Provider Works

The responsibility of the OpenID Connect is to authenticate users through their Identity Providers (IDPS). This helps enable seamless integration into our system. Clients can have multiple OIDC implemented into our integration dashboard.

Workflow Setup

During the login process, the system uses Just-in-Time (JIT) Provisioning. This is an automated process that creates user accounts for web applications and services when a user signs in for the first time using a Single Sign-On (SSO) system.

Note: During the creation process, the main SSO strategy is using RG_Authentication_Provider_Strategy_Simple. For an Email Registration Criteria type scheme, the SSO strategy is set to RG_Authentication_Provider_Strategy_Username.

The Setup

1. Configuration Name

This will be the name of the OpenId Connect configuration. By default, the name will be used on the discount site on the login page. This step has validation to prevent the creation of two integrations with the same name.

 2. WellKnownURL

This URL provides necessary configuration details, such as endpoints and supported features, to facilitate secure integration with the authorization server. This step has validation to make sure the provided url is accessible and returns the correct response, or that it’s with the correct format.

 3. Scopes

 Scopes are used to request specific sets of information or permissions.

 4. Additional Parameters

Accept JavaScript Object Notation (JSON) is responsible for additional parameters as during the authorization phase, such as acr_values. This step has validation that isn't mandatory, but it only works if the provided JSON is with the correct format.

 5. Client ID

This parameter is used to identify the client.

 6. Client Secret

This is a confidential value that is used by the client (application) to authenticate themselves (itself) to the authorization server.

 7. Claims

Claims are pieces of information about the user that the client application can request from the authorization server. 

Note: The Claims Required fields are different for every scheme type.

Requirements

You need an Identity Provider (IDP) that supports OpenID Connect to handle authentication and authorization securely and efficiently. OpenID Connect is an identity layer on top of the OAuth 2.0 protocol, which allows clients to verify the identity of end-users based on the authentication performed by an Authorization Server. It also provides mechanisms to obtain basic profile information about the end-users. In this context, rg_auth can serve as such an Identity Provider, offering the necessary capabilities to support OpenID Connect for your authentication needs.

How To Test the Setup

1. To start the test, we need to run the identity on local (rg_auth)

2. We need to configure the Integration (for local)

WellKnownUrl: https://identity.rewardgateway.dev/.well-known/openid-configuration

Scopes: OpenID profile email

Client Id: openId_client

Client Secret: openidId-client-secret123

Claims:

Payroll Number: sub

ClientID and ClientSecret can be found in the data.yaml → (internal_oauth_clients)

Standard Claims 

Here, we are ensuring what fields we can return

 3. On the testing state, click on start test to successfully log in to enable the next button

Note that if the rg-core-integtrations-filebeat isn’t working in the rg_core container, it wont validate your login.

 4. Verify your changes and click save

 5. Open the Landing page on the scheme you enabled the OIDC

 6. Login with member from a different scheme