Samouczek: konfigurowanie usługi Ping Identity za pomocą usługi Azure Active Directory B2C na potrzeby bezpiecznego dostępu hybrydowego

Ważne

Od 1 maja 2025 r. usługa Azure AD B2C nie będzie już dostępna do zakupu dla nowych klientów. Dowiedz się więcej w naszych często zadawanych pytaniach.

Z tego samouczka dowiesz się, jak rozszerzyć możliwości usługi Azure Active Directory B2C (Azure AD B2C) za pomocą poleceń PingAccess i PingFederate. PingAccess zapewnia dostęp do aplikacji i interfejsów API oraz silnik zasad dla autoryzowanego dostępu użytkowników. PingFederate to serwer federacyjny przedsiębiorstwa używany do uwierzytelniania użytkowników i logowania jednokrotnego, systemu, który umożliwia klientom, pracownikom i partnerom dostęp do aplikacji na urządzeniach. Użyj ich razem, aby włączyć bezpieczny dostęp hybrydowy (SHA).

Wiele witryn handlu elektronicznego i aplikacji internetowych dostępnych w internecie jest wdrażanych za systemami proxy lub serwerem reverse-proxy. Te systemy proxy wstępnie uwierzytelniają się, wymuszają zasady i kierują ruch. Typowe scenariusze obejmują ochronę aplikacji internetowych przed przychodzącym ruchem internetowym i zapewnienie jednolitego zarządzania sesjami we wdrożeniach serwera rozproszonego.

Ogólnie rzecz biorąc, konfiguracje obejmują warstwę translacji uwierzytelniania, która wyodrębnia uwierzytelnianie z aplikacji internetowej. Odwrotne serwery proxy dostarczają uwierzytelniony kontekst użytkownika do aplikacji internetowych, takie jak wartość nagłówka w postaci czystej lub skompresowanej. Aplikacje nie używają standardowych tokenów branżowych, takich jak Security Assertion Markup Language (SAML), OAuth lub OpenID Connect (OIDC). Zamiast tego serwer proxy zapewnia kontekst uwierzytelniania i utrzymuje sesję z agentem użytkownika końcowego, takim jak przeglądarka lub aplikacja natywna. Jako usługa działająca jako pośrednik, serwery proxy zapewniają znaczącą kontrolę sesji. Usługa serwera proxy jest wydajna i skalowalna i nie stanowi wąskiego gardła dla aplikacji za usługą proxy. Diagram przedstawia implementację odwrotnego proxy i przepływ komunikacji.

Modernizacja

Jeśli chcesz zmodernizować platformę tożsamości w takich konfiguracjach, mogą występować obawy klientów:

• Oddzielenie wysiłków na rzecz modernizacji aplikacji od modernizacji platformy tożsamości
• Środowiska z nowoczesnym i starszym uwierzytelnianiem, korzystające ze zmodernizowanego dostawcy usług identyfikacyjnych.
  • Wspieranie spójności środowiska użytkownika końcowego
  • Zapewnić środowisko jednokrotnego logowania się w aplikacjach

W odpowiedzi na te obawy podejściem w tym samouczku jest integracja Azure AD B2C, PingAccess i PingFederate.

Środowisko udostępnione

Technicznie wykonalne i opłacalne rozwiązanie polega na skonfigurowaniu systemu serwera proxy odwrotnego do korzystania z unowocześnionego systemu tożsamości, delegując uwierzytelnianie.
Serwery proxy obsługują nowoczesne protokoły uwierzytelniania i używają uwierzytelniania opartego na przekierowaniu (pasywnym), które wysyła użytkowników do nowego dostawcy tożsamości (IdP).

Usługa Azure AD B2C jako dostawca tożsamości

W usłudze Azure AD B2C definiujesz zasady, które napędzają środowiska i zachowania użytkowników, nazywane również ścieżkami użytkowników. Każda taka polityka uwidacznia punkt końcowy protokołu, który może wykonywać uwierzytelnianie jako IdP (Dostawca Tożsamości). Po stronie aplikacji nie jest wymagana specjalna obsługa niektórych zasad. Aplikacja wysyła żądanie uwierzytelnienia standardowego do punktu końcowego uwierzytelniania specyficznego dla protokołu, określanego przez politykę.
Usługę Azure AD B2C można skonfigurować tak, aby współużytkować tego samego wystawcę między zasadami lub unikatowym wystawcą dla każdej zasady. Każda aplikacja może wskazywać zasady, tworząc uwierzytelniające żądanie natywne dla protokołu, które wpływa na zachowania użytkowników, takie jak logowanie, rejestracja i edytowanie profilu. Na diagramie przedstawiono przepływy pracy aplikacji OIDC i SAML.

Scenariusz może być trudny dla starszych aplikacji w celu dokładnego przekierowania użytkownika. Żądanie dostępu do aplikacji może nie zawierać kontekstu środowiska użytkownika. W większości przypadków warstwa serwera proxy lub zintegrowany agent w aplikacji internetowej przechwytuje żądanie dostępu.

Zwrotny serwer proxy PingAccess

Funkcję PingAccess można wdrożyć jako zwrotny serwer proxy. Funkcja PingAccess przechwytuje bezpośrednie żądanie, działając jako pośrednik lub poprzez przekierowanie z agenta uruchomionego na serwerze aplikacji internetowej.

Skonfiguruj funkcję PingAccess przy użyciu protokołu OIDC, OAuth2 lub SAML na potrzeby uwierzytelniania za pomocą nadrzędnego dostawcy uwierzytelniania. Na serwerze PingAccess można skonfigurować nadrzędnego dostawcę tożsamości w tym celu. Zobacz poniższy diagram.

W typowym wdrożeniu usługi Azure AD B2C z zasadami uwzględniającymi dostawców tożsamości istnieje wyzwanie. Funkcja PingAccess jest skonfigurowana przy użyciu jednego nadrzędnego dostawcy tożsamości.

Serwer proxy federacji PingFederate

Serwer PingFederate można skonfigurować jako dostawcę uwierzytelniania lub serwer proxy dla IdP wyższego poziomu. Zobacz poniższy diagram.

Użyj tej funkcji do kontekstowego, dynamicznego lub deklaratywnego przełączania żądania przychodzącego do polityki Azure AD B2C. Zobacz poniższy diagram przepływu sekwencji protokołów.

Wymagania wstępne

Aby rozpocząć pracę, potrzebne są następujące elementy:

• Subskrypcja platformy Azure
  • Jeśli go nie masz, uzyskaj bezpłatne konto platformy Azure
• Dzierżawa usługi Azure AD B2C połączona z subskrypcją platformy Azure
• PingAccess i PingFederate wdrożone w kontenerach platformy Docker lub na maszynach wirtualnych platformy Azure

Łączność i komunikacja

Potwierdź następującą łączność i komunikację.

• Serwer PingAccess — komunikuje się z serwerem PingFederate, przeglądarką klienta, identyfikatorem OIDC, dobrze znanym uwierzytelnianiem OAuth i odnajdywaniem kluczy opublikowanym przez usługę Azure AD B2C i serwer PingFederate
• Serwer PingFederate — komunikuje się z serwerem PingAccess, przeglądarką klienta, identyfikatorem OIDC, dobrze znanym uwierzytelnianiem OAuth i odnajdywaniem kluczy opublikowanym przez usługę Azure AD B2C
• Starsza lub oparta na nagłówku aplikacja AuthN — komunikuje się do i z serwera PingAccess
• Aplikacja strony ufającej SAML — obsługuje ruch przeglądarki pochodzący od klienta. Uzyskuje dostęp do metadanych federacji SAML opublikowanych przez usługę Azure AD B2C.
• Nowoczesna aplikacja — przejmuje ruch przeglądarki od klienta. Uzyskuje dostęp do dobrze znanego odnajdywania OIDC, OAuth i kluczy opublikowanych przez usługę Azure AD B2C.
• Interfejs API REST — obsługuje ruch od klienta natywnego lub internetowego. Uzyskuje dostęp do opublikowanych przez usługę Azure AD B2C funkcji odnajdywania OIDC, OAuth oraz kluczy.

Konfigurowanie usługi Azure AD B2C

Możesz użyć podstawowych przepływów użytkowników lub zaawansowanych zasad programu Identity Enterprise Framework (IEF). Funkcja PingAccess generuje punkt końcowy metadanych na podstawie wartości wystawcy przy użyciu protokołu WebFinger na potrzeby konwencji odnajdywania. Aby postępować zgodnie z tą konwencją, zaktualizuj wystawcę Azure AD B2C, korzystając z właściwości polityki przepływu użytkownika.

W zaawansowanych zasadach konfiguracja obejmuje element metadanych IssuanceClaimPattern na wartość AuthorityWithTfp w profilu technicznym wystawcy JWT.

Skonfiguruj PingAccess i PingFederate

Skorzystaj z instrukcji w poniższych sekcjach, aby skonfigurować funkcje PingAccess i PingFederate. Zobacz poniższy diagram przedstawiający ogólny przepływ użytkownika w integracji.

Konfigurowanie usługi PingFederate jako dostawcy tokenu

Aby skonfigurować system PingFederate jako dostawcę tokenów dla PingAccess, upewnij się, że istnieje łączność między PingFederate a PingAccess. Potwierdź łączność z PingAccess do PingFederate.

Konfigurowanie aplikacji PingAccess na potrzeby uwierzytelniania opartego na nagłówku

Skorzystaj z poniższych instrukcji, aby utworzyć aplikację PingAccess dla docelowej aplikacji internetowej na potrzeby uwierzytelniania opartego na nagłówku.

Tworzenie hosta wirtualnego

Ważne

Utwórz hosta wirtualnego dla każdej aplikacji.

Aby utworzyć hosta wirtualnego:

1. Przejdź do pozycji Ustawienia>Uzyskiwanie dostępu do>hostów wirtualnych.
2. Wybierz pozycję Dodaj hosta wirtualnego.
3. W polu Host wprowadź odpowiednią część FQDN adresu URL aplikacji.
4. W polu Port wprowadź 443.
5. Wybierz pozycję Zapisz.

Tworzenie sesji internetowej

Aby utworzyć sesję internetową:

1. Przejdź do pozycji Ustawienia>Uzyskiwanie dostępu do>sesji sieci Web.
2. Wybierz pozycję Dodaj sesję sieci Web.
3. Wprowadź nazwę sesji sieci Web.
4. Wybierz typ pliku cookie: podpisany zestaw JWT lub zaszyfrowany zestaw JWT.
5. Wprowadź unikatową wartość dla grupy odbiorców.
6. W polu Identyfikator klienta wprowadź identyfikator aplikacji Entra firmy Microsoft.
7. W polu Klucz tajny klienta wprowadź klucz wygenerowany dla aplikacji w identyfikatorze Entra firmy Microsoft.
8. (Opcjonalnie) Tworzenie i używanie oświadczeń niestandardowych za pomocą interfejsu API programu Microsoft Graph: wybierz pozycję Zaawansowane. Usuń zaznaczenie Request Profile (Profil żądania) i Refresh User Attributes (Odśwież atrybuty użytkownika). Dowiedz się więcej o oświadczeniach niestandardowych: logowanie jednokrotne oparte na nagłówku dla aplikacji lokalnych przy użyciu serwera proxy aplikacji Microsoft Entra.
9. Wybierz Zapisz

Tworzenie mapowania tożsamości

Uwaga

Możesz użyć mapowania tożsamości z więcej niż jedną aplikacją, jeśli oczekują one tych samych danych w nagłówku.

Aby utworzyć mapowanie tożsamości:

1. Przejdź do Ustawienia>Dostęp>Mapowania tożsamości.
2. Wybierz pozycję Dodaj mapowanie tożsamości.
3. Określ *nazwę.
4. Wybierz typ mapowania tożsamości nagłówka.
5. W tabeli Mapowanie atrybutów określ wymagane mapowania. Na przykład

Nazwa atrybutu	Nazwa nagłówka
"upn"	x-userprincipalname (nazwa główna użytkownika)
"e-mail"	x-email (x-email)
"oid"	x-oid (x-oid)
"scp"	x-scope (zakres x)
"amr"	Napęd X-AMR

6. Wybierz Zapisz

Tworzenie witryny

Uwaga

W niektórych konfiguracjach lokacja może zawierać wiele aplikacji. W razie potrzeby można użyć witryny z więcej niż jedną aplikacją.

Aby utworzyć witrynę:

1. Przejdź do witryn głównych>.
2. Wybierz pozycję Dodaj witrynę.
3. Wprowadź nazwę witryny.
4. Wejdź na witrynę Target. Elementem docelowym jest para hostname:port dla serwera obsługującego aplikację. Nie wprowadzaj ścieżki aplikacji w tym polu. Na przykład aplikacja w lokalizacji https://mysite:9999/AppName ma wartość docelową mysite:9999.
5. Określ, czy obiekt docelowy oczekuje bezpiecznych połączeń.
6. Jeśli obiekt docelowy oczekuje bezpiecznych połączeń, ustaw grupę zaufanych certyfikatów na Ufaj dowolnym.
7. Wybierz pozycję Zapisz.

Tworzenie aplikacji

Aby utworzyć aplikację w funkcji PingAccess dla każdej aplikacji na platformie Azure, którą chcesz chronić.

1. Przejdź do głównych>aplikacji

2. Wybierz pozycję Dodaj aplikację

3. Określanie nazwy aplikacji

4. Opcjonalnie wprowadź opis aplikacji

5. Określ katalog główny aplikacji dla aplikacji. Na przykład aplikacja w https://mysite:9999/AppName będzie mieć kontekst root /AppName. Katalog kontekstu musi zaczynać się od ukośnika (/), nie może kończyć się ukośnikiem (/) i może mieć więcej niż jedną warstwę, na przykład /Apps/MyApp.

6. Wybierz utworzony host wirtualny

   Uwaga

   Kombinacja wirtualnego hosta i kontekstowego katalogu głównego musi być unikatowa w PingAccess.

7. Wybierz utworzoną sesję internetową

8. Wybierz utworzoną witrynę zawierającą aplikację

9. Wybierz utworzone mapowanie tożsamości

10. Wybierz pozycję Włączone , aby włączyć witrynę podczas zapisywania

11. Wybierz Zapisz

Konfigurowanie zasad uwierzytelniania PingFederate

Skonfiguruj zasadę uwierzytelniania PingFederate, aby federować z różnymi dostawcami tożsamości oferowanymi przez dzierżawców Azure AD B2C

1. Utwórz kontrakt, aby połączyć atrybuty między dostawcami tożsamości i dostawcą usług. Należy potrzebować tylko jednego kontraktu, chyba że dostawca usług wymaga innego zestawu atrybutów od każdego dostawcy tożsamości. Aby uzyskać więcej informacji, zobacz Federation Hub and authentication policy contracts (Kontrakty zasad federacyjnych i uwierzytelniania ) w dokumentacji usługi Ping Identity.

2. Dla każdego dostawcy tożsamości utwórz połączenie IdP między dostawcą tożsamości i serwerem PingFederate, koncentratorem federacyjnym jako SP (dostawcą usług).

3. W oknie Mapowanie sesji docelowej dodaj odpowiednie kontrakty zasad uwierzytelnienia do połączenia IdP.

4. W oknie Selektory skonfiguruj selektor uwierzytelniania. Na przykład, zobacz wystąpienie Adaptera Identyfikatora First, aby przypisać każdego dostawcę tożsamości do odpowiedniego połączenia z dostawcą tożsamości w polityce uwierzytelniania.

5. Utwórz połączenie SP między serwerem PingFederate, centrum federacyjnym jako IdP, a SP.

6. Dodaj odpowiedni kontrakt zasad uwierzytelniania do połączenia SP w oknie Mapowanie źródła uwierzytelniania.

7. Współpracuj z każdym dostawcą tożsamości, aby nawiązać połączenie z PingFederate, który działa jako koncentrator federacyjny i dostawca usług.

8. Skontaktuj się z dostawcą usług, aby nawiązać połączenie z serwerem PingFederate, koncentratorem federacyjnym jako dostawcą tożsamości.

Następne kroki

Aby uzyskać dodatkowe informacje, zapoznaj się z następującymi artykułami

• Zasady niestandardowe w usłudze Azure AD B2C

• Rozpocznij pracę z zasadami niestandardowymi w usłudze Azure AD B2C