Udostępnij za pośrednictwem


Omówienie zasad niestandardowych usługi Azure AD B2C

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.

Zasady niestandardowe to pliki konfiguracji definiujące zachowanie Twojej dzierżawy usługi Azure Active Directory B2C (Azure AD B2C). Chociaż przepływy użytkowników są wstępnie zdefiniowane w portalu Azure AD B2C dla najbardziej typowych zadań związanych z tożsamościami, deweloper tożsamości może edytować zasady niestandardowe, aby wykonać wiele różnych zadań.

Polityka niestandardowa jest w pełni konfigurowalna i zarządzana przez zasady. Niestandardowa polityka koordynuje zaufanie między podmiotami w standardowych protokołach. Na przykład OpenID Connect, OAuth, SAML i kilka niestandardowych, na przykład wymiana oświadczeń system-system oparta na REST API. Platforma tworzy przyjazne dla użytkownika środowiska z etykietami białymi.

Zasady niestandardowe są reprezentowane przez jeden lub więcej plików w formacie XML, które odwołują się do siebie w łańcuchu hierarchicznym. Elementy XML definiują bloki konstrukcyjne, interakcję z użytkownikiem i innymi stronami oraz logikę biznesową.

Niestandardowy pakiet startowy zasad

Pakiet startowy zasad niestandardowych usługi Azure AD B2C zawiera kilka wstępnie utworzonych zasad, które umożliwiają szybkie rozpoczęcie pracy. Każdy z tych pakietów startowych zawiera najmniejszą liczbę profili technicznych i podróży użytkowników potrzebnych do realizacji opisanych scenariuszy:

  • Konta lokalne — umożliwia korzystanie tylko z kont lokalnych.
  • SocialAccounts — umożliwia korzystanie tylko z kont społecznościowych (lub federacyjnych).
  • SocialAndLocalAccounts — umożliwia korzystanie zarówno z kont lokalnych, jak i społecznościowych. Większość naszych próbek odnosi się do tej polityki.
  • SocialAndLocalAccountsWithMFA — umożliwia opcje uwierzytelniania społecznościowego, lokalnego i wieloskładnikowego.

W repozytorium GitHub z przykładami usługi Azure AD B2C znajdują się przykłady dla kilku rozbudowanych, personalizowanych ścieżek i scenariuszy użytkowników usługi Azure AD B2C. Na przykład ulepszenia zasad kont lokalnych, ulepszenia zasad kont społecznościowych, ulepszenia uwierzytelniania wieloskładnikowego, ulepszenia interfejsu użytkownika, ulepszenia ogólne, migracja aplikacji, migracja użytkowników, dostęp zależny od warunków, test internetowy i integracja ciągła/ciągłe wdrażanie.

Zrozumienie podstaw

Oświadczenia

Roszczenie zapewnia tymczasowe przechowywanie danych podczas wykonywania polityki usługi Azure AD B2C. Twierdzenia bardziej przypominają zmienne w języku programowania. Może przechowywać informacje o użytkowniku, takie jak imię, nazwisko rodowe lub wszelkie inne roszczenia uzyskane od użytkownika lub innych systemów (wymiana roszczeń). Schemat oświadczeń to miejsce, w którym zadeklarowane są oświadczenia.

Gdy polityka jest uruchomiona, Azure AD B2C wysyła i odbiera oświadczenia do i od stron wewnętrznych i zewnętrznych, a następnie wysyła podzbiór tych oświadczeń do aplikacji bazującej na użytkowniku jako część tokenu. Oświadczenia są używane w następujący sposób:

  • Oświadczenie jest zapisywane, odczytywane lub aktualizowane względem obiektu użytkownika katalogu.
  • Odebrano oświadczenie od zewnętrznego dostawcy tożsamości.
  • Oświadczenia są wysyłane lub odbierane przy użyciu niestandardowej usługi interfejsu API REST.
  • Dane są zbierane jako roszczenia od użytkownika podczas procesu rejestracji lub edycji profilu.

Manipulowanie roszczeniami

Przekształcenia oświadczeń to wstępnie zdefiniowane funkcje, których można użyć do przekonwertowania danego oświadczenia na inne, oceny oświadczenia lub ustawienia wartości oświadczenia. Na przykład dodanie elementu do kolekcji ciągów znaków, zmiana wielkości liter ciągu znaków lub ocena roszczenia dotyczącego daty i godziny. Przekształcenie wymagań określa metodę transformacji, która jest również wstępnie zdefiniowana.

Dostosuj i zlokalizuj swój interfejs użytkownika

Aby zbierać informacje od użytkowników poprzez wyświetlanie strony w ich przeglądarce internetowej, użyj profilu technicznego z własnym potwierdzeniem. Możesz edytować swój własny profil techniczny, aby dodawać oświadczenia i dostosowywać dane wejściowe użytkownika.

Aby dostosować interfejs użytkownika do własnego profilu technicznego, należy określić adres URL w elemencie definicji zawartości z dostosowaną zawartością HTML. W samodzielnie określonym profilu technicznym należy wskazać ten identyfikator definicji zawartości.

Aby dostosować ciągi specyficzne dla języka, użyj elementu localization . Definicja zawartości może zawierać odwołanie do lokalizacji , które określa listę zlokalizowanych zasobów do załadowania. Azure AD B2C scala elementy interfejsu użytkownika z zawartością HTML, która jest ładowana z adresu URL, a następnie wyświetla stronę użytkownikowi.

Omówienie zasad strony ufającej

Aplikacja jednostki uzależnionej, która w protokole SAML jest nazywana dostawcą usług, wywołuje zasady jednostki uzależnionej w celu wykonania określonej podróży użytkownika. Zasady jednostki uzależnionej określają podróż użytkownika, która ma zostać wykonana, oraz listę oświadczeń, które zawiera token.

Diagram przedstawiający przepływ wykonywania zasad

Wszystkie aplikacje klientów, które używają tej samej polityki, otrzymują te same atrybuty tokenów, a użytkownik przechodzi przez tę samą ścieżkę użytkownika.

Podróże użytkowników

Podróże użytkowników umożliwiają zdefiniowanie logiki biznesowej ze ścieżką, przez którą użytkownik podąża w celu uzyskania dostępu do aplikacji. Użytkownik jest przeprowadzany przez proces użytkownika w celu pobrania oświadczeń, które mają być zaprezentowane w aplikacji. Podróż użytkownika jest tworzona na podstawie sekwencji kroków aranżacji. Użytkownik musi wykonać ostatni krok, aby uzyskać token.

W poniższych instrukcjach opisano, jak dodać kroki orkiestracji do polityki pakietu startowego kont społecznościowych i lokalnych. Oto przykład wywołania REST API, które zostało dodane.

Spersonalizowana podróż użytkownika

Kroki orkiestracji

Krok aranżacji odwołuje się do metody, która implementuje swój zamierzony cel lub funkcjonalność. Ta metoda nazywana jest profilem technicznym. Gdy podróż użytkownika musi się rozgałęzić, aby lepiej reprezentować logikę biznesową, krok orkiestracji odwołuje się do podróży podrzędnej. Podróż podrzędna zawiera własny zestaw kroków aranżacji.

Aby uzyskać token, użytkownik musi dotrzeć do ostatniego etapu orchestration w ścieżce użytkownika. Jednak użytkownicy mogą nie musieć przechodzić przez wszystkie kroki aranżacji. Kroki aranżacji mogą być wykonywane warunkowo na podstawie warunków wstępnych zdefiniowanych w kroku aranżacji.

Po zakończeniu kroku aranżacji Azure AD B2C przechowuje wyprowadzone oświadczenia w torbie oświadczeń. Oświadczenia w zbiorze oświadczeń mogą być wykorzystywane przez kolejne etapy organizacji w ścieżce użytkownika.

Na poniższym diagramie pokazano, w jaki sposób kroki zarządzania podróżą użytkownika mogą uzyskać dostęp do zbioru roszczeń.

Podróż użytkownika usługi Azure AD B2C

Profil techniczny

Profil techniczny udostępnia interfejs do komunikowania się z różnymi typami podmiotów. Ścieżka użytkownika łączy wywoływanie profilów technicznych za pośrednictwem kroków orkiestracji w celu zdefiniowania logiki biznesowej.

Wszystkie typy profili technicznych mają tę samą koncepcję. Wysyłasz oświadczenia wejściowe, uruchamiasz przekształcanie oświadczeń i komunikujesz się ze skonfigurowaną stroną. Po zakończeniu procesu profil techniczny zwraca roszczenia wyjściowe do zbioru roszczeń. Aby uzyskać więcej informacji, zobacz Omówienie profilów technicznych.

Profil techniczny walidacji

Gdy użytkownik wchodzi w interakcję z interfejsem użytkownika, może być konieczne zweryfikowanie zebranych danych. Aby wchodzić w interakcje z użytkownikiem, należy użyć profilu technicznego , który sam sobie narzucił.

Aby zweryfikować dane wejściowe użytkownika, wywoływany jest profil techniczny walidacji z samodzielnie potwierdzonego profilu technicznego. Profil techniczny walidacji to metoda wywołania dowolnego profilu technicznego, który nie jest interaktywny. W takim przypadku profil techniczny może zwrócić oświadczenia wyjściowe lub komunikat o błędzie. Komunikat o błędzie jest renderowany do użytkownika na ekranie, umożliwiając użytkownikowi ponowienie próby.

Na poniższym diagramie pokazano, jak Azure AD B2C używa profilu technicznego weryfikacji do weryfikowania poświadczeń użytkownika.

Diagram profilu technicznego walidacji

Model dziedziczenia

Każdy pakiet startowy zawiera następujące pliki:

  • Plik podstawowy, który zawiera większość definicji. Aby ułatwić rozwiązywanie problemów i długoterminową konserwację zasad, spróbuj zminimalizować liczbę zmian wprowadzanych w tym pliku.
  • Plik lokalizacji, który zawiera ciągi lokalizacji. Ten plik zasad pochodzi z pliku podstawowego. Użyj tego pliku, aby dostosować różne języki do potrzeb klienta.
  • Plik rozszerzeń, który zawiera unikatowe zmiany konfiguracji dla lokatora. Ten plik strategii pochodzi z pliku lokalizacji. Użyj tego pliku, aby dodać nową funkcję lub zastąpić istniejącą funkcję. Na przykład użyj tego pliku, aby sfederować się z nowymi dostawcami tożsamości.
  • Plik jednostki uzależnionej (RP), który jest pojedynczym plikiem skoncentrowanym na zadaniu, który jest wywoływany bezpośrednio przez aplikację jednostki uzależnionej, taką jak aplikacje internetowe, mobilne lub klasyczne. Każde unikalne zadanie, takie jak rejestracja, logowanie lub edycja profilu, wymaga własnego pliku polityki strony zaufanej. Ten plik zasad pochodzi z pliku rozszerzeń.

Model dziedziczenia jest następujący:

  • Polityki podrzędne na dowolnym poziomie mogą dziedziczyć z polityki nadrzędnej i rozszerzać ją przez dodawanie nowych elementów.
  • W przypadku bardziej złożonych scenariuszy można dodać więcej poziomów dziedziczenia (łącznie do 10).
  • Możesz dodać więcej zasad stron ufających. Na przykład usuń moje konto, zmień numer telefonu, zasady jednostki uzależnionej SAML i nie tylko.

Na poniższym diagramie przedstawiono relację między plikami zasad a aplikacjami jednostki uzależnionej.

Diagram przedstawiający model dziedziczenia zasad struktury zaufania

Wskazówki i najlepsze rozwiązania

Najlepsze rozwiązania

W ramach zasad niestandardowych usługi Azure AD B2C można zintegrować własną logikę biznesową w celu tworzenia wymaganych środowisk użytkowników i rozszerzania funkcjonalności usługi. Mamy zestaw najlepszych praktyk i zaleceń na początek.

  • Utwórz logikę w obrębie zasad rozszerzenia lub zasad strony polegającej. Możesz dodać nowe elementy, które zastępują zasady podstawowe, odwołując się do tego samego identyfikatora. Takie podejście umożliwia poziome skalowanie projektu, jednocześnie ułatwiając uaktualnianie polityk bazowych później, jeśli firma Microsoft wyda nowe pakiety startowe.
  • W ramach zasad podstawowych zdecydowanie zalecamy unikanie wprowadzania jakichkolwiek zmian. W razie potrzeby zakomentuj miejsca, w których zostały wprowadzone zmiany.
  • W przypadku zastępowania elementu, takiego jak metadane profilu technicznego, unikaj kopiowania całego profilu technicznego z polityki bazowej. Zamiast tego skopiuj tylko wymaganą sekcję elementu. Zobacz Wyłączanie weryfikacji adresu e-mail , aby zapoznać się z przykładem wprowadzania zmian.
  • Aby ograniczyć powielanie profilów technicznych, w których podstawowe funkcje są współdzielone, użyj dołączania profilów technicznych.
  • Unikaj zapisywania w katalogu Microsoft Entra podczas logowania, co może prowadzić do problemów z ograniczaniem przepustowości.
  • Jeśli zasady mają zależności zewnętrzne, takie jak interfejsy API REST, upewnij się, że są one wysoce dostępne.
  • Aby zapewnić lepsze wrażenia użytkownika, upewnij się, że niestandardowe szablony HTML są wdrażane globalnie przy użyciu dostarczania zawartości online. Usługa Azure Content Delivery Network (CDN) pozwala skrócić czas ładowania, zaoszczędzić przepustowość i zwiększyć szybkość odpowiedzi.
  • Jeśli chcesz wprowadzić zmianę ścieżki użytkownika, skopiuj całą ścieżkę użytkownika z polityki podstawowej do polityki rozszerzenia. Podaj unikatowy identyfikator dla ścieżki użytkownika, którą skopiowałeś. Następnie w polityce strony współpracującej zmień domyślną podróż użytkownika, aby wskazywała na nową podróż użytkownika.

Rozwiązywanie problemów

Podczas pracy nad zasadami Azure AD B2C mogą wystąpić błędy lub wyjątki podczas realizacji scenariusza użytkownika. Można to zbadać przy użyciu usługi Application Insights.

Ciągła integracja

Korzystając z potoku ciągłej integracji i dostarczania (CI/CD) skonfigurowanego w usłudze Azure Pipelines, możesz uwzględnić zasady niestandardowe usługi Azure AD B2C w automatyzacji dostarczania oprogramowania i zarządzaniu kodem. Podczas wdrażania w różnych środowiskach Azure AD B2C, na przykład deweloperskich, testowych i produkcyjnych, zalecamy usunięcie procesów ręcznych i przeprowadzenie automatycznego testowania przy użyciu usługi Azure Pipelines.

Przygotowywanie środowiska

Rozpoczynasz pracę z zasadami niestandardowymi usługi Azure AD B2C:

  1. Utwórz dzierżawcę usługi Azure AD B2C
  2. Zarejestruj aplikację internetową przy użyciu Azure Portal, aby móc przetestować zasady.
  3. Dodaj niezbędne klucze zasad i zarejestruj aplikacje Identity Experience Framework.
  4. Pobierz pakiet startowy zasad usługi Azure AD B2C i przekaż go do dzierżawy.
  5. Po przesłaniu pakietu startowego przetestuj zasady rejestracji lub logowania.
  6. Zalecamy pobranie i zainstalowanie Visual Studio Code (VS Code). Visual Studio Code to lekki, ale zaawansowany edytor kodu źródłowego, który działa na pulpicie i jest dostępny dla systemów Windows, macOS i Linux. Za pomocą programu VS Code można szybko nawigować i edytować pliki XML zasad niestandardowych usługi Azure AD B2C, instalując rozszerzenie Azure AD B2C dla programu VS Code

Po skonfigurowaniu i przetestowaniu zasad usługi Azure AD B2C możesz rozpocząć dostosowywanie zasad. Zapoznaj się z poniższymi artykułami, aby dowiedzieć się, jak: