Wykonywanie konektorów

Istnieje kilka metod wykonania sekwencji udostępniania:

• za pomocą plików Batch lub PowerShell z liniami poleceń wywołującymi plik wykonywalny HPPRunCli
• za pomocą interfejsu zarządzania zadaniami
• za pomocą usług sieciowych SIP

Wykonywanie sekwencji udostępniania za pomocą HPPRUNCLI.exe

W pliku Batch lub PowerShell należy wywołać plik wykonywalny HppRunClie.exe, a po nim następujące opcje:

Opcje	Funkcja	Obowiązkowa (Y/N)
-sec [Sequence Name]	Opcja wskazująca sekwencję do wykonania.	Y
-cfg [Config_file_name]	Opcja wskazująca plik konfiguracyjny, który ma być użyty.	N. Domyślnie używany jest plik hpp.ini.
-obj [Val_attribute1|Val_attribute2|…]	Opcja wskazująca wartość atrybutu uzgadniania, aby wykonać sekwencję jednostkowo. Jeśli trzeba podać kilka wartości atrybutu, należy wymienić je w kolejności, w jakiej mają być wykonane eksporty.	N
-seq [Directory_nm]	Opcja wskazująca nazwę katalogu wyjściowego dla plików dziennika.	N

Wykonywanie sekwencji udostępniania przez interfejs zarządzania zadaniami

Ze strony podglądu instancji zadań sekwencji udostępniania można wykonać zadanie pojedynczo albo masowo.

Aby uruchomić zadanie masowo, kliknij przycisk „”.

Wybierz żądane zadanie lub zadania, a następnie kliknij „Validate”, aby umieścić zadania w kolejce.

Aby uruchomić zadanie pojedynczo, kliknij przycisk „”.

Wybierz żądane zadanie, a następnie wprowadź wartość wskazującą obiekt, na którym chcesz wykonać zadanie.

Uwaga: Obecnie, jeśli zadanie zawiera kilka sekwencji, do wykonania go w trybie jednostkowym atrybut uzgadniania musi mieć tę samą wartość we wszystkich sekwencjach.

Wykonywanie sekwencji udostępniania przez usługi sieciowe SIP

Przykład skryptu wykonującego zadanie udostępniania za pomocą skryptu 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
    }
}

Podobnie, aby za pomocą skryptu PowerShell wznowić zadanie udostępniania zatrzymane z powodu progu importu, trzeba pobrać identyfikator instancji zadania, wywołując ścieżkę /scim/v2/job-instance/ (metoda GET).

Więcej informacji znajdziesz w dokumentacji Swagger: https://[SIP_Server_URL]:44355/swagger/

Wykonywanie nowego konektora zasilania wstępnego (od 7.0 SP3)

Od wersji 7.0 SP3 można przypisywać tożsamościom role i/lub uprawnienia za pomocą nowego konektora zasilania wstępnego.

Powiązania tożsamości – role oraz tożsamości/role – autoryzacje, tworzone i/lub usuwane ze źródła autorytatywnego, są zarządzane przez nowy typ powiązania w bazie danych. Dlatego eksport powiązań tożsamości – role oraz tożsamości/role – autoryzacje z repozytorium Identity zwróci wyłącznie role i autoryzacje przypisane przez SIP.

Konfigurowanie konektora powiązań tożsamości - role

Aby skonfigurować konektor powiązań tożsamości - role, musisz utworzyć co najmniej:

• Eksport ze źródła autorytatywnego, który musi zawierać następujące informacje:
• UID tożsamości (wymagane)
  • Kod roli do przypisania (wymagane) – wartość pojedyncza.
  • Data początkowa roli (opcjonalnie)
  • Data końcowa roli (opcjonalnie)
• Eksport repozytorium Identity typu PERSON_ROLES, w którym trzeba wskazać typy osób i kody repozytoriów, dla których mają zostać utworzone powiązania tożsamość-rola.
• Regułę synchronizacji, aby zdefiniować operacje Matching, tworzenia, modyfikacji i usuwania
  • W regule Matching porównaj uid tożsamości i kod roli
  • W regule tworzenia obowiązkowo wskaż uid tożsamości i kod roli. Daty początkowa i końcowa są opcjonalne
  • W regule modyfikacji obowiązkowo wskaż ID powiązania osoba-rola, pobrane z eksportu repozytorium Identity. Zmieniać można tylko daty
  • W regule usuwania obowiązkowo wskaż ID powiązania osoba-rola, pobrane z eksportu repozytorium Identity.
  • Składnia kodów Identity do użycia w regułach synchronizacji:
    • person = UID tożsamości
    • role = kod roli
    • startdate = data początkowa roli
    • enddate = data końcowa roli
    • id = ID powiązania tożsamość-rola (pole id w tabeli sid.PersonRoles)
• Import do repozytorium Identity typu PERSON_ROLES. Możesz zaznaczyć opcję wyłączenia bieżącego obliczania kont, aby opanować czas importu przy dużych wolumenach. Jeśli opcja została włączona, trzeba wykonać import ACCOUNTCALC, aby przeliczyć konta w danym repozytorium.

Konfigurowanie konektora powiązań tożsamości - role

• Eksport ze źródła autorytatywnego, który musi zawierać następujące informacje:
  • UID tożsamości (wymagane)
  • Kod roli (wymagane) – wartość pojedyncza.
  • Kod autoryzacji do przypisania powiązaniu tożsamość/rola (wymagane) – wartość pojedyncza
  • Data początkowa autoryzacji (opcjonalnie)
  • Data końcowa autoryzacji (opcjonalnie)

Uwaga

Powiązanie tożsamość/rola musi już istnieć, aby konektor powiązań tożsamość/rola – autoryzacje działał prawidłowo

• Eksport repozytorium Identity typu PERSON_RIGHTS, w którym trzeba wskazać typy osób i kody repozytoriów, dla których mają zostać utworzone powiązania tożsamość/rola-autoryzacja.
• Regułę synchronizacji, aby zdefiniować operacje Matching, tworzenia, modyfikacji i usuwania
  • W regule Matching porównaj uid tożsamości, kod roli i kod autoryzacji.
  • W regule tworzenia obowiązkowo wskaż uid tożsamości, kod roli i kod autoryzacji. Daty początkowa i końcowa są opcjonalne
  • W regule modyfikacji obowiązkowo wskaż ID powiązania osoba/rola - autoryzacja, pobrane z eksportu repozytorium Identity. Zmieniać można tylko daty.
  • W regule usuwania obowiązkowo wskaż ID powiązania osoba/rola - autoryzacja, pobrane z eksportu repozytorium Identity.
  • Składnia kodów Identity do użycia w regułach synchronizacji:
  • person = UID tożsamości
    • role = kod roli
    • right = kod autoryzacji
    • startdate = data początkowa autoryzacji
    • enddate = data końcowa autoryzacji
  • id = ID powiązania tożsamość-rola-prawo (pole id w tabeli sid.PersonRights)
• Import do repozytorium Identity typu PERSON_RIGHTS. Możesz zaznaczyć opcję wyłączenia bieżącego obliczania kont, aby opanować czas importu przy dużych wolumenach. Jeśli opcja została włączona, trzeba wykonać import ACCOUNTCALC, aby przeliczyć konta w danym repozytorium.

Włączanie śledzenia

Od wersji 7.1 śledzenie silnika provisioningu nie jest już włączane w rejestrze, lecz w pliku [Installation_Directory]\SIP\Config.ini.

Uwaga

Jest to plik silnika provisioningu. Nie myl go z plikami konfiguracyjnymi konektorów (*.ini), przekazywanymi do HPPRunCli za pomocą opcji -cfg.

W sekcji General dodaj następujące trzy parametry:

• traceLevel: 0, aby wyłączyć śledzenie, 2FFFF, aby je włączyć.
• traceModule: lista modułów do śledzenia, rozdzielonych przecinkami. W nazwach modułów wielkość liter nie ma znaczenia. Możliwe wartości to:
  • HPPCfg
  • HPPCSV
  • HPPHP
  • HPPLDAP
  • HPPReference
  • HPPRunCli
  • HPPSQL
  • SIPSCIM
  • SIPLDAP
  • WrapperDLL
  • All, aby włączyć śledzenie wszystkich modułów
• traceOutputDir: katalog wyjściowy logów. Ten parametr jest opcjonalny: jeśli nie zostanie określony, logi są generowane w folderze %tmp% użytkownika.

Przykład:

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

Uwaga

Instalator wersji 7.1 zapisuje już te trzy parametry w Config.ini ze śledzeniem wyłączonym: traceLevel=0, traceModule wypełniony pełną listą modułów oraz traceOutputDir=C:\Temp. Aby włączyć śledzenie, wystarczy zatem zmodyfikować traceLevel. Sprawdź, czy konto, na którym działa silnik, może zapisywać w katalogu wyjściowym.

Wskazówka

W celu ukierunkowanej diagnostyki ogranicz traceModule wyłącznie do odpowiednich modułów — na przykład SIPSCIM w przypadku problemu z połączeniem z celem SCIM. Po zakończeniu diagnostyki ustaw traceLevel z powrotem na 0: szczegółowe śledzenie zajmuje miejsce na dysku i spowalnia przetwarzanie.

Szyfrowanie haseł i sekretu klienta

Od wersji 7.1 hasła i „client secrets” używane przez silnik provisioningu i zapisane w pliku [Installation_Directory]\SIP\Config.ini są szyfrowane.

Podczas pierwszej instalacji dane te są zapisywane automatycznie zgodnie z parametrami wprowadzonymi w instalatorze.

Aby ręcznie zmodyfikować jedną z tych dwóch wartości, użyj pliku wykonywalnego [Installation_Directory]\SIP\SIPEncrypt.exe. W wierszu polecenia lub w oknie PowerShell uruchom SIPEncrypt.exe, podając hasło lub sekret klienta do zaszyfrowania, a następnie skopiuj wynik do pliku Config.ini.

SIPEncrypt.exe oczekuje jednego parametru. Bez parametru lub z kilkoma parametrami wyświetla komunikat SIPEncrypt should be called with a single input parameter. i niczego nie generuje. Jeśli wartość zawiera spacje lub znaki interpretowane przez wiersz polecenia (&, |, ^, ", $…), ujmij ją w cudzysłów — w PowerShell najlepiej w apostrofy.

Sekret klienta wprowadza się w parametrze clientSecret pliku Config.ini.

Uwaga

Do uwierzytelniania w celach SCIM silnik używa bez zmian każdego hasła lub sekretu klienta, którego nie może odszyfrować. Wartość przypadkowo pozostawiona w postaci jawnej działa więc bez żadnego ostrzeżenia, podczas gdy sekret jest ujawniony w pliku. Sprawdź, czy każdy sekret w Config.ini jest rzeczywiście wartością wygenerowaną przez SIPEncrypt.exe.

To szyfrowanie jest odwracalne, ponieważ silnik sam odszyfrowuje wartości: chroni przed odczytaniem sekretu w postaci jawnej, a nie przed dostępem do pliku. Ogranicz dostęp do Config.ini do kont administracyjnych i konta, na którym działa silnik. Wartość jawna wpisana w wierszu polecenia może również pozostać w historii konsoli: po użyciu zamknij sesję.