🔑Configure OIDC authentication

Overview

This document outlines the steps to configure OpenID Connect (OIDC) authentication for a client application using the OIDC Discovery mechanism. The Discovery endpoint provides metadata for the OIDC Provider (OP), allowing dynamic configuration without manual entry of endpoints and other settings.

OpenID Connect (OIDC) is an authentication protocol based on the OAuth 2.0 framework. It adds a standardized identity layer on top of OAuth 2.0, enabling Single Sign-On (SSO) functionality. OIDC allows clients to verify the identity of users based on the authentication performed by an Authorization Server, and to obtain basic profile information about the user in an interoperable and REST-like manner.

Key terminology

To avoid confusion, let's define some key terms:

• The End User: The person who wants to log in.

• The Client (in this case, the Application, Curity): The entity that wants to authenticate users using OIDC.

• The Provider (also known as OpenID Connect Provider): The entity that provides the authentication services. It often has an Identity Provider associated with it, and is able to provide the user's identity information.

• The Identity Provider (in this case, the Provider): The entity that provides user identities and authentication services.

• The Discovery Document: A public JSON document that contains information about the Provider, including endpoints, supported scopes, and other metadata. Often accessible at https://<auth hostname>/.well-known/openid-configuration.

  • Example: https://accounts.google.com/.well-known/openid-configuration

Configuration

OIDC Provider side (Your Identity Provider)

Go to your OIDC Provider administration console and configure the necessary settings for OIDC authentication.

To configure OIDC authentication, you can follow these general steps:

1. Create an OAuth Client in your Identity Provider.

2. Set the Redirect URI to https://<auth hostname>/7bf98083-e4ff-4769-baa7-da4fde86d932/authentication/authentication/oidc/callback

   • 7bf98083-e4ff-4769-baa7-da4fde86d932 correspond the the helm chart default value global.tenantID. In which, it has no other function beside naming the tenant. This used internally at Toucan.

   • oidc (before the /callback) correspond to the name of the OIDC authenticator (see below), in the OIDC client configuration. If you plan to use another name, replace oidc by the name of the authenticator.

3. Fetch the client ID and client secret. Also fetch the Provider's discovery URL.

That's should be it! Of course, some OIDC providers might require additional configuration, but this should be the minimal requirements.

OIDC Client side (Curity)

Method 1: Using Helm

To configure OIDC authentication, follow these steps:

1. Create a secret with the client ID and client secret:

apiVersion: v1
kind: Secret
metadata:
  name: sso-secret
  namespace: <namespace>
type: Opaque
stringData:
  client-secret: '<client secret>'

Deploy with kubectl apply -f sso-secret.yaml.

1. In the Helm Charts, set these parameters:

curity:
  config:
    sso:
      authenticators:
        - id: oidc # Influences the url, see above
          type: oidc
          configurationURL: 'https://sso.example.com/.well-known/openid-configuration'
          scopes: openid profile email
          clientID: '<client id>' # From above
          clientSecret:
            secretName: sso-secret
            secretKey: client-secret

1. Deploy the Helm Charts (helm upgrade -f ./values.override.yaml ...).

Method 2: Using the UI

To configure OIDC authentication, follow these steps:

1. In the Helm Charts, make sure the admin interface is accessible:

curity:
  admin:
    ingress:
      enabled: true
      ingressClassName: nginx
      hostname: <auth hostname>
      path: /admin
      tls: true

And deploy it (helm upgrade -f ./values.override.yaml ...).

1. Fetch the credentials for the admin interface:

# The secret may be named something else based on your configuration.
kubectl get secret --namespace toucan toucan-stack-curity -o jsonpath='{.data.curity-admin-password}' | base64 --decode

1. Access the UI at the following URL: https://<auth hostname>/admin and use the credentials admin as username and the password you got from the previous step.

2. You should be at the home page. Go to the Profiles tab () and select the first section () of the first profile.

   
3. Go to authenticators:

   
4. Push the new authenticator button .

5. Name it oidc and the type is Google .

6. Replace the fields:

   • Configuration URL: The provider discovery document URL

     • Example: https://accounts.google.com/.well-known/openid-configuration (it should end with .well-known/openid-configuration)

   • Client ID: The client ID fetched from the provider

   • Client Secret: The client secret fetched from the provider

   • Scopes: openid email profile (the discovery document will tell you the available scopes)

   • 

7. We'll need to setup some Login actions:

8. default_create_account:

   1. Click on Add Action on the right side of Login. 2. Select Default_create_account

9. Do the same:

   • default_copy_attribute

   • default_lookup_account_by_email_to_action_attributes

   • prepare_tenant_id_workspace_id

   • prepare_update_user_from_sso

   • default_update_user_from_attributes

10. At this point, it should looks like:

    
11. Commit the changes:

    

The actions create the user in the Curity user database and provision permissions in the layout service.

By default, users coming from SSO are given admin privileges. You can change the behavior by editing the values in the Helm Charts:

curity:
  config:
    sso:
      permissionsProvisioning:
        isAdmin: true
        # list of strings (names of groups)
        groups:
          []
          # - group-1
          # - group-2
        # map of string (app name) -> string (permission)
        # available permissions are 'view', 'edit'
        appPermissions:
          {}
          # app-1: 'view'
          # app-2: 'edit'