Aller au contenu

Client oidc

Description

Ce client permet l'authentification par OIDC.

Il implémente une solution d'authentification indirecte (pour l'authentification des utilisateurs physiques au travers d'un formulaire de login mis à disposition par le fournisseur d'identité) et directe (pour l'authentification des services web au moyen d'un token JWT).

Type d'authentification OIDC

Le présent client ne prend pas en charge OpenID (Connect) Federation.

L'authentification dont il est question ici est une authentification en relation directe (bilatérale), c'est-à-dire une relation où le client (RP ou Relying Party) connaît explicitement son fournisseur d'identité (OP ou OpenID Provider). Elle est donc adaptée à une configuration avec un IdP de type Keycloak, Azure AD, etc.

Paramètres

Paramètres requis pour la configuration de l'authentification indirecte :

clientId obligatoire
Nom du client id
clientSecret obligatoire

Secret rattaché au client id.

Nous rappelons ici que la valeur peut être chiffrée. On l'indiquera alors en ajoutant un attribut encrypted="true" à l'élément dans le fichier XML.

discoveryUri

URL de discovery fournie par le serveur OIDC.

Exemple: https://adfs.domain.com/adfs/.well-known/openid-configuration

useNonce
Valeur true/false indiquant le nonce doit être utilisé
withState

Valeur true/false indiquant si un paramètre OAuth state est utilisé.

Par défaut la valeur est true.

authMethod

Méthode d'authentification. Les valeurs reconnues sont:

  • client_secret_basic
  • client_secret_post
  • client_secret_jwt
  • private_key_jwt
  • tls_client_auth
  • self_signed_tls_client_auth
  • request_object
  • none

Cette page fournit davantage d'informations sur les différentes méthodes.

scope
Scope. Il est possible de spécifier plusieurs scopes en les séparant par un espace, par exemple: openid profile roles.
algo
Définit l'algorithme JWS de préférence
responseType

Valeur du response_type. Il est possible de spécifier plusieurs valeurs en les séparant par un espace. Il existe généralement trois variantes possibles de valeurs pour cette propriété:

code
Flux standard en mode autorisation
id_token token
Flux implicite
code id_token token
Flux hybride
callUserInfoEndpoint

Flag true/false indiquant si le client OIDC est autorisé à invoquer l'endpoint /userinfo.

Le flag est true par défaut. Il peut être utile de désactiver cet appel sur les anciennes version d'AD FS (antérieures à 2019).

disablePkce

Flag true/false permettant d'activer/désactiver le mécanisme PKCE (Proof Key for Code Exchange).

Le flag est false par défaut et ne devrait pas être modifié. L'option est définie essentiellement pour permettre le debug.

maxClockSkew
Décalage de temps max en secondes autorisé entre les serveurs (serveur d'application et serveur AD FS). Par défaut le décalage toléré est de 30 secondes.
uidAttribute

Nom de l'attribut contenant la valeur à reprendre comme uid.

En principe, l'attribut est cn ou commonname. À définir en fonction du provider d'identité.

cleanUid

Flag true/false indiquant si le uid doit être "nettoyé".

Selon le provider, il peut arriver que le uid contienne des éléments superflux pour les besoins de l'application. Il peut par exemple avoir la forme AD\user ou user@ad.hostname.com. Le fait d'activer l'option cleanUid fera que le uid sera nettoyé des éléments spécifiques à l'annuaire.

Sans effet si uidAttribute n'est pas spécifié.

rolesAttribute
Nom de l'attribut contenant les rôles. En principe les rôles sont fournis dans des attributs roles, memberOf, etc. À définir en fonction du provider d'identité.
cleanRoles

Flag true/false indiquant si les noms de rôles doivent être "nettoyés".

De même que pour le uid, les rôles peuvent être fournis sous une forme inadaptée. Dans le cas d'ADFS par exemple on recevra les DN (distinguished names) des groupes, par exemple CN=MyGroup,CN=Users,DC=ad,DC=epilogic,DC=ch. L'option permet d'extraire le nom du groupe de ce DN.

Sans effet si rolesAttribute n'est pas spécifié.

customParam

Ajoute un ou plusieurs paramètres supplémentaires qui seront repris dans l'URL d'authentification.

L'élément doit posséder un attribut name qui indique le nom du paramètre et une valeur. Cette dernière peut être chiffrée (mais pas le nom du paramètre).

repository

Référentiel(s) sur le(s)quel(s) s'appuyer pour mettre à jour les profils utilisateurs.

Il est possible de spécifier plusieurs référentiels en les séparant par une virgule.

connectTimeout

Délai d'expiration de la connexion. Ce timeout correspond au temps maximum autorisé pour établir la connexion initiale, c'est-à-dire pour terminer la négociation TCP.

Cette valeur sert à éviter une attente infinie lorsque le client doit obtenir des données de serveur d'authentification (par exemple pour obtenir la configuration ou pour renouveler les clés de chiffrement).

readTimeout

Délai d'expiration de lecture. Ce timeout correspond au temps maximum autorisé pour attendre la lecture des données. Si l'obtention du payload est plus long que le délai indiqué, une erreur de délai d'expiration de lecture sera générée.

Cette valeur sert à éviter une attente infinie lorsque le client doit obtenir des données de serveur d'authentification (par exemple pour obtenir la configuration ou pour renouveler les clés de chiffrement).

Paramètres requis pour la configuration de l'authentification directe :

directClientName
Nom du client direct. Le fait de définir un nom active le mode d'authentification direct. Si le paramètre est absent ou vide, le client direct n'est pas instancié.
directUidAttribute
Nom de l'attribut à reprendre du token pour identifier le service client. Par défaut, le module recherche l'attribut "sub", mais il y a de grandes chances que le token ne contienne pas cet attribut (car le client direct est généralement utilisé pour identifier un service et non un utilisateur physique). Le module se rabat alors sur l'attribut indiqué.
Si la valeur est rnd:## est un nombre positif non nul, le module génère un id aléatoire de la longueur indiquée.
directRepository

Référentiel(s) sur le(s)quel(s) s'appuyer pour mettre à jour les profils utilisateur en cas de mode direct.

Il est possible de spécifier plusieurs référentiels en les séparant par une virgule.

directRoles
Rôles à assigner au client connecté en mode direct. Le paramètre attend une liste de rôles séparés par une virgule. Le paramètre remplit en quelque sorte un rôle analogue à directRepository dans le sens où il permet de rajouter des rôles au profil utilisateur, mais ici les rôles sont ajoutés de façon uniforme pour toutes les connexions via le client.

Exemple

Exemple de fichier configuration ewtAuthConfig.xml pour un client oidc combinant les modes indirect et direct.

<?xml version="1.0" encoding="utf-8"?>
<config>
    <!-- Fichier décrivant les référentiels et les méthodes d'authentification
         supportées (appelées "clients" dans la nomenclature de pac4j). -->
    <callbackUrl>${env:EWT_AUTH_CALLBACK_URL}</callbackUrl>

    <repository name="script-file-repo-direct" type="script">
        <script>auth/findApplication</script>
        <application>unittest</application>
    </repository>

    <client name="myoidc" type="oidc">
        <clientId>4cabe33f-5690-4507-9e9a-41da980865b8</clientId>
        <clientSecret>some-secret</clientSecret>
        <discoveryUri>https://myad/adfs/.well-known/openid-configuration</discoveryUri>
        <useNonce>false</useNonce>
        <withState>false</withState>
        <scope>openid profile email</scope>

        <uidAttribute>commonname</uidAttribute>
        <cleanUid>false</cleanUid>
        <rolesAttribute>role</rolesAttribute>
        <cleanRoles>true</cleanRoles>

        <!-- paramètres du client direct (pour l'authentification des services) -->
        <directClientName>myoidc-bearer</directClientName>
        <directUidAttribute>appid</directUidAttribute>
        <directRepository>script-file-repo-direct</directRepository>
        <!--<directRoles></directRoles>-->
    </client>
</config>