Esecuzione dei connettori¶

Esistono diversi metodi per eseguire una sequenza di provisioning:

Mediante file Batch o PowerShell con righe di comando che invocano l'eseguibile HPPRunCli
Mediante l'interfaccia di gestione dei job
Mediante i servizi web SIP

Eseguire le sequenze di provisioning con HPPRUNCLI.exe¶

In un file Batch o PowerShell, occorre invocare l'eseguibile HppRunClie.exe seguito dalle opzioni seguenti:

Opzioni	Funzione	Obbligatorio (Y/N)
-sec [Sequence Name]	Opzione che permette di indicare la sequenza da eseguire.	Y
-cfg [Config_file_name]	Opzione che permette di indicare il file di configurazione da utilizzare.	N. Per impostazione predefinita, viene utilizzato il file hpp.ini.
-obj [Val_attribute1\|Val_attribute2\|…]	Opzione che permette di indicare il valore dell'attributo di corrispondenza per eseguire la sequenza in modo unitario. Se occorre indicare più valori di attributo, questi devono essere elencati nell'ordine in cui le esportazioni devono essere eseguite.	N
-seq [Directory_nm]	Opzione che permette di indicare il nome della directory di output dei file di log.	N

Eseguire le sequenze di provisioning dall'interfaccia di gestione dei job¶

Dalla pagina di consultazione delle istanze di job delle sequenze di provisioning, è possibile eseguire un job in modo unitario o in modo massivo.

Per avviare un job in modo massivo, fare clic sul pulsante «».

Selezionare il job o i job desiderati, quindi fare clic su «Validate» per inserire i job nella coda di attesa.

Per avviare un job in modo unitario, fare clic sul pulsante «».

Selezionare il job desiderato, quindi immettere il valore che permette di selezionare l'oggetto sul quale si desidera eseguire il job.

Attenzione: attualmente, se il job contiene più sequenze, per eseguirlo in modalità unitaria l'attributo di corrispondenza deve avere lo stesso valore in tutte le sequenze.

Eseguire le sequenze di provisioning tramite i servizi web SIP¶

Esempio di script per eseguire un job di provisioning tramite uno 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
    }
}

Analogamente, per riavviare tramite uno script PowerShell un job di provisioning arrestato a causa di una soglia di importazione, è necessario recuperare l'identificativo dell'istanza di job invocando il percorso /scim/v2/job-instance/ (metodo GET).

Per maggiori informazioni, consultare la documentazione Swagger: https://[SIP_Server_URL]:44355/swagger/

Eseguire il nuovo connettore di alimentazione a monte (dalla 7.0 SP3)¶

A partire dalla versione 7.0 SP3 è possibile assegnare ruoli e/o autorizzazioni alle identità tramite un nuovo connettore di alimentazione a monte.

I collegamenti Identità – Ruoli e Identità/Ruoli – Autorizzazioni creati e/o eliminati da una fonte autorevole sono gestiti da un nuovo tipo di collegamento nel database. Pertanto, l'esportazione dei collegamenti Identità – Ruoli e Identità/Ruoli – Autorizzazioni dal repository Identity restituirà soltanto i ruoli e le autorizzazioni assegnati da SIP.

Configurare un connettore di collegamento Identità - Ruoli¶

Per configurare un connettore di collegamento Identità - Ruoli, occorre creare almeno:

Un'esportazione da una fonte autorevole che deve contenere le informazioni seguenti:
UID dell'identità (obbligatorio)
- Codice del ruolo da assegnare (obbligatorio) – valore unico.
- Data di inizio del ruolo (facoltativo)
- Data di fine del ruolo (facoltativo)
Un'esportazione del repository Identity di tipo PERSON_ROLES nella quale occorre indicare i tipi di persona e i codici dei repository per i quali si desidera creare i collegamenti identità-ruolo.
Una regola di sincronizzazione per definire le operazioni di Matching, di creazione, di modifica e di eliminazione
- Nella regola di Matching, confrontare l'uid dell'identità e il codice del ruolo
- Nella regola di creazione, è obbligatorio indicare l'uid dell'identità e il codice del ruolo. Le date di inizio e di fine sono opzionali
- Nella regola di modifica, è obbligatorio indicare l'ID del collegamento persona-ruolo, recuperato dall'esportazione del repository Identity. Solo le date possono essere modificate
- Nella regola di eliminazione, è obbligatorio indicare l'ID del collegamento persona-ruolo, recuperato dall'esportazione del repository Identity.
- Sintassi dei codici Identity da utilizzare nelle regole di sincronizzazione:
  - person = UID dell'identità
  - role = codice del ruolo
  - startdate = data di inizio del ruolo
  - enddate = data di fine del ruolo
  - id = ID del collegamento identità-ruolo (campo id della tabella sid.PersonRoles)
Un'importazione nel repository Identity di tipo PERSON_ROLES. È possibile selezionare l'opzione di disattivazione del calcolo degli account al volo per controllare il tempo di importazione in caso di grandi volumi. Se l'opzione è stata attivata, occorre eseguire un'importazione ACCOUNTCALC per ricalcolare gli account nel repository interessato.

Configurare un connettore di collegamento Identità - Ruoli¶

Un'esportazione da una fonte autorevole che deve contenere le informazioni seguenti:
- UID dell'identità (obbligatorio)
- Codice del ruolo (obbligatorio) – valore unico.
- Codice dell'autorizzazione da assegnare al collegamento identità/ruolo (obbligatorio) – valore unico
- Data di inizio dell'autorizzazione (facoltativo)
- Data di fine dell'autorizzazione (facoltativo)

Attenzione

Il collegamento Identità/Ruolo deve già esistere perché il connettore di collegamento Identità/Ruolo – Autorizzazioni funzioni correttamente

Un'esportazione del repository Identity di tipo PERSON_RIGHTS nella quale occorre indicare i tipi di persona e i codici dei repository per i quali si desidera creare i collegamenti identità/ruolo-autorizzazione.
Una regola di sincronizzazione per definire le operazioni di Matching, di creazione, di modifica e di eliminazione
- Nella regola di Matching, confrontare l'uid dell'identità, il codice del ruolo e il codice dell'autorizzazione.
- Nella regola di creazione, è obbligatorio indicare l'uid dell'identità, il codice del ruolo e il codice dell'autorizzazione. Le date di inizio e di fine sono opzionali
- Nella regola di modifica, è obbligatorio indicare l'ID del collegamento persona/ruolo - autorizzazione, recuperato dall'esportazione del repository Identity. Solo le date possono essere modificate.
- Nella regola di eliminazione, è obbligatorio indicare l'ID del collegamento persona/ruolo - autorizzazione, recuperato dall'esportazione del repository Identity.
- Sintassi dei codici Identity da utilizzare nelle regole di sincronizzazione:
- person = UID dell'identità
  - role = codice del ruolo
  - right = codice dell'autorizzazione
  - startdate = data di inizio dell'autorizzazione
  - enddate = data di fine dell'autorizzazione
- id = ID del collegamento identità-ruolo-autorizzazione (campo id della tabella sid.PersonRights)
Un'importazione nel repository Identity di tipo PERSON_RIGHTS. È possibile selezionare l'opzione di disattivazione del calcolo degli account al volo per controllare il tempo di importazione in caso di grandi volumi. Se l'opzione è stata attivata, occorre eseguire un'importazione ACCOUNTCALC per ricalcolare gli account nel repository interessato.

Abilitazione delle tracce¶

A partire dalla versione 7.1, le tracce del motore di provisioning non vengono più abilitate nel registro, ma nel file [Installation_Directory]\SIP\Config.ini.

Nota

Questo file è quello del motore di provisioning. Non deve essere confuso con i file di configurazione dei connettori (*.ini), passati a HPPRunCli con l'opzione -cfg.

Nella sezione General, aggiungere i tre parametri seguenti:

traceLevel: 0 per disabilitare le tracce, 2FFFF per abilitarle.
traceModule: elenco dei moduli da tracciare, separati da virgole. I nomi dei moduli non fanno distinzione tra maiuscole e minuscole. I valori possibili sono:
- HPPCfg
- HPPCSV
- HPPHP
- HPPLDAP
- HPPReference
- HPPRunCli
- HPPSQL
- SIPSCIM
- SIPLDAP
- WrapperDLL
- All, per abilitare le tracce di tutti i moduli
traceOutputDir: directory di output dei log. Questo parametro è facoltativo: se non è specificato, i log vengono generati nella cartella %tmp% dell'utente.

Esempio:

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

Nota

Il programma di installazione della versione 7.1 scrive già questi tre parametri in Config.ini, con le tracce disabilitate: traceLevel=0, traceModule compilato con l'elenco completo dei moduli e traceOutputDir=C:\Temp. Per abilitare le tracce, è quindi sufficiente modificare traceLevel. Verificare che l'account che esegue il motore possa scrivere nella directory di output.

Suggerimento

Per una diagnosi mirata, limitare traceModule ai soli moduli interessati — per esempio SIPSCIM per un problema di connessione con una destinazione SCIM. Una volta completata la diagnosi, reimpostare traceLevel su 0: le tracce dettagliate occupano spazio su disco e rallentano le elaborazioni.

Cifratura delle password e del client secret¶

A partire dalla versione 7.1, le password e i «client secret» utilizzati dal motore di provisioning e presenti nel file [Installation_Directory]\SIP\Config.ini sono cifrati.

Durante una prima installazione, questi dati vengono salvati automaticamente in base ai parametri immessi nel programma di installazione.

Per modificare manualmente uno di questi due valori, utilizzare l'eseguibile [Installation_Directory]\SIP\SIPEncrypt.exe. Da un prompt dei comandi o da una finestra PowerShell, eseguire SIPEncrypt.exe seguito dalla password o dal client secret da cifrare, quindi copiare il risultato nel file Config.ini.

SIPEncrypt.exe si aspetta un solo parametro. Senza parametri, o con più parametri, visualizza il messaggio SIPEncrypt should be called with a single input parameter. e non produce nulla. Se il valore contiene spazi o caratteri interpretati dal prompt dei comandi (&, |, ^, ", $…), racchiuderlo tra virgolette — preferibilmente virgolette singole in PowerShell.

Il client secret viene immesso nel parametro clientSecret del file Config.ini.

Attenzione

Per l'autenticazione presso le destinazioni SCIM, il motore utilizza così com'è qualsiasi password o client secret che non riesce a decifrare. Un valore lasciato in chiaro per errore funziona quindi senza alcun messaggio di avvertenza, mentre il segreto è esposto nel file. Verificare che ogni segreto in Config.ini sia effettivamente un valore prodotto da SIPEncrypt.exe.

Questa cifratura è reversibile, poiché è il motore stesso a decifrare i valori: protegge dalla lettura del segreto in chiaro, non dall'accesso al file. Limitare l'accesso a Config.ini agli account di amministrazione e all'account che esegue il motore. Se digitato nella riga di comando, il valore in chiaro può anche rimanere nella cronologia della console: chiudere la sessione dopo l'uso.