Samouczek: konfigurowanie tożsamości ping przy użyciu usługi Azure Active Directory B2C pod kątem bezpiecznego dostępu hybrydowego

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. Funkcja PingAccess zapewnia dostęp do aplikacji i interfejsów API oraz aparatu zasad na potrzeby autoryzowanego dostępu użytkowników. PingFederate to serwer federacyjny przedsiębiorstwa umożliwiający uwierzytelnianie użytkowników i logowanie jednokrotne, urząd, który umożliwia klientom, pracownikom i partnerom dostęp do aplikacji z urządzeń. Użyj ich razem, aby włączyć bezpieczny dostęp hybrydowy (SHA).

Wiele witryn handlu elektronicznego i aplikacji internetowych uwidocznionych w Internecie jest wdrażanych za systemami proxy lub systemem odwrotnego serwera 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ę tłumaczenia uwierzytelniania, która umożliwia zewnętrzne uwierzytelnianie z aplikacji internetowej. Zwrotne serwery proxy zapewniają uwierzytelniony kontekst użytkownika w aplikacjach internetowych, na przykład wartość nagłówka w postaci jasnej lub szyfrowanej. 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 man-in-the-middle serwery proxy zapewniają znaczną kontrolę sesji. Usługa proxy jest wydajna i skalowalna, a nie wąskim gardłem dla aplikacji za usługą proxy. Diagram jest implementacją odwrotnego serwera proxy i przepływem komunikacji.

Modernizacja

Jeśli chcesz zmodernizować platformę tożsamości w takich konfiguracjach, mogą wystąpić 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 tożsamości
  • Zapewnienie spójności środowiska użytkownika końcowego
  • Zapewnianie środowiska logowania jednokrotnego w aplikacjach

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

Środowisko udostępnione

Technicznie opłacalne i ekonomiczne rozwiązanie polega na skonfigurowaniu systemu odwrotnego serwera proxy do korzystania z zmodernizowanego systemu tożsamości, delegowania uwierzytelniania.
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).

Azure AD B2C jako dostawca tożsamości

W Azure AD B2C definiujesz zasady, które napędzają środowiska użytkownika i zachowania, nazywane również podróżami użytkowników. Każda z takich zasad uwidacznia punkt końcowy protokołu, który może przeprowadzić uwierzytelnianie jako dostawcę tożsamości. Po stronie aplikacji nie jest wymagana specjalna obsługa niektórych zasad. Aplikacja wysyła standardowe żądanie uwierzytelniania do punktu końcowego uwierzytelniania specyficznego dla protokołu uwidacznianego przez zasady.
Można skonfigurować Azure AD B2C, aby współużytkować tego samego wystawcę między zasadami lub unikatowym wystawcą dla poszczególnych zasad. Każda aplikacja może wskazywać zasady, tworząc natywne dla protokołu żądanie uwierzytelniania, które napędza 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 funkcji PingAccess

Funkcję PingAccess można wdrożyć jako zwrotny serwer proxy. Funkcja PingAccess przechwytuje bezpośrednie żądanie, będąc man-in-the-middle lub przekierowaniem z agenta uruchomionego na serwerze aplikacji internetowej.

Skonfiguruj funkcję PingAccess z protokołem OIDC, OAuth2 lub SAML na potrzeby uwierzytelniania za pomocą nadrzędnego dostawcy uwierzytelniania. W tym celu można skonfigurować nadrzędną dostawcę tożsamości na serwerze PingAccess. Zapoznaj się z poniższym diagramem.

W typowym Azure AD wdrożeniu B2C z zasadami uwidacznianymi dostawcami tożsamości jest 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 nadrzędnych dostawców tożsamości. Zapoznaj się z poniższym diagramem.

Ta funkcja służy do kontekstowego, dynamicznego lub deklaratywnego przełączania żądania przychodzącego na zasady usługi 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 znanymi kluczami i odnajdywaniem kluczy opublikowanych 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 opublikowanych przez usługę Azure AD B2C
• Starsza lub oparta na nagłówku aplikacja AuthN — komunikuje się z serwerem PingAccess i z serwera PingAccess
• Aplikacja jednostki uzależnionej SAML — dociera do ruchu przeglądarki od klienta. Uzyskuje dostęp do metadanych federacji SAML opublikowanych przez usługę Azure AD B2C.
• Nowoczesna aplikacja — dociera do ruchu przeglądarki z klienta. Uzyskuje dostęp do dobrze znanego odnajdywania identyfikatorów OIDC, OAuth i kluczy opublikowanych przez usługę Azure AD B2C.
• Interfejs API REST — dociera do ruchu z natywnego lub internetowego klienta. Uzyskuje dostęp do dobrze znanego odnajdywania identyfikatorów OIDC, OAuth i kluczy opublikowanych przez usługę Azure AD B2C

Konfigurowanie Azure AD B2C

Możesz użyć podstawowych przepływów użytkownika 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 przy użyciu właściwości zasad przepływu użytkownika.

W zaawansowanych zasadach konfiguracja obejmuje element metadanych WystawianieClaimPattern do wartości AuthorityWithTfp w profilu technicznym wystawcy tokenu JWT.

Konfigurowanie funkcji PingAccess i pingFederate

Skorzystaj z instrukcji w poniższych sekcjach, aby skonfigurować funkcje PingAccess i PingFederate. Zapoznaj się z poniższym diagramem ogólnego przepływu użytkownika integracji.

Konfigurowanie usługi PingFederate jako dostawcy tokenów

Aby skonfigurować usługę PingFederate jako dostawca tokenów dla funkcji PingAccess, upewnij się, że łączność z serwera PingFederate do usługi PingAccess. Potwierdź łączność z funkcji PingAccess do polecenia PingFederate.

Aby uzyskać więcej informacji, zobacz Konfigurowanie narzędzia PingFederate jako dostawcy tokenu dla funkcji PingAccess w dokumentacji usługi Ping Identity.

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 uzyskać więcej informacji, zobacz Co mogę skonfigurować za pomocą funkcji PingAccess? w dokumentacji usługi Ping Identity.

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ź część nazwy FQDN adresu URL aplikacji.
4. W polu Port wprowadź wartość 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ę internetową.
3. Wprowadź nazwę sesji sieci Web.
4. Wybierz typ pliku cookie: Podpisany JWT lub Zaszyfrowany zestaw JWT.
5. Wprowadź unikatową wartość dla grupy odbiorców.
6. W polu Identyfikator klienta wprowadź identyfikator aplikacji Microsoft Entra.
7. W polu Klucz tajny klienta wprowadź klucz wygenerowany dla aplikacji w identyfikatorze Microsoft Entra.
8. (Opcjonalnie) Tworzenie i używanie oświadczeń niestandardowych za pomocą interfejs Graph API firmy Microsoft: wybierz pozycję Zaawansowane. Usuń zaznaczenie pola Wyboru profilu żądania i 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 pozycję 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 pozycji Ustawienia>Mapowania tożsamościdostępu>.
2. Wybierz pozycję Dodaj mapowanie tożsamości.
3. Określ *nazwę.
4. Wybierz typ mapowania tożsamości mapowania tożsamości 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
"wiadomość e-mail"	x-email
"oid"	x-oid
"scp"	x-scope
"amr"	x-amr

6. Wybierz pozycję Zapisz

Tworzenie lokacji

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ź dowitryngłównych>.
2. Wybierz pozycję Dodaj witrynę.
3. Wprowadź nazwę witryny.
4. Wprowadź element docelowy witryny. Elementem docelowym jest para hostname:port dla serwera hostowania aplikacji. 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 opcję Zaufana grupa certyfikatów na Wartość Dowolna.
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 pozycji Główne>aplikacje

2. Wybierz pozycję Dodaj aplikację

3. Określanie nazwy aplikacji

4. Opcjonalnie wprowadź opis aplikacji

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

6. Wybierz utworzony host wirtualny

   Uwaga

   Kombinacja wirtualnego hosta i katalogu głównego kontekstu musi być unikatowa w funkcji 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ę po zapisaniu

11. Wybierz pozycję Zapisz

Konfigurowanie zasad uwierzytelniania PingFederate

Skonfiguruj zasady uwierzytelniania PingFederate, aby sfederować wiele dostawców tożsamości udostępnianych przez dzierżawy usługi 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ługi wymaga innego zestawu atrybutów od każdego dostawcy tożsamości. Aby uzyskać więcej informacji, zobacz Federacja centrum i kontrakty zasad uwierzytelniania w dokumentacji usługi Ping Identity.

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

3. W oknie Mapowanie sesji docelowej dodaj odpowiednie kontrakty zasad uwierzytelniania do połączenia dostawcy tożsamości.

4. W oknie Selektory skonfiguruj selektor uwierzytelniania. Na przykład zobacz wystąpienie pierwszej karty identyfikatora , aby zamapować każdego dostawcę tożsamości na odpowiednie połączenie dostawcy tożsamości w zasadach uwierzytelniania.

5. Utwórz połączenie sp między serwerem PingFederate, centrum federacyjnym jako dostawcą tożsamości i dostawcą usług.

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 usługą PingFederate, koncentratorem federacyjnym jako dostawcą usług.

8. Skontaktuj się z dostawcą usług, aby nawiązać połączenie z usługą 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

• Wprowadzenie do zasad niestandardowych w usłudze Azure AD B2C