Omówienie zasad niestandardowych usługi Azure AD B2C

  • Artykuł

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 usługi Azure AD B2C dla najbardziej typowych zadań związanych z tożsamościami, deweloper tożsamości może edytować zasady niestandardowe, aby wykonywać wiele różnych zadań.

Zasady niestandardowe są w pełni konfigurowalne i oparte na zasadach. Zasady niestandardowe organizuje zaufanie między jednostkami w standardowych protokołach. Na przykład openID Połączenie, OAuth, SAML i kilka niestandardowych, na przykład wymiany oświadczeń opartych na interfejsie API REST systemowo-systemowych. Platforma tworzy przyjazne dla użytkownika środowiska z etykietami białymi.

Zasady niestandardowe są reprezentowane jako co najmniej jeden plik sformatowany w formacie XML, który odwołuje 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 niestandardowych zasad usługi Azure AD B2C zawiera kilka wstępnie utworzonych zasad, aby szybko rozpocząć pracę. Każdy z tych pakietów startowych zawiera najmniejszą liczbę profilów technicznych i podróży użytkowników potrzebnych do osiągnięcia 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 przykładów odnosi się do tych zasad.
  • SocialAndLocalAccountsWithMFA — umożliwia opcje uwierzytelniania społecznościowego, lokalnego i wieloskładnikowego.

W repozytorium GitHub przykładów usługi Azure AD B2C znajdziesz przykłady dla kilku rozszerzonych niestandardowych podróży i scenariuszy ciaM usługi Azure AD B2C. Na przykład ulepszenia zasad konta lokalnego, ulepszenia zasad konta społecznościowego, ulepszenia uwierzytelniania wieloskładnikowego, ulepszenia interfejsu użytkownika, ogólne ulepszenia, migracja aplikacji, migracja użytkowników, dostęp warunkowy, test internetowy i ciągła integracja/ciągłe wdrażanie.

Informacje o podstawach

Roszczenia

Oświadczenie zapewnia tymczasowe przechowywanie danych podczas wykonywania zasad usługi Azure AD B2C. Oświadczenia są bardziej podobne do zmiennej w języku programowym. Może przechowywać informacje o użytkowniku, takie jak imię, nazwisko lub inne oświadczenie uzyskane od użytkownika lub innych systemów (wymiany oświadczeń). Schemat oświadczeń to miejsce, w którym zadeklarowane są oświadczenia.

Po uruchomieniu zasad usługa Azure AD B2C wysyła i odbiera oświadczenia do i z wewnętrznych i zewnętrznych stron, a następnie wysyła podzbiór tych oświadczeń do aplikacji jednostki uzależnionej w ramach tokenu. Oświadczenia są używane na następujące sposoby:

  • Oświadczenie jest zapisywane, odczytywane lub aktualizowane względem obiektu użytkownika katalogu.
  • Oświadczenie jest odbierane 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 oświadczenia od użytkownika podczas tworzenia konta lub edytowania przepływów profilu.

Manipulowanie oświadczeniami

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

Dostosowywanie i lokalizowanie interfejsu użytkownika

Aby zebrać informacje od użytkowników, przedstawiając stronę w przeglądarce internetowej, użyj własnego profilu technicznego. Możesz edytować własny profil techniczny, aby dodać oświadczenia i dostosować dane wejściowe użytkownika.

Aby dostosować interfejs użytkownika dla własnego profilu technicznego, należy określić adres URL w elemecie definicji zawartości z dostosowaną zawartością HTML. W samodzielnym profilu technicznym wskażesz ten identyfikator definicji zawartości.

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

Omówienie zasad jednostki uzależnionej

Aplikacja jednostki uzależnionej, która w protokole SAML jest znana jako dostawca usług, wywołuje zasady jednostki uzależnionej, aby wykonać określoną podróż użytkownika. Zasady jednostki uzależnionej określają podróż użytkownika do wykonania i listę oświadczeń, które zawiera token.

Diagram showing the policy execution flow

Wszystkie aplikacje jednostki uzależnionej korzystające z tych samych zasad otrzymują te same oświadczenia tokenu, a użytkownik przechodzi przez tę samą podróż użytkownika.

Podróże użytkownika

Podróże użytkowników umożliwiają zdefiniowanie logiki biznesowej ze ścieżką, za pomocą której użytkownik uzyskuje dostęp do aplikacji. Użytkownik przechodzi przez podróż użytkownika w celu pobrania oświadczeń, które mają być prezentowane aplikacji. Podróż użytkownika jest tworzona na podstawie sekwencji kroków aranżacji. Aby uzyskać token, użytkownik musi osiągnąć ostatni krok.

W poniższych instrukcjach opisano sposób dodawania kroków aranżacji do zasad pakietów startowych kont społecznościowych i lokalnych. Oto przykład dodanego wywołania interfejsu API REST.

customized user journey

Kroki orkiestracji

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

Użytkownik musi przejść do ostatniego kroku aranżacji w celu uzyskania tokenu. Użytkownicy mogą jednak nie podróżować przez wszystkie kroki orkiestracji. Kroki orkiestracji można wykonać warunkowo na podstawie warunków wstępnych zdefiniowanych w kroku aranżacji.

Po zakończeniu kroku aranżacji usługa Azure AD B2C przechowuje wyjściowe oświadczenia w torbie oświadczeń. Oświadczenia w torbie oświadczeń mogą być wykorzystywane przez dalsze kroki aranżacji w podróży użytkownika.

Na poniższym diagramie przedstawiono sposób, w jaki kroki aranżacji podróży użytkownika mogą uzyskać dostęp do torby oświadczeń.

Azure AD B2C user journey

Profil techniczny

Profil techniczny udostępnia interfejs do komunikowania się z różnymi typami stron. Podróż użytkownika łączy wywoływanie profilów technicznych za pomocą kroków aranżacji w celu zdefiniowania logiki biznesowej.

Wszystkie typy profilów technicznych mają taką samą koncepcję. Wysyłasz oświadczenia wejściowe, uruchamiasz transformację oświadczeń i komunikujesz się ze skonfigurowaną stroną. Po zakończeniu procesu profil techniczny zwraca oświadczenia wyjściowe do torby oświadczeń. Aby uzyskać więcej informacji, zobacz omówienie profilów technicznych.

Profil techniczny weryfikacji

Gdy użytkownik wchodzi w interakcję z interfejsem użytkownika, może być konieczne zweryfikowanie zebranych danych. Aby móc korzystać z użytkownika, należy użyć własnego profilu technicznego.

Aby zweryfikować dane wejściowe użytkownika, profil techniczny weryfikacji jest wywoływany z profilu technicznego z samodzielnego potwierdzenia. Profil techniczny weryfikacji to metoda wywoływania dowolnego nieinterakcyjnego profilu technicznego. W takim przypadku profil techniczny może zwracać oświadczenia wyjściowe lub komunikat o błędzie. Komunikat o błędzie jest renderowany dla użytkownika na ekranie, dzięki czemu użytkownik może ponowić próbę.

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

Validation technical profile diagram

Model dziedziczenia

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

  • Plik podstawowy zawierający większość definicji. Aby ułatwić rozwiązywanie problemów i długoterminową konserwację zasad, spróbuj zminimalizować liczbę zmian w tym pliku.
  • Plik lokalizacji, który zawiera ciągi lokalizacji. Ten plik zasad pochodzi z pliku podstawowego. Ten plik służy do obsługi różnych języków zgodnie z potrzebami klientów.
  • Plik Rozszerzeń, który zawiera unikatowe zmiany konfiguracji dla dzierżawy. Ten plik zasad pochodzi z pliku lokalizacji. Użyj tego pliku, aby dodać nowe funkcje lub zastąpić istniejące funkcje. 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 aplikacja internetowa, mobilna lub klasyczna. Każde unikatowe zadanie, takie jak rejestracja, logowanie lub edytowanie profilu, wymaga własnego pliku zasad jednostki uzależnionej. Ten plik zasad pochodzi z pliku rozszerzeń.

Model dziedziczenia wygląda następująco:

  • Zasady podrzędne na dowolnym poziomie mogą dziedziczyć z zasad nadrzędnych i rozszerzać je przez dodanie 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 jednostki uzależnionej. Na przykład usuń moje konto, zmień numer telefonu, zasady jednostki uzależnionej SAML i inne.

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

Diagram showing the trust framework policy inheritance model

Wskazówki i najlepsze rozwiązania

Najlepsze rozwiązania

W ramach niestandardowych zasad usługi Azure AD B2C możesz zintegrować własną logikę biznesową, aby utworzyć wymagane środowiska użytkownika i rozszerzyć funkcjonalność usługi. Mamy zestaw najlepszych rozwiązań i zaleceń, aby rozpocząć pracę.

  • Utwórz logikę w ramach zasad rozszerzenia lub zasad jednostki uzależnionej. Możesz dodać nowe elementy, które zastępują zasady podstawowe, odwołując się do tego samego identyfikatora. Takie podejście umożliwia skalowanie projektu w poziomie przy jednoczesnym ułatwianiu uaktualniania zasad bazowych później, jeśli firma Microsoft wyda nowe pakiety startowe.
  • W ramach zasad podstawowych zdecydowanie zalecamy unikanie wprowadzania jakichkolwiek zmian. W razie potrzeby wprowadź komentarze, w których wprowadzono zmiany.
  • Podczas zastępowania elementu, takiego jak metadane profilu technicznego, należy unikać kopiowania całego profilu technicznego z zasad podstawowych. Zamiast tego skopiuj tylko wymaganą sekcję elementu. Zobacz Wyłączanie weryfikacji poczty e-mail, aby zapoznać się z przykładem sposobu wprowadzania zmian.
  • Aby zmniejszyć duplikację profilów technicznych, w których udostępniana jest podstawowa funkcjonalność, należy użyć dołączania profilu technicznego.
  • 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 uzyskać lepsze środowisko użytkownika, upewnij się, że niestandardowe szablony HTML są globalnie wdrażane 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ę w podróży użytkownika, skopiuj całą podróż użytkownika z zasad podstawowych do zasad rozszerzenia. Podaj unikatowy identyfikator podróży użytkownika do skopiowanej podróży użytkownika. Następnie w zasadach jednostki uzależnionej zmień domyślny element podróży użytkownika, aby wskazać nową podróż użytkownika.

Rozwiązywanie problemów

Podczas opracowywania za pomocą zasad usługi Azure AD B2C można napotkać błędy lub wyjątki podczas wykonywania podróży użytkownika. Można je zbadać przy użyciu Szczegółowe informacje aplikacji.

Ciągła integracja

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

Przygotowywanie środowiska

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

  1. Tworzenie dzierżawy usługi Azure AD B2C
  2. Zarejestruj aplikację internetową przy użyciu witryny Azure Portal, aby móc przetestować zasady.
  3. Dodaj niezbędne klucze zasad i zarejestruj aplikacje platformy Identity Experience Framework.
  4. Pobierz pakiet startowy zasad usługi Azure AD B2C i przekaż go do dzierżawy.
  5. Po przekazaniu pakietu startowego przetestuj zasady rejestracji lub logowania.
  6. Zalecamy pobranie i zainstalowanie programu 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 przechodzić i edytować niestandardowe pliki XML zasad usługi Azure AD B2C, instalując rozszerzenie Usługi Azure AD B2C dla programu VS Code

Następne kroki

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