Exécution des connecteurs¶

Il existe plusieurs méthodes pour exécuter une séquence de provisioning :

Via des fichiers de type Batch ou PowerShell avec des lignes de commande appelant l’exécutable HPPRunCli
Via l’interface de gestion les jobs
Via les webservices SIP

Exécution des séquences de provisioning avec HPPRUNCLI.exe¶

Dans un fichier de type Batch ou PowerShell, il est nécessaire d’appeler l’exécutable HppRunClie.exe suivi des options suivantes :

Options	Fonction	Obligatoire (O/N)
-sec [Nom séquence]	Option pour indiquer la séquence à exécuter.	O
-cfg [Nom_fichier_config]	Option pour indiquer le fichier de configuration à utiliser.	N. Par défaut c’est le fichier hpp.ini qui est utilisé.
-obj [Val_attribut1\|Val_attribut2\|…]	Option pour indiquer la valeur d’attribut de matching pour exécuter la séquence de manière unitaire. Si plusieurs valeurs d’attributs sont à indiquer, il faut les mettre par ordre d’exécution des exports.	N
-seq [Nm_répertoire]	Option pour indiquer le nom du répertoire de sortie des fichiers de logs.	N

Exécution des séquences de provisioning via l'interface de gestion des jobs¶

Depuis la page de consultation des instances de jobs séquences de provisioning , il est possible d’exécuter un job soit de manière unitaire soit pour une exécution en masse.

Pour lancer un job en l'exécutant en masse, cliquez sur le bouton « ».

Sélectionnez le ou les jobs souhaités, puis cliquez sur « Valider » pour mettre les jobs dans la file d'attente.

Pour lancer un job de manière unitaire, cliquez sur le bouton « ».

Sélectionnez le job souhaité, puis renseignez la valeur pour sélectionner l’objet sur lequel vous souhaitez exécuter le job.

Avertissement : Actuellement, si votre job contient plusieurs séquences, pour pouvoir lancer un job en mode unitaire, il faut que l’attribut de matching soit la même valeur pour toutes les séquences.

Exécution des séquences de provisioning via les webservices SIP¶

Exemple de script pour exécuter un job de provisioning via un script powershell:

$urlGenToken = "https://[URL_serveur_SID]:44350/connect/token"
$BodyJsonPostToken = "grant_type=password&client_id=sip&client_secret=sip&username=[login_cpt]&password=[mot_de_passe_compte]"
$MonHeader = @{
        "Content-Type" = "application/x-www-form-urlencoded"
        "accept" = "Application/Json"
        "Host" = "[URL_serveur_SID]:44350"
    }

$MonHeaderReq = @{
        "Content-Type" = "application/x-www-form-urlencoded"
        "accept" = "Application/Json"
        "Host" = "[URL_serveur_SID]:44350"
        "Authorization" = "Bearer $($token_gen)" 
    }

try {

    $result = Invoke-RestMethod -Uri $urlGenToken -Method Post -Headers $MonHeader -Body $BodyJsonPostToken 
    $token_gen = $result.access_token
    #ajouter logs
}
catch {
    $token_gen = ""
    #ajouter logs
}

if ($token_gen -ne "")
{
    $job_code = [code_du_job_à_exécuter]
    $MonHeaderReq = @{
        "Content-Type" = "application/x-www-form-urlencoded"
        "accept" = "Application/Json"
        "Host" = "sid.iam-test.ght49.intra:44355"
        "Authorization" = "Bearer $($token_gen)"
    }
    $urlExecutionJob="https://sid.iam-test.ght49.intra:44355/scim/v2/job/run/$job_code"

    try {
        $res = Invoke-RestMethod -Uri $urlExecutionJob -Method Post -Headers $MonHeaderReq  
        #ajouter logs
    }
    catch {
        #ajouter logs et traitement
    }
}

Dans le même principe, pour relancer via un script PowerShell un job de provisioning qui aurait été arrêté à cause d’un seuil d’import, il faut récupérer l’ID de l’instance de job en appelant la route /scim/v2/job-instance/ (méthode GET).

Se rendre sur la documentation swagger pour plus d’informations : https://[URL_Serveur_SIP]:44355/swagger/

Exécution du nouveau connecteur d'alimentation amont (à partir de 7.0 SP3)¶

À partir de la version 7.0 SP3, il est possible d’affecter des rôles et/ou habilitations à des identités via un nouveau connecteur d’alimentation amont.

Les liens Identités – Rôles et Identités/Rôles – Habilitations créés et/ou supprimés à partir d'une source autoritaire sont gérés par un nouveau type de lien dans la base de données. Ainsi, l'export des liens Identités – Rôles et Identités/Rôles – Habilitations du référentiel Identity retournera seulement les rôles et habilitations affectés par SIP.

Configurer un connecteur de lien Identités - Rôles¶

Pour configurer un connecteur de lien identités - Rôles, il est nécessaire de créer au minimum :

Un export d’une source autoritaire qui doit contenir les informations suivantes :
- UID de l’identité (obligatoire)
- Code du rôle à affecter (obligatoire) – monovalué.
- Date de début du rôle (facultatif)
- Date de fin du rôle (facultatif)
Un export du référentiel Identity de type PERSON_ROLES dans lequel il faut préciser les types de personnes et les codes des référentiels pour lesquels on veut créer des liens identités - rôles.
Une règle de synchronisation pour définir les opérations de Matching, Création, Modification et Suppression
- Dans la règle de Matching, comparez l’uid de l’identité et le code du rôle
- Dans la règle de création, il est obligatoire de préciser l’uid de l’identité et le code du rôle. Les dates de début et de fin sont facultatives
- Dans la règle de modification, il est obligatoire de préciser l’ID du lien personne – rôle, récupéré dans l’export du référentiel Identity. Seul les dates peuvent être modifiées
- Dans la règle de suppression, il est obligatoire de préciser l’ID du lien personne – rôle, récupéré dans l’export du référentiel Identity.
- Syntaxe des codes Identity à utiliser dans les règles de synchronisation :
  - person = UID de l’identité
  - role = code du rôle
  - startdate = date de début du rôle
  - enddate = date de fin du rôle
  - id = id du lien identité-rôle (champ id dans la table sid.PersonRoles)
Un import dans le référentiel Identity de type PERSON_ROLES. Il est possible de cocher l’option pour désactiver le calcul des comptes à la volée afin de gérer le temps d’import en cas de grosse volumétrie. Si l’option a été activée, il est nécessaire d’exécuter un import de type ACCOUNTCALC pour recalculer les comptes du référentiel impacté.

Configurer un connecteur de lien Identités - Rôles¶

Un export d’une source autoritaire qui doit contenir les informations suivantes :
- UID de l’identité (obligatoire)
- Code du rôle (obligatoire) – monovalué.
- Code de l’habilitation à affecter au lien identité/rôle (obligatoire) – monovalué
- Date de début de l’habilitation (facultatif)
- Date de fin de l’habilitation (facultatif)

Attention

Le lien Identités/Rôles doit préalablement exister pour un bon fonctionnement du connecteur de lien Identité/Rôle – Habilitations

Un export du référentiel Identity de type PERSON_RIGHTS dans lequel il faut préciser les types de personnes et les codes des référentiels pour lesquels on veut créer des liens identités/rôles - habilitations.
Une règle de synchronisation pour définir les opérations de Matching, Création, Modification et Suppression
- Dans la règle de Matching, comparez l’uid de l’identité, le code du rôle et le code de l’habilitation
- Dans la règle de création, il est obligatoire de préciser l’uid de l’identité, le code du rôle et le code de l’habilitation. Les dates de début et de fin sont facultatives
- Dans la règle de modification, il est obligatoire de préciser l’ID du lien personne/rôle - habilitation, récupéré dans l’export du référentiel Identity. Seul les dates peuvent être modifiées.
- Dans la règle de suppression, il est obligatoire de préciser l’ID du lien personne/rôle - habilitation, récupéré dans l’export du référentiel Identity.
- Syntaxe des codes Identity à utiliser dans les règles de synchronisation :
  - person = UID de l’identité
  - role = code du rôle
  - right = code de l’habilitation
  - startdate = date de début de l’habilitation
  - enddate = date de fin de l’habilitation
- id = id du lien identité-rôle-right (champ id dans la table sid.PersonRights)
Un import dans le référentiel Identity de type PERSON_RIGHTS. Il est possible de cocher l’option pour désactiver le calcul des comptes à la volée afin de gérer le temps d’import en cas de grosse volumétrie. Si l’option a été activée, il est nécessaire d’exécuter un import de type ACCOUNTCALC pour recalculer les comptes du référentiel impacté.

Activation des traces¶

À partir de la version 7.1, l’activation des traces du moteur de provisioning ne se fait plus dans la base de registre mais dans le fichier [Répertoire_Installation]\SIP\Config.ini.

Note

Ce fichier est celui du moteur de provisioning. Il ne doit pas être confondu avec les fichiers de configuration de connecteur (*.ini), passés à HPPRunCli par l’option -cfg.

Dans la section General, ajoutez les trois paramètres suivants :

traceLevel : 0 pour désactiver les traces, 2FFFF pour les activer.
traceModule : liste des modules à tracer, séparés par des virgules. Les noms de modules ne sont pas sensibles à la casse. Les valeurs possibles sont :
- HPPCfg
- HPPCSV
- HPPHP
- HPPLDAP
- HPPReference
- HPPRunCli
- HPPSQL
- SIPSCIM
- SIPLDAP
- WrapperDLL
- All, pour activer les traces de tous les modules
traceOutputDir : répertoire de sortie des journaux. Ce paramètre est facultatif : s’il n’est pas précisé, les journaux sont générés dans le dossier %tmp% de l’utilisateur.

Exemple :

[General]
traceLevel=2ffff
traceModule=HPPCSV,HPPCfg,HPPLDAP
traceOutputDir=c:/myLog

Note

L’installeur de la version 7.1 écrit déjà ces trois paramètres dans Config.ini, avec les traces désactivées : traceLevel=0, traceModule renseigné avec la liste complète des modules, et traceOutputDir=C:\Temp. Pour activer les traces, il suffit donc de modifier traceLevel. Vérifiez que le compte qui exécute le moteur peut écrire dans le répertoire de sortie.

Conseil

Pour un diagnostic ciblé, réduisez traceModule aux seuls modules concernés — par exemple SIPSCIM pour un problème de connexion à une cible SCIM. Une fois le diagnostic terminé, remettez traceLevel à 0 : les traces détaillées consomment de l’espace disque et ralentissent les traitements.

Chiffrement des mots de passe et du secret client¶

À partir de la version 7.1, les mots de passe et les « client secret » utilisés par le moteur de provisioning et présents dans le fichier [Répertoire_Installation]\SIP\Config.ini sont chiffrés.

Lors d’une primo-installation, ces données sont enregistrées automatiquement selon les paramètres saisis dans l’installeur.

Pour modifier manuellement l’une de ces deux valeurs, utilisez l’exécutable [Répertoire_Installation]\SIP\SIPEncrypt.exe. Depuis une invite de commandes ou une fenêtre PowerShell, lancez SIPEncrypt.exe suivi du mot de passe ou du secret client à chiffrer, puis copiez le résultat obtenu dans le fichier Config.ini.

SIPEncrypt.exe attend un seul paramètre. Sans paramètre, ou avec plusieurs, il affiche le message SIPEncrypt should be called with a single input parameter. et ne produit rien. Si la valeur contient des espaces ou des caractères interprétés par l’invite de commandes (&, |, ^, ", $…), placez-la entre guillemets — de préférence des guillemets simples sous PowerShell.

Le secret client se renseigne dans le paramètre clientSecret du fichier Config.ini.

Attention

Pour l’authentification auprès des cibles SCIM, le moteur utilise tel quel un mot de passe ou un secret client qu’il ne parvient pas à déchiffrer. Une valeur laissée en clair par erreur fonctionne donc sans aucun message d’alerte, alors que le secret est exposé dans le fichier. Vérifiez que chaque secret de Config.ini est bien une valeur produite par SIPEncrypt.exe.

Ce chiffrement est réversible, puisque le moteur déchiffre lui-même les valeurs : il protège contre la lecture du secret en clair, pas contre l’accès au fichier. Restreignez l’accès à Config.ini aux comptes d’administration et au compte qui exécute le moteur. Tapée en ligne de commande, la valeur en clair peut aussi rester dans l’historique de la console : fermez la session après usage.