Logowanie jednokrotne i dane o nauce

Dwie integracje konfiguruje administrator IT w panelu administracji IT, a nie przez to API. Ta strona zbiera to, co muszą wiedzieć Twoje zespoły od tożsamości i analityki.

#Logowanie jednokrotne (OpenID Connect)

Osoby mogą logować się przez dowolnego dostawcę tożsamości zgodnego z OpenID Connect (np. Microsoft Entra ID), przepływem authorization code z PKCE.

• Co wpisuje administrator IT: adres wydawcy (issuer, dokument discovery), identyfikator i sekret aplikacji zarejestrowanej u dostawcy oraz opcjonalnie oświadczenia (claims) z adresem e-mail i numerem kadrowym. Przed zapisem panel sprawdza discovery i klucze podpisu.
• Redirect URI do zarejestrowania u dostawcy: adres platformy Twojej organizacji z dopiskiem /auth/sso/callback (dokładną wartość pokazuje panel).
• Domeny e-mail weryfikuje się rekordem DNS TXT pokazanym w panelu. Pierwsze logowanie łączy osobę po zweryfikowanym adresie e-mail albo — jeśli tak skonfigurowano — po oświadczeniu z numerem kadrowym; potem liczy się już tylko identyfikator u dostawcy (iss + sub). Konta nie są zakładane przy logowaniu — twórz je przez SCIM albo API osób.
• Tryb wymagany może wymusić logowanie jednokrotne dla wybranych działów lub typów pracowników. Co najmniej jeden administrator zachowuje hasło jako konto awaryjne.

Tokeny ID muszą być podpisane algorytmem asymetrycznym; sprawdzane są iss, aud, nonce i czasy ważności.

#Zakładanie kont (SCIM 2.0)

Dostawcy tożsamości synchronizują konta i grupy przez SCIM — adres i token opisuje Uwierzytelnianie, a obsługiwane zasoby sekcja SCIM referencji API. Konta założone przez SCIM należą do dostawcy tożsamości; API osób zwraca 409 MANAGED_ELSEWHERE przy próbie ich zmiany.

#Dane o nauce (przekazywanie xAPI)

Aktywność szkoleniowa (uruchomienia kursów, postęp, ukończenia) jest zapisywana jako zdarzenia xAPI (statements). Platforma może przekazywać je do Twojego własnego Learning Record Store:

• Co wpisuje administrator IT: adres bazowy LRS (zakończony /), login i sekret uwierzytelniania Basic oraz wersję xAPI (1.0.3 albo 2.0.0). Panel sprawdza połączenie przez GET {endpoint}about i uwierzytelnione GET {endpoint}statements?limit=1.
• Zdarzenia idą paczkami do 100 przez POST {endpoint}statements, w kolejności zapisu. Nieudane paczki są ponawiane po 1 minucie, 5 minutach, 30 minutach, a potem co 2 godziny; nic nie jest pomijane.
• Gdy LRS odrzuci paczkę kodem 400, jest ona wysyłana ponownie po jednym zdarzeniu; zdarzenia odrzucone pojedynczo są widoczne w panelu, a pozostałe idą dalej.
• Odpowiedzi tekstowe kursantów (result.response) są usuwane, chyba że administrator włączy ich wysyłanie.
• Host LRS musi być publiczną nazwą hosta na porcie 443. Żądania wychodzą ze stałego adresu platformy — jeśli Twoja zapora używa listy dozwolonych adresów, poproś o niego opiekuna wdrożenia.

Do przekazywania ukończeń do systemu kadrowego zwykle prostsze są webhooki niż odczyt z LRS.