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).

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

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.

Paramètres requis pour la configuration de l'authentification directe. Dans le mode direct, il est possible

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:# où # 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>