Udostępnij przez


Zarządzanie dostępem użytkowników w usłudze Azure Active Directory 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.

W tym artykule omówiono sposób zarządzania dostępem użytkowników do aplikacji przy użyciu Azure Active Directory B2C (Azure AD B2C). Zarządzanie dostępem w aplikacji obejmuje:

  • Identyfikowanie osób niepełnoletnich i kontrolowanie dostępu użytkowników do aplikacji.
  • Wymaganie zgody rodziców na korzystanie z aplikacji przez osoby niepełnoletnie.
  • Zbieranie danych o narodzinach i kraju/regionie od użytkowników.
  • Przechwytywanie umowy dotyczącej warunków użytkowania i bramkowanie dostępu.

Uwaga / Notatka

W usłudze Azure Active Directory B2C niestandardowe zasady są przeznaczone głównie do rozwiązywania złożonych scenariuszy. W przypadku większości scenariuszy zalecamy używanie wbudowanych przepływów użytkownika. Jeśli nie zostało to zrobione, dowiedz się więcej o niestandardowym pakiecie startowym zasad w temacie Wprowadzenie do zasad niestandardowych w usłudze Active Directory B2C.

Kontrolowanie dostępu osób pomocniczych

Aplikacje i organizacje mogą zdecydować o zablokowaniu osobom niepełnoletnim możliwości korzystania z aplikacji i usług, które nie są przeznaczone dla tej grupy odbiorców. Alternatywnie, aplikacje i organizacje mogą zdecydować o przyjęciu osób niepełnoletnich, a następnie zarządzać zgodą rodziców i zapewnić dozwolone doświadczenia dla nieletnich, zgodnie z regułami biznesowymi i dozwolonymi przez przepisy.

Jeśli użytkownik zostanie zidentyfikowany jako osoba niepełnoletnia, możesz ustawić przepływ użytkownika w Azure AD B2C na jedną z trzech opcji:

  • Wyślij podpisany id_token JWT z powrotem do aplikacji: Użytkownik jest rejestrowany w katalogu, a token jest zwracany do aplikacji. Następnie aplikacja przechodzi dalej, stosując reguły biznesowe. Na przykład aplikacja może kontynuować proces uzyskiwania zgody rodzicielskiej. Aby skorzystać z tej metody, wybierz opcję otrzymywania z aplikacji roszczeń ageGroup i consentProvidedForMinor .

  • Wyślij niepodpisany token JSON do aplikacji: Azure AD B2C powiadamia aplikację, że użytkownik jest osobą niepełnoletnią, i podaje stan zgody rodzicielskiej użytkownika. Następnie aplikacja przechodzi dalej, stosując reguły biznesowe. Token JSON nie kończy pomyślnego uwierzytelniania w aplikacji. Aplikacja musi przetworzyć nieuwierzytelnionego użytkownika zgodnie z oświadczeniami zawartymi w tokenie JSON, które mogą obejmować imię i nazwisko, adres e-mail, grupę wiekową i consentProvidedForMinor.

  • Zablokuj użytkownika: Jeśli użytkownik jest niepełnoletni, a zgoda rodzicielska nie została udzielona, Azure AD B2C może powiadomić użytkownika, że jest zablokowany. Nie jest wystawiany żaden token, dostęp jest blokowany, a konto użytkownika nie jest tworzone podczas procesu rejestracji. Aby zaimplementować to powiadomienie, należy dostarczyć odpowiednią stronę z zawartością HTML/CSS, która informuje użytkownika i przedstawia odpowiednie opcje. W przypadku nowych rejestracji aplikacja nie musi podejmować żadnych dalszych działań.

W zależności od przepisów dotyczących aplikacji może być konieczne udzielenie zgody rodzicielskiej przez użytkownika, który jest zweryfikowany jako osoba dorosła. Azure AD B2C nie zapewnia środowiska do weryfikowania wieku osoby, a następnie zezwalania zweryfikowanej osobie dorosłej na udzielenie zgody rodzicielskiej osobie niepełnoletniej. To doświadczenie musi być zapewnione przez aplikację lub innego usługodawcę.

Poniżej znajduje się przykład przepływu użytkownika służącego do zbierania zgody rodzicielskiej:

  1. Operacja interfejsu API programu Microsoft Graph identyfikuje użytkownika jako osobę pomocniczą i zwraca dane użytkownika do aplikacji w postaci niepodpisanego tokenu JSON.

  2. Aplikacja przetwarza token JSON i wyświetla ekran osobie niepełnoletniej, powiadamiając ją, że wymagana jest zgoda rodzicielska i prosząc rodzica o zgodę online.

  3. Azure AD B2C pokazuje podróż logowania, do której użytkownik może się normalnie zalogować, i wystawia token do aplikacji, która jest ustawiona tak, aby zawierała legalAgeGroupClassification = "minorWithParentalConsent". Aplikacja zbiera adres e-mail rodzica i weryfikuje, czy rodzic jest osobą pełnoletnią. W tym celu korzysta z zaufanego źródła, takiego jak krajowe/regionalne biuro dowodu osobistego, weryfikacja licencji lub dowód karty kredytowej. Jeśli weryfikacja zakończy się pomyślnie, aplikacja wyświetli monit o zalogowanie się osoby niepełnoletniej przy użyciu przepływu użytkownika Azure AD B2C. Jeśli zgoda zostanie odrzucona (na przykład jeśli legalAgeGroupClassification = "minorWithoutParentalConsent"), Azure AD B2C zwraca token JSON (nie login) do aplikacji, aby ponownie uruchomić proces wyrażania zgody. Opcjonalnie możliwe jest dostosowanie przepływu użytkownika w taki sposób, aby osoba niepełnoletnia lub osoba dorosła mogła odzyskać dostęp do konta osoby niepełnoletniej, wysyłając kod rejestracyjny na adres e-mail osoby niepełnoletniej lub zarejestrowany adres e-mail osoby dorosłej.

  4. Aplikacja oferuje osobie niepełnoletniej możliwość cofnięcia zgody.

  5. Gdy osoba niepełnoletnia lub dorosła odwoła zgodę, interfejs API programu Microsoft Graph może zostać użyty do zmiany wartości consentProvidedForMinor na odmowę. Alternatywnie wniosek może zdecydować o usunięciu osoby niepełnoletniej, której zgoda została cofnięta. Opcjonalnie można dostosować przepływ użytkownika w taki sposób, aby uwierzytelniona osoba niepełnoletnia (lub rodzic korzystający z konta osoby niepełnoletniej) mogła cofnąć zgodę. Azure AD B2C rejestruje consentProvidedForMinor jako odmowę.

Aby uzyskać więcej informacji na temat legalAgeGroupClassification, consentProvidedForMinor i ageGroup, zobacz Typ zasobu użytkownika. Aby uzyskać więcej informacji na temat atrybutów niestandardowych, zobacz Używanie atrybutów niestandardowych do zbierania informacji o użytkownikach. W przypadku adresowania atrybutów rozszerzonych przy użyciu interfejsu API programu Microsoft Graph należy użyć długiej wersji atrybutu, takiej jak extension_18b70cf9bb834edd8f38521c2583cd86_dateOfBirth: 2011-01-01T00:00:00Z.

Zbieranie danych o dacie urodzenia i kraju/regionie

Aplikacje mogą polegać na usłudze Azure AD B2C w celu zbierania informacji o dacie urodzenia (DOB) i kraju/regionie od wszystkich użytkowników podczas rejestracji. Jeśli te informacje jeszcze nie istnieją, aplikacja może zażądać ich od użytkownika podczas następnej podróży uwierzytelniania (logowania). Użytkownicy nie mogą kontynuować bez podania swojej daty urodzenia i informacji o kraju/regionie. Azure AD B2C używa tych informacji do określenia, czy dana osoba jest uważana za osobę niepełnoletnią zgodnie ze standardami prawnymi tego kraju/regionu.

Dostosowany przepływ użytkownika może zbierać informacje o DOB i kraju/regionie oraz używać transformacji oświadczeń Azure AD B2C w celu określenia grupy wiekowej i utrwalenia wyniku (lub bezpośredniego utrwalenia informacji o DOB i kraju/regionie) w katalogu.

W poniższych krokach przedstawiono logikę używaną do obliczania grupy wiekowej na podstawie daty urodzenia użytkownika:

  1. Spróbuj znaleźć kraj/region według kodu kraju/regionu na liście. Jeśli kraj/region nie zostanie znaleziony, wróć do opcji Domyślne.

  2. Jeśli węzeł MinorConsent znajduje się w elemencie kraju/regionu:

    a. Oblicz datę, w której użytkownik musiał się urodzić, aby został uznany za dorosłego. Na przykład, jeśli bieżąca data to 14 marca 2015 r., a MinorConsent to 18 lat, data urodzenia nie może być późniejsza niż 14 marca 2000 r.

    b. Porównaj minimalną datę urodzenia z rzeczywistą datą urodzenia. Jeśli minimalna data urodzenia przypada przed datą urodzenia użytkownika, obliczenia zwracają wartość Niepełnoletnia jako obliczenie grupy wiekowej.

  3. Jeśli węzeł MinorNoConsentRequired znajduje się w elemencie kraju/regionu, powtórz kroki 2a i 2b, używając wartości z MinorNoConsentRequired. Dane wyjściowe 2b zwracają wartość MinorNoConsentRequired , jeśli minimalna data urodzenia jest wcześniejsza niż data urodzenia użytkownika.

  4. Jeśli żadne z obliczeń nie zwróci wartości true, obliczenia zwrócą wartość Adult.

Jeśli aplikacja niezawodnie zebrała dane o dniu urodzenia lub kraju/regionie innymi metodami, może użyć interfejsu Graph API do zaktualizowania rekordu użytkownika o te informacje. Przykład:

  • Jeśli wiadomo, że użytkownik jest osobą dorosłą, zaktualizuj atrybut ageGroup w katalogu o wartość Adult.
  • Jeśli wiadomo, że użytkownik jest osobą niepełnoletnią, zaktualizuj atrybut katalogu ageGroup o wartość Minor i ustaw odpowiednią wartość consentProvidedForMinor.

Drobne reguły obliczeniowe

Bramkowanie wiekowe obejmuje dwie wartości wieku: wiek, w którym dana osoba nie jest już uważana za niepełnoletnią, oraz wiek, w którym osoba niepełnoletnia musi mieć zgodę rodziców. W poniższej tabeli wymieniono reguły wiekowe, które są używane do definiowania osoby niepełnoletniej i osoby niepełnoletniej wymagającej zgody.

Kraj/region Nazwa kraju/regionu Wiek zgody osoby niepełnoletniej Niepełnoletni wiek
Wartość domyślna Żaden Żaden 18
AE Zjednoczone Emiraty Arabskie Żaden dwadzieścia jeden
PRZY Austria 14 18
BYĆ Belgia 14 18
BG Bułgaria 16 18
BH Bahrajn Żaden dwadzieścia jeden
CENTYMETR Kamerun Żaden dwadzieścia jeden
CY Cypr 16 18
CZ Republika Czeska 16 18
Niemcy Niemcy 16 18
DK Dania 16 18
EE Estonia 16 18
NP Egipt Żaden dwadzieścia jeden
ES Hiszpania 13 18
Francja Francja 16 18
GB Wielka Brytania 13 18
GR Grecja 16 18
Zasoby Ludzkie Chorwacja 16 18
HU Węgry 16 18
IE (Internet Explorer) Irlandia 13 18
Dział IT Włochy 16 18
KR Republika Korei 14 18
LT Litwa 16 18
LU Luksemburg 16 18
Łotwa Łotwa 16 18
MT Malta 16 18
NIE Namibia Żaden dwadzieścia jeden
Holandia Holandia 16 18
Polska Polska 13 18
PT Portugalia 16 18
RO Rumunia 16 18
SE Szwecja 13 18
SG Singapur Żaden dwadzieścia jeden
Międzynarodowy Układ Jednostek SI Słowenia 16 18
SK Słowacja 16 18
TD Czad Żaden dwadzieścia jeden
TH Tajlandia Żaden 20
TW Tajwan Żaden 20
USA Stany Zjednoczone 13 18

Umowa dotycząca warunków użytkowania

Podczas tworzenia aplikacji zwykle rejestruje się akceptację warunków użytkowania w ich aplikacjach przez użytkowników bez udziału lub z niewielkim udziałem ze strony katalogu użytkowników. Istnieje jednak możliwość użycia przepływu użytkownika usługi Azure AD B2C w celu zebrania akceptacji warunków użytkowania przez użytkownika, ograniczenia dostępu, jeśli akceptacja nie zostanie udzielona, i wymuszenia akceptacji przyszłych zmian warunków użytkowania na podstawie daty ostatniej akceptacji i daty najnowszej wersji warunków użytkowania.

Warunki użytkowania mogą również zawierać "Zgodę na udostępnianie danych stronom trzecim". W zależności od lokalnych przepisów i reguł biznesowych możesz zebrać akceptację obu warunków przez użytkownika razem lub zezwolić użytkownikowi na zaakceptowanie jednego warunku, a nie drugiego.

W poniższych krokach opisano, jak można zarządzać warunkami użytkowania:

  1. Rejestruj akceptację warunków użytkowania i datę akceptacji przy użyciu interfejsu Graph API i atrybutów rozszerzonych. Można to zrobić przy użyciu zarówno wbudowanych przepływów użytkowników, jak i zasad niestandardowych. Zalecamy utworzenie i używanie atrybutów extension_termsOfUseConsentDateTime i extension_termsOfUseConsentVersion .

  2. Utwórz wymagane pole wyboru oznaczone "Zaakceptuj warunki użytkowania" i zapisz wynik podczas rejestracji. Można to zrobić przy użyciu zarówno wbudowanych przepływów użytkowników, jak i zasad niestandardowych.

  3. W usłudze Azure AD B2C jest przechowywana umowa dotycząca warunków użytkowania i akceptacja użytkownika. Za pomocą interfejsu Graph API można wykonywać zapytania o stan dowolnego użytkownika, odczytując atrybut rozszerzenia, który jest używany do rejestrowania odpowiedzi (na przykład odczyt termsOfUseTestUpdateDateTime). Można to zrobić przy użyciu zarówno wbudowanych przepływów użytkowników, jak i zasad niestandardowych.

  4. Wymagaj akceptacji zaktualizowanych warunków użytkowania, porównując datę akceptacji z datą najnowszej wersji warunków użytkowania. Daty można porównywać tylko przy użyciu niestandardowego przepływu użytkownika. Użyj atrybutu extended extension_termsOfUseConsentDateTime i porównaj wartość z oświadczeniem termsOfUseTextUpdateDateTime. Jeśli akceptacja jest stara, wymuś nową akceptację, wyświetlając ekran z własnym potwierdzeniem. W przeciwnym razie zablokuj dostęp przy użyciu logiki zasad.

  5. Wymagaj akceptacji zaktualizowanych warunków użytkowania, porównując numer wersji akceptacji z najnowszym zaakceptowanym numerem wersji. Numery wersji można porównywać tylko przy użyciu niestandardowego przepływu użytkownika. Użyj atrybutu extended extension_termsOfUseConsentDateTime i porównaj wartość z oświadczeniem extension_termsOfUseConsentVersion. Jeśli akceptacja jest stara, wymuś nową akceptację, wyświetlając ekran z własnym potwierdzeniem. W przeciwnym razie zablokuj dostęp przy użyciu logiki zasad.

Akceptację warunków użytkowania można przechwycić w następujących scenariuszach:

  • Rejestruje się nowy użytkownik. Warunki użytkowania są wyświetlane, a wynik akceptacji jest przechowywany.
  • Loguje się użytkownik, który wcześniej zaakceptował najnowsze lub aktywne warunki użytkowania. Warunki użytkowania nie są wyświetlane.
  • Loguje się użytkownik, który nie zaakceptował jeszcze najnowszych lub aktywnych warunków użytkowania. Warunki użytkowania są wyświetlane, a wynik akceptacji jest przechowywany.
  • Loguje się użytkownik, który zaakceptował już starszą wersję warunków użytkowania, która została zaktualizowana do najnowszej wersji. Warunki użytkowania są wyświetlane, a wynik akceptacji jest przechowywany.

Na poniższej ilustracji przedstawiono zalecany przepływ użytkownika:

Diagram schematu blokowego przedstawiający zalecany przepływ użytkowników akceptacji

Poniżej znajduje się przykład zgody na korzystanie z usług na podstawie daty w roszczeniu. extension_termsOfUseConsentDateTime Jeśli oświadczenie jest starsze niż 2025-01-15T00:00:00, wymuś nową akceptację, sprawdzając termsOfUseConsentRequired oświadczenie logiczne i wyświetlając ekran z własnym potwierdzeniem.

<ClaimsTransformations>
  <ClaimsTransformation Id="GetNewUserAgreeToTermsOfUseConsentDateTime" TransformationMethod="GetCurrentDateTime">
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="extension_termsOfUseConsentDateTime" TransformationClaimType="currentDateTime" />
    </OutputClaims>
  </ClaimsTransformation>
  <ClaimsTransformation Id="IsTermsOfUseConsentRequired" TransformationMethod="IsTermsOfUseConsentRequired">
    <InputClaims>
      <InputClaim ClaimTypeReferenceId="extension_termsOfUseConsentDateTime" TransformationClaimType="termsOfUseConsentDateTime" />
    </InputClaims>
    <InputParameters>
      <InputParameter Id="termsOfUseTextUpdateDateTime" DataType="dateTime" Value="2025-01-15T00:00:00" />
    </InputParameters>
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="termsOfUseConsentRequired" TransformationClaimType="result" />
    </OutputClaims>
  </ClaimsTransformation>
</ClaimsTransformations>

Poniżej znajduje się przykład zgody na warunki użytkowania opartej na wersji w roszczeniu. extension_termsOfUseConsentVersion Jeśli twierdzenie nie jest równe V1, wymuś nową akceptację, sprawdzając termsOfUseConsentRequired oświadczenie logiczne i wyświetlając ekran z własnym potwierdzeniem.

<ClaimsTransformations>
  <ClaimsTransformation Id="GetEmptyTermsOfUseConsentVersionForNewUser" TransformationMethod="CreateStringClaim">
    <InputParameters>
      <InputParameter Id="value" DataType="string" Value=""/>
    </InputParameters>
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="extension_termsOfUseConsentVersion" TransformationClaimType="createdClaim" />
    </OutputClaims>
  </ClaimsTransformation>
  <ClaimsTransformation Id="GetNewUserAgreeToTermsOfUseConsentVersion" TransformationMethod="CreateStringClaim">
    <InputParameters>
      <InputParameter Id="value" DataType="string" Value="V1"/>
    </InputParameters>
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="extension_termsOfUseConsentVersion" TransformationClaimType="createdClaim" />
    </OutputClaims>
  </ClaimsTransformation>
  <ClaimsTransformation Id="IsTermsOfUseConsentRequiredForVersion" TransformationMethod="CompareClaimToValue">
    <InputClaims>
      <InputClaim ClaimTypeReferenceId="extension_termsOfUseConsentVersion" TransformationClaimType="inputClaim1" />
    </InputClaims>
    <InputParameters>
      <InputParameter Id="compareTo" DataType="string" Value="V1" />
      <InputParameter Id="operator" DataType="string" Value="not equal" />
      <InputParameter Id="ignoreCase" DataType="string" Value="true" />
    </InputParameters>
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="termsOfUseConsentRequired" TransformationClaimType="outputClaim" />
    </OutputClaims>
  </ClaimsTransformation>
</ClaimsTransformations>

Dalsze kroki