Skonfiguruj niestandardowych dostawców tożsamości (IdP) dla logowania jednokrotnego SAML lub OIDC, aby użytkownicy Twojej organizacji mogli się uwierzytelniać przy użyciu swoich istniejących danych uwierzytelniających firmy.

Uwaga:

Zarządzanie dostawcami tożsamości jest dostępne wyłącznie dla administratorów planu Enterprise.

Skonfiguruj niestandardowego dostawcę tożsamości (IdP), aby włączyć logowanie jednokrotne (SSO) dla swojej organizacji. Po skonfigurowaniu IdP Bob przekierowuje Cię do niego w celu uwierzytelnienia podczas logowania do IBM Bob w IDE, Bob Shell i Bob Web.

Z Bobem możesz skonfigurować dostawców tożsamości SAML i OpenID Connect (OIDC). Użyj protokołu, który pasuje do platformy tożsamości Twojej organizacji.

Zgodność protokołów SSO

IBM Bob jest kompatybilny z następującymi protokołami SSO:

SAML (Security Assertion Markup Language)

OIDC (OpenID Connect)

Zweryfikowani dostawcy OIDC

Choć możesz używać innych dostawców OIDC spełniających wymagania konfiguracyjne i tokenowe, następujące platformy są zweryfikowane:

Auth0

Keycloak

Okta

PingOne

Dodawanie dostawcy tożsamości

Dodawanie IdP to dwuetapowy proces. Najpierw konfigurujesz IdP i zapisujesz go, a następnie dodajesz domeny e-mail, które go używają.

Krok 1: Konfigurowanie dostawcy tożsamości

Przejdź na stronę administracyjną IBM Bob.

Wybierz kartę Authentication.

Kliknij Add IdP. Wprowadź nazwę dla IdP. Wybierz typ IdP: SAML lub OIDC. Wygeneruj swoje dane uwierzytelniające service provider (SP).

Bob wymaga klucza prywatnego SP i certyfikatu SP do podpisywania żądań uwierzytelniania SAML. Musisz je wygenerować samodzielnie za pomocą narzędzia wiersza poleceń openssl.

Uwaga:

Jeśli masz już parę kluczy SP i certyfikat, pomiń następny krok.

Uruchom następujące polecenie, aby wygenerować klucz prywatny SP:

openssl genrsa -out sp_private_key.pem 2048

Następnie uruchom to polecenie, aby wygenerować certyfikat SP z klucza prywatnego. Zastąp wartości /CN, /O i /C opisową nazwą certyfikatu, nazwą swojej organizacji i dwuliterowym kodem kraju:

openssl req -new -x509 -key sp_private_key.pem -out sp_certificate.pem -days 365 -subj "/CN=Bob SAML SP/O=IBM/C=US"

Uwaga:

Plik sp_certificate.pem musi być również przesłany do Twojego IdP, aby mógł weryfikować podpisy żądań z Bob.

Wprowadź szczegóły konfiguracji IdP. Przejrzyj wymagania specyficzne dla protokołu w poniższych sekcjach. Kliknij Save.

IdP zostaje utworzony i pojawia się w tabeli na karcie Authentication.

Konfiguracja SAML

SAML wymaga następujących szczegółów konfiguracji:

Pola identity provider — uzyskaj je od swojego IdP:

idp_entity_id — unikalny identyfikator IdP (na przykład https://idp.example.com)

idp_sso_url — adres URL SSO, pod który Bob wysyła żądania uwierzytelniania

idp_certificate — certyfikat X.509 zakodowany w PEM używany do weryfikacji odpowiedzi SAML z IdP

Pola service provider — użyj plików wygenerowanych w poprzednim kroku:

sp_private_key — zawartość sp_private_key.pem

sp_certificate — zawartość sp_certificate.pem

Pola opcjonalne:

idp_slo_url — adres URL Single Logout IdP. Single Logout nie jest jeszcze w pełni zaimplementowany w Bob.

W sekcji Attribute mapping przypisz atrybuty użytkownika IdP do pól użytkownika IBM Bob. Format mapowania to nazwa atrybutu Bob → nazwa atrybutu lub URI IdP. Sprawdź konfigurację swojego IdP, aby uzyskać prawidłowe nazwy atrybutów.

email (wymagane) — adres e-mail użytkownika

name (opcjonalne) — pełna nazwa wyświetlana użytkownika

given_name (opcjonalne) — imię użytkownika

family_name (opcjonalne) — nazwisko użytkownika

groups (opcjonalne) — grupy użytkownika

Administrator IdP: rejestrowanie nowego klienta OIDC

Zanim admin instancji Bob będzie mógł skonfigurować rekord IdP OIDC w Bob, administrator IdP musi najpierw utworzyć aplikację OIDC (klienta) w dostawcy tożsamości. Wartości wygenerowane w tym kroku są tymi, które admin instancji Bob wprowadza podczas dodawania IdP w Bob.

Typ aplikacji i typ przyznania

Utwórz aplikację webową (po stronie serwera / klient poufny) u swojego dostawcy tożsamości i włącz typ przyznania Authorization Code. Bob używa wyłącznie przepływu Authorization Code — nie wybieraj Implicit, Device Code ani Client Credentials.

URI przekierowania

Zarejestruj następujący URL zwrotny w aplikacji OIDC. Większość dostawców wykonuje dokładne dopasowanie ciągu, więc skopiuj go dokładnie:

https://api.us-east.bob.ibm.com/authn/v1/auth/callback

Zakresy do włączenia na kliencie

Zakres	Cel	Wymagane
`openid`	Włącza tryb OIDC i zwraca `id_token`	Tak
`email`	Udostępnia adres e-mail użytkownika w `id_token` lub przez endpoint userinfo	Tak
`offline_access`	Przyznaje `refresh_token` wraz z access token	Tak dla większości dostawców

Bob wymaga, aby refresh_token był obecny w każdej odpowiedzi wymiany kodu autoryzacji. Jeśli dostawca wydaje tokeny odświeżania przez inny mechanizm (np. zakres specyficzny dla dostawcy lub bezwarunkowo przy każdej wymianie kodu), skonfiguruj to odpowiednio — ale upewnij się, że klient może otrzymywać tokeny odświeżania. Jeśli nie zostanie zwrócony żaden refresh_token, logowanie jest przerywane.

Metoda uwierzytelniania na token endpoint

Skonfiguruj metodę uwierzytelniania na token endpoint aplikacji OIDC jako client_secret_post. Bob wysyła client_id i client_secret jako parametry treści formularza w każdym żądaniu tokenu. client_secret_basic, private_key_jwt i none nie są akceptowane.

Ustawienia tokenów

Ustawienie	Wymagana wartość
Format access token	Dowolny (JWT lub nieprzejrzysty — Bob nie analizuje bezpośrednio access token IdP)
ID token	Musi być wydany przy każdej wymianie kodu autoryzacji i przy każdym odświeżeniu tokenu
Algorytm podpisu ID token	`RS256`, `ES256` lub `PS256`
Rotacja refresh token	Możesz korzystać z rotacji refresh token. Bob przechowuje nowy token przy każdym odświeżeniu. Jeśli dostawca rotuje tokeny odświeżania, upewnij się, że dostawca unieważnia poprzedni token dopiero po tym, jak Bob otrzyma zamiennik (standardowe zachowanie rotacji, nie jednorazowe użycie bez okna tolerancji).

Wartości do przekazania adminowi instancji Bob

Po utworzeniu aplikacji klienta przekaż poniższe wartości adminowi instancji Bob:

Wartość	Gdzie ją znaleźć	Pole konfiguracji Bob
Client ID	Strona danych uwierzytelniających aplikacji	`client_id`
Client Secret	Strona danych uwierzytelniających aplikacji	`client_secret`
URL authorization endpoint	Strona endpointów OIDC dostawcy lub `.well-known/openid-configuration`	`authorization_endpoint`
URL token endpoint	Strona endpointów OIDC dostawcy lub `.well-known/openid-configuration`	`token_endpoint`
JWKS URI	Strona endpointów OIDC dostawcy lub `.well-known/openid-configuration`	`jwks_uri`
URL issuer	Strona endpointów OIDC dostawcy lub `.well-known/openid-configuration`	`issuer`
URL userinfo endpoint (opcjonalnie)	Strona endpointów OIDC dostawcy lub `.well-known/openid-configuration`	`userinfo_endpoint`

Wskazówka:

Większość dostawców publikuje wszystkie adresy URL endpointów pod adresem https://<twoja-domena-dostawcy>/.well-known/openid-configuration.

Konfiguracja OIDC

Możesz używać wykrywania dostawcy OIDC. Kliknij przycisk Retrieve configuration, aby automatycznie wypełnić pola endpointów z dokumentu .well-known/openid-configuration swojego dostawcy, lub możesz ręcznie wprowadzić każdy URL endpointu.

OIDC wymaga następujących szczegółów konfiguracji:

Pole	Wymagane	Opis
`client_id`	Tak	Identyfikator klienta zarejestrowany u dostawcy tożsamości.
`client_secret`	Tak	Sekret klienta dla zarejestrowanej aplikacji. Bob przechowuje go bezpiecznie i nigdy nie zwraca w odpowiedziach API.
`scopes`	Tak	Zakresy żądane podczas przepływu autoryzacji. Ta lista musi zawierać `openid`. Zazwyczaj zawiera również `email` i zakres specyficzny dla dostawcy używany do wydawania tokenu odświeżania, taki jak `offline_access`.
`authorization_endpoint`	Tak	URL autoryzacji HTTPS, do którego Bob przekierowuje użytkowników w celu zalogowania.
`token_endpoint`	Tak	URL tokenu HTTPS używany do wymiany kodu autoryzacji na tokeny.
`jwks_uri`	Tak	URL HTTPS zestawu kluczy JSON Web Key Set (JWKS) używanego do weryfikacji podpisu odpowiedzi `id_token`.
`issuer`	Nie	Identyfikator wystawcy HTTPS dla dostawcy tożsamości.
`prompt`	Nie	Wartość `prompt` OIDC przekazywana do żądania autoryzacji.

OIDC nie używa Attribute mapping. Bob odczytuje e-mail użytkownika bezpośrednio z roszczenia email w id_token.

Przykład konfiguracji OIDC

{
  "authorization_endpoint": "https://corp.okta.com/oauth2/default/v1/authorize",
  "token_endpoint": "https://corp.okta.com/oauth2/default/v1/token",
  "issuer": "https://corp.okta.com/oauth2/default",
  "client_id": "0oa1b2c3d4e5f6g7h8i9",
  "client_secret": "super-secret-value",
  "scopes": ["openid", "email", "offline_access"]
}

Wymagania i ograniczenia OIDC

Bob wymaga refresh_token w odpowiedzi wymiany kodu autoryzacji. Jeśli dostawca go nie zwraca, logowanie kończy się niepowodzeniem.

W przypadku większości dostawców dodanie offline_access do scopes powoduje wydanie tokenu odświeżania. Niektórzy dostawcy używają innego zachowania, więc sprawdź dokumentację swojego dostawcy.

Wylogowanie back-channel OIDC nie jest dostępne.

Jeśli dostawca zmieni swoje URL endpointów, zaktualizuj konfigurację IdP w Bob.

Krok 2: Dodawanie filtrów domen

Po zapisaniu IdP dodaj domeny e-mail, które powinny go używać do uwierzytelniania.

Na karcie Authentication znajdź właśnie utworzony IdP i otwórz jego ustawienia. W sekcji Domain filters dodaj domeny e-mail, które powinny używać tego IdP. Użytkownicy, których adresy e-mail pasują do skonfigurowanej domeny, są podczas logowania przekierowywani do tego IdP. Zapisz zmiany.

Uwaga:

Każda domena e-mail może być powiązana tylko z jednym IdP. Jeśli dana domena jest już używana przez inny IdP, konfiguracji nie można zapisać, dopóki konflikt nie zostanie rozwiązany. Każda domena musi być również zweryfikowana przed wymuszeniem SSO. Zobacz Weryfikacja własności domeny.

Weryfikacja własności domeny

IBM Bob wymaga zweryfikowania, że Twoja organizacja jest właścicielem każdej domeny, zanim SSO zostanie dla niej wymuszone. Weryfikacja odbywa się poprzez dodanie rekordu TXT DNS do domeny.

Przejdź na stronę administracyjną IBM Bob. Wybierz kartę Authentication. Wybierz IdP zawierający domenę, którą chcesz zweryfikować. W sekcji Domain filters znajdź domenę i skopiuj wyświetlony kod weryfikacyjny. U swojego dostawcy DNS dodaj rekord TXT do domeny w następującym formacie:

bob-verify=<verification-code>

Zastąp verification-code kodem skopiowanym z sekcji Domain filters. Wróć na kartę Authentication i kliknij Check verification przy danej domenie.

Status weryfikacji domeny zmienia się na Verified, gdy IBM Bob pomyślnie wykryje rekord TXT. Propagacja zmian DNS może zająć trochę czasu.

Usuwanie dostawcy tożsamości

Przejdź na stronę administracyjną IBM Bob. Wybierz kartę Authentication. Znajdź IdP, który chcesz usunąć, i kliknij Delete. W oknie dialogowym potwierdzenia kliknij Confirm.

Ostrzeżenie:

Usunięcie IdP powoduje usunięcie konfiguracji SSO dla wszystkich powiązanych domen. Użytkownicy, którzy korzystali z tego IdP do uwierzytelniania, będą musieli zalogować się inną metodą. Ostrzeżenie jest wyświetlane, jeśli IdP ma zweryfikowane domeny.

Zarządzanie dostawcami tożsamości

Na tej stronie