Zarządzanie dostępem użytkowników w usłudze Azure Active Directory B2C
W tym artykule omówiono sposób zarządzania dostępem użytkowników do aplikacji przy użyciu usługi Azure Active Directory B2C (Azure AD B2C). Zarządzanie dostępem w aplikacji obejmuje:
- Identyfikowanie nieletnich i kontrolowanie dostępu użytkownika do aplikacji.
- Wymaganie zgody rodziców dla nieletnich do korzystania z Twoich aplikacji.
- Zbieranie danych urodzenia i kraju/regionu od użytkowników.
- Przechwytywanie umowy dotyczącej warunków użytkowania i pozyskiwanie dostępu.
Uwaga
W usłudze Azure Active Directory B2C zasady niestandardowe 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żytkowników. 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.
Kontrola dostępu pomocniczego
Aplikacje i organizacje mogą podjąć decyzję o zablokowaniu używania aplikacji i usług, które nie są przeznaczone dla tych odbiorców. Alternatywnie aplikacje i organizacje mogą podjąć decyzję o zaakceptowaniu nieletnich, a następnie zarządzaniu zgodą rodziców i dostarczać dopuszczalne doświadczenia dla nieletnich zgodnie z zasadami biznesowymi i dozwolone przez regulacje.
Jeśli użytkownik jest identyfikowany jako pomocniczy, możesz ustawić przepływ użytkownika w Azure AD B2C na jedną z trzech opcji:
Wyślij podpisaną id_token JWT z powrotem do aplikacji: użytkownik jest zarejestrowany w katalogu, a token jest zwracany do aplikacji. Następnie aplikacja przechodzi przez zastosowanie reguł biznesowych. Na przykład aplikacja może kontynuować proces wyrażania zgody rodzicielskiej. Aby użyć tej metody, wybierz odbieranie z aplikacji oświadczeń ageGroup i consentProvidedForMinor .
Wyślij niepodpisany token JSON do aplikacji: Azure AD B2C powiadamia aplikację, że użytkownik jest nieletni i zapewnia stan zgody rodzicielskiej użytkownika. Następnie aplikacja przechodzi przez zastosowanie reguł biznesowych. 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óry może zawierać nazwę, adres e-mail, grupę wiekową i zgodęProvidedForMinor.
Blokuj użytkownika: jeśli użytkownik jest nieletni, a zgoda rodzicielska nie została podana, Azure AD B2C może powiadomić użytkownika o zablokowaniu. Nie wystawiono tokenu, dostęp jest zablokowany, a konto użytkownika nie jest tworzone podczas podróży rejestracji. Aby zaimplementować to powiadomienie, należy podać odpowiednią stronę zawartości HTML/CSS, aby poinformować użytkownika i przedstawić odpowiednie opcje. Aplikacja nie wymaga dalszych działań na potrzeby nowych rejestracji.
Uzyskiwanie zgody rodziców
W zależności od regulacji aplikacji może być konieczne udzielenie zgody rodzicielskiej przez użytkownika, który jest weryfikowany jako osoba dorosła. Azure AD B2C nie zapewnia doświadczenia w celu zweryfikowania wieku osoby fizycznej, a następnie umożliwienia zweryfikowanej osoby dorosłej udzielenia zgody rodziców na osobę nieletnią. To środowisko musi być udostępniane przez aplikację lub innego dostawcę usług.
Poniżej przedstawiono przykład przepływu użytkownika na potrzeby zbierania zgody rodziców:
Operacja microsoft interfejs Graph API identyfikuje użytkownika jako pomocniczą i zwraca dane użytkownika do aplikacji w postaci niepodpisanego tokenu JSON.
Aplikacja przetwarza token JSON i wyświetla ekran do osoby pomocniczej, powiadamiając ich, że wymagana jest zgoda rodziców i żądanie zgody rodzica w trybie online.
Azure AD B2C pokazuje podróż logowania, do którego użytkownik może zalogować się normalnie i wystawia token do aplikacji, która ma zawierać wartość legalAgeGroupClassification = "minorWithParentalConsent". Aplikacja zbiera adres e-mail elementu nadrzędnego i sprawdza, czy element nadrzędny jest dorosłym. W tym celu używa zaufanego źródła, takiego jak krajowy/regionalny urząd identyfikatora, weryfikacja licencji lub dowód karty kredytowej. Jeśli weryfikacja zakończy się pomyślnie, aplikacja wyświetli monit o zalogowanie się przy użyciu przepływu użytkownika usługi Azure AD B2C. Jeśli odmowa zgody (na przykład jeśli legalAgeGroupClassification = "minorWithoutParentalConsent"), Azure AD B2C zwraca token JSON (a nie identyfikator logowania) do aplikacji w celu ponownego uruchomienia procesu wyrażania zgody. Opcjonalnie można dostosować przepływ użytkownika, aby osoba nieletnia lub osoba dorosła mogła odzyskać dostęp do konta osoby pomocniczej, wysyłając kod rejestracyjny na adres e-mail dziecka lub adres e-mail osoby dorosłej w rekordzie.
Aplikacja oferuje opcję odwoływanie zgody przez pomocniczą.
Gdy osoba pomocnicza lub osoba dorosła odwoła zgodę, interfejs Graph API microsoft może służyć do zmiany zgodyProvidedForMinor na odmowę. Alternatywnie aplikacja może zdecydować się na usunięcie osoby pomocniczej, której zgoda została odwołana. Opcjonalnie można dostosować przepływ użytkownika, aby uwierzytelniony element pomocniczy (lub element nadrzędny korzystający z konta osoby pomocniczej) mógł odwołać zgodę. Azure AD rekordy B2C consentProvidedForMinor jako odrzucone.
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 interfejs Graph API Microsoft należy użyć długiej wersji atrybutu, takiej jak extension_18b70cf9bb834edd8f38521c2583cd86_dateOfBirth: 2011-01-01T00:00:00Z.
Zbieranie danych o narodzinach i kraju/regionie
Aplikacje mogą polegać na Azure AD B2C, aby zebrać datę urodzenia (DOB) i informacje o kraju/regionie od wszystkich użytkowników podczas rejestracji. Jeśli te informacje jeszcze nie istnieją, aplikacja może zażądać jej od użytkownika podczas następnego uwierzytelniania (logowania). Użytkownicy nie mogą kontynuować pracy bez podawania informacji o dob i kraju/regionie. Azure AD B2C wykorzystuje informacje w celu ustalenia, czy dana osoba jest uważana za nieletnią zgodnie ze standardami regulacyjnymi tego kraju/regionu.
Dostosowany przepływ użytkownika może zbierać informacje o usłudze DOB i kraju/regionie oraz korzystać z przekształcenia Azure AD oświadczeń B2C w celu określenia grupy wiekowej i utrwalania wyniku (lub utrwalania informacji o kraju/regionie) w katalogu.
W poniższych krokach przedstawiono logikę używaną do obliczania grupy wiekowej na podstawie daty urodzenia użytkownika:
Spróbuj znaleźć kraj/region według kodu kraju/regionu na liście. Jeśli kraj/region nie zostanie znaleziony, wróć do domyślnego.
Jeśli węzeł MinorConsent znajduje się w elemecie kraj/region:
a. Oblicz datę urodzenia użytkownika, aby był uważany za dorosłego. Jeśli na przykład bieżąca data to 14 marca 2015 r., a wartość MinorConsent to 18, 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 jest wcześniejsza niż data urodzenia użytkownika, obliczenie zwraca wartość Pomocnicza jako obliczenie grupy wiekowej.
Jeśli węzeł MinorNoConsentRequired znajduje się w elemencie country/region, powtórz kroki 2a i 2b przy użyciu wartości z MinorNoConsentRequired. Dane wyjściowe 2b zwracają wartość MinorNoConsentRequired , jeśli minimalna data urodzenia przypada przed datą urodzenia użytkownika.
Jeśli żadne obliczenie nie zwróci wartości true, obliczenie zwraca wartość Adult.
Jeśli aplikacja niezawodnie zgromadziła dane DOB lub kraju/regionu za pomocą innych metod, aplikacja może użyć interfejs Graph API, aby zaktualizować rekord użytkownika przy użyciu tych informacji. Na przykład:
- Jeśli użytkownik jest znany jako dorosły, zaktualizuj atrybut directory ageGroup wartością Adult.
- Jeśli użytkownik jest znany jako pomocniczy, zaktualizuj atrybut directory ageGroup z wartością Pomocnicza i ustaw wartość consentProvidedForMinor zgodnie z potrzebami.
Reguły obliczeń pomocniczych
Starzenie się obejmuje dwie wartości wieku: wiek, w którym ktoś nie jest już uważany za nieletniego, oraz wiek, w którym osoba nieletnia musi mieć zgodę rodziców. W poniższej tabeli wymieniono reguły wieku, które są używane do definiowania drobnych i drobnych wymagających zgody.
| Kraj/region | Nazwa kraju/regionu | Niewielki wiek zgody | Niepełny wiek |
|---|---|---|---|
| Domyślny | Brak | Brak | 18 |
| AE | Zjednoczone Emiraty Arabskie | Brak | 21 |
| AT | Austria | 14 | 18 |
| BE | Belgia | 14 | 18 |
| BG | Bułgaria | 16 | 18 |
| BH | Bahrajn | Brak | 21 |
| CM | Kamerun | Brak | 21 |
| CY | Cypr | 16 | 18 |
| CZ | Republika Czeska | 16 | 18 |
| DE | Niemcy | 16 | 18 |
| DK | Dania | 16 | 18 |
| EE | Estonia | 16 | 18 |
| EG | Egipt | Brak | 21 |
| ES | Hiszpania | 13 | 18 |
| PW | Francja | 16 | 18 |
| GB | Zjednoczone Królestwo | 13 | 18 |
| GR | Grecja | 16 | 18 |
| HR | Chorwacja | 16 | 18 |
| HU | Węgry | 16 | 18 |
| IE | Irlandia | 13 | 18 |
| IT | Włochy | 16 | 18 |
| KR | Korea Południowa | 14 | 18 |
| LT | Litwa | 16 | 18 |
| LU | Luksemburg | 16 | 18 |
| LV | Łotwa | 16 | 18 |
| MT | Malta | 16 | 18 |
| NA | Namibia | Brak | 21 |
| NL | Holandia | 16 | 18 |
| PL | Polska | 13 | 18 |
| PT | Portugalia | 16 | 18 |
| RO | Rumunia | 16 | 18 |
| SE | Szwecja | 13 | 18 |
| SG | Singapur | Brak | 21 |
| SI | Słowenia | 16 | 18 |
| SK | Słowacja | 16 | 18 |
| TD | Czad | Brak | 21 |
| TH | Tajlandia | Brak | 20 |
| TW | Tajwan | Brak | 20 |
| USA | Stany Zjednoczone | 13 | 18 |
Przechwytywanie warunków użytkowania umowy
Podczas tworzenia aplikacji zwykle przechwytujesz akceptację warunków użytkowania użytkowników w swoich aplikacjach bez udziału w katalogu użytkowników. Istnieje jednak możliwość użycia przepływu użytkownika Azure AD B2C w celu zebrania akceptacji warunków użytkowania użytkownika, ograniczenia dostępu, jeśli akceptacja nie zostanie udzielona, i wymuszenie akceptacji przyszłych zmian warunków użytkowania na podstawie daty najnowszej akceptacji i daty najnowszej wersji warunków użytkowania.
Warunki użytkowania mogą również zawierać "Zgoda na udostępnianie danych osobom trzecim". W zależności od lokalnych przepisów i reguł biznesowych można zebrać akceptację obu warunków połączonych przez użytkownika lub zezwolić użytkownikowi na zaakceptowanie jednego warunku, a nie drugiego.
W poniższych krokach opisano sposób zarządzania warunkami użytkowania:
Zarejestruj akceptację warunków użytkowania i datę akceptacji przy użyciu interfejs Graph API i atrybutów rozszerzonych. Można to zrobić przy użyciu wbudowanych przepływów użytkownika i zasad niestandardowych. Zalecamy tworzenie i używanie atrybutów extension_termsOfUseConsentDateTime i extension_termsOfUseConsentVersion .
Utwórz wymagane pole wyboru z etykietą "Zaakceptuj warunki użytkowania" i zarejestruj wynik podczas rejestracji. Można to zrobić przy użyciu wbudowanych przepływów użytkownika i zasad niestandardowych.
Azure AD B2C przechowuje warunki użytkowania i akceptację użytkownika. Możesz użyć interfejs Graph API, aby wykonać zapytanie o stan dowolnego użytkownika, odczytując atrybut rozszerzenia używany do rejestrowania odpowiedzi (na przykład przeczytaj termsOfUseTestUpdateDateTime). Można to zrobić przy użyciu wbudowanych przepływów użytkownika i zasad niestandardowych.
Wymagaj akceptacji zaktualizowanych warunków użytkowania, porównując datę akceptacji z datą najnowszej wersji warunków użytkowania. Daty można porównać tylko przy użyciu niestandardowego przepływu użytkownika. Użyj atrybutu rozszerzonego extension_termsOfUseConsentDateTime i porównaj wartość z oświadczeniem termsOfUseTextUpdateDateTime. Jeśli akceptacja jest stara, wymuś nową akceptację, wyświetlając ekran z potwierdzeniem własnym. W przeciwnym razie zablokuj dostęp przy użyciu logiki zasad.
Wymagaj akceptacji zaktualizowanych warunków użytkowania przez porównanie numeru wersji akceptacji z najnowszym zaakceptowanym numerem wersji. Numery wersji można porównać tylko przy użyciu niestandardowego przepływu użytkownika. Użyj extension_termsOfUseConsentDateTime atrybutu rozszerzonego i porównaj wartość z oświadczeniem extension_termsOfUseConsentVersion. Jeśli akceptacja jest stara, wymuś nową akceptację, wyświetlając ekran z potwierdzeniem własnym. W przeciwnym razie zablokuj dostęp przy użyciu logiki zasad.
Warunki użytkowania można przechwycić w następujących scenariuszach:
- Nowy użytkownik rejestruje się. Warunki użytkowania są wyświetlane, a wynik akceptacji jest przechowywany.
- Użytkownik loguje się, kto wcześniej zaakceptował najnowsze lub aktywne warunki użytkowania. Warunki użytkowania nie są wyświetlane.
- Użytkownik loguje się, kto nie zaakceptował jeszcze najnowszych lub aktywnych warunków użytkowania. Warunki użytkowania są wyświetlane, a wynik akceptacji jest przechowywany.
- Użytkownik loguje się, kto zaakceptował już starszą wersję warunków użytkowania, która jest teraz aktualizowana do najnowszej wersji. Warunki użytkowania są wyświetlane, a wynik akceptacji jest przechowywany.
Na poniższej ilustracji przedstawiono zalecany przepływ użytkownika:
Poniżej przedstawiono przykładowe warunki użytkowania oparte na dacie w oświadczeniu.
extension_termsOfUseConsentDateTime Jeśli roszczenie jest starsze niż 2025-01-15T00:00:00, wymuś nową akceptację, sprawdzając termsOfUseConsentRequired oświadczenie warunkowe i wyświetlając ekran samozwańczy.
<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 przedstawiono przykład zgody na korzystanie z wersji w oświadczeniu.
extension_termsOfUseConsentVersion Jeśli oświadczenie nie jest równe V1, wymuś nową akceptację, sprawdzając termsOfUseConsentRequired oświadczenie logiczne i wyświetlając ekran samozwańczy.
<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>
Następne kroki
- Włącz age Gating w Azure AD B2C.
- Aby dowiedzieć się, jak usuwać i eksportować dane użytkowników, zobacz Zarządzanie danymi użytkownika.
- Przykładowe zasady niestandardowe implementujące monit o warunki użytkowania można znaleźć w temacie A B2C IEF Custom Policy - Sign Up and Sign In with "Terms of Use" prompt (Zasady niestandardowe protokołu IEF B2C — rejestrowanie się i logowanie przy użyciu monitu "Warunki użytkowania").