Hantera användaråtkomst i Azure Active Directory B2C

  • Artikel

Den här artikeln beskriver hur du hanterar användaråtkomst till dina program med hjälp av Azure Active Directory B2C (Azure AD B2C). Åtkomsthantering i ditt program omfattar:

  • Identifiera minderåriga och kontrollera användaråtkomst till ditt program.
  • Krav på föräldramedgivande för att minderåriga ska kunna använda dina program.
  • Samla in födelse- och lands-/regiondata från användare.
  • Samla in ett avtal om användningsvillkor och ge åtkomst.

Anteckning

I Azure Active Directory B2C är anpassade principer främst utformade för att hantera komplexa scenarier. I de flesta scenarier rekommenderar vi att du använder inbyggda användarflöden. Om du inte har gjort det kan du läsa mer om startpaketet för anpassad princip i Kom igång med anpassade principer i Active Directory B2C.

Kontrollera mindre åtkomst

Program och organisationer kan besluta att blockera minderåriga från att använda program och tjänster som inte är riktade till den här målgruppen. Alternativt kan program och organisationer besluta att acceptera minderåriga och därefter hantera föräldrarnas medgivande, och leverera tillåtna upplevelser för minderåriga enligt affärsregler och tillåtna genom reglering.

Om en användare identifieras som en del kan du ange användarflödet i Azure AD B2C till något av tre alternativ:

  • Skicka en signerad JWT-id_token tillbaka till programmet: Användaren är registrerad i katalogen och en token returneras till programmet. Programmet fortsätter sedan med att tillämpa affärsregler. Programmet kan till exempel fortsätta med en process för föräldramedgivande. Om du vill använda den här metoden väljer du att ta emot ageGroup - och consentProvidedForMinor-anspråken från programmet.

  • Skicka en osignerad JSON-token till programmet: Azure AD B2C meddelar programmet att användaren är mindre och ger status för användarens föräldramedgivande. Programmet fortsätter sedan med att tillämpa affärsregler. En JSON-token slutför inte en lyckad autentisering med programmet. Programmet måste bearbeta den oautentiserade användaren enligt de anspråk som ingår i JSON-token, som kan innehålla namn, e-post, ageGroup och consentProvidedForMinor.

  • Blockera användaren: Om en användare är minderårig och föräldrarnas medgivande inte har angetts kan Azure AD B2C meddela användaren att de är blockerade. Ingen token utfärdas, åtkomst blockeras och användarkontot skapas inte under en registreringsresa. För att implementera det här meddelandet tillhandahåller du en lämplig HTML/CSS-innehållssida för att informera användaren och presentera lämpliga alternativ. Inga ytterligare åtgärder krävs av programmet för nya registreringar.

Beroende på tillämpningsförordningen kan föräldramedgivande behöva beviljas av en användare som är verifierad som vuxen. Azure AD B2C ger inte någon upplevelse för att verifiera en individs ålder och sedan tillåta en verifierad vuxen att bevilja föräldramedgivande till en minderårig. Den här upplevelsen måste tillhandahållas av programmet eller någon annan tjänstleverantör.

Följande är ett exempel på ett användarflöde för insamling av föräldramedgivande:

  1. En Microsoft-Graph API-åtgärd identifierar användaren som en del och returnerar användardata till programmet i form av en osignerad JSON-token.

  2. Programmet bearbetar JSON-token och visar en skärm för den underåriga, meddelar dem att föräldramedgivande krävs och begär samtycke från en överordnad online.

  3. Azure AD B2C visar en inloggningsresa som användaren kan logga in på normalt och utfärdar en token till programmet som är inställt på att inkludera legalAgeGroupClassification = "minorWithParentalConsent". Programmet samlar in den överordnades e-postadress och verifierar att den överordnade är en vuxen. För att göra det använder den en betrodd källa, till exempel ett nationellt/regionalt ID-kontor, licensverifiering eller kreditkortsbevis. Om verifieringen lyckas uppmanar programmet delprogrammet att logga in med hjälp av Azure AD B2C-användarflöde. Om medgivande nekas (till exempel om legalAgeGroupClassification = "minorWithoutParentalConsent") returnerar Azure AD B2C en JSON-token (inte en inloggning) till programmet för att starta om medgivandeprocessen. Du kan också anpassa användarflödet så att en minderårig eller en vuxen kan få åtkomst till en minderårigs konto genom att skicka en registreringskod till den minderåriges e-postadress eller den vuxnas e-postadress i registret.

  4. Programmet erbjuder ett alternativ till den underåriga för att återkalla medgivande.

  5. När antingen den underåriga eller den vuxna återkallar medgivande kan Microsoft-Graph API användas för att ändra medgivandeProvidedForMinor till nekad. Alternativt kan programmet välja att ta bort en underordnad vars medgivande har återkallats. Du kan också anpassa användarflödet så att den autentiserade underordnad (eller överordnad som använder den underordnades konto) kan återkalla medgivandet. Azure AD B2C registrerar consentProvidedForMinor som nekad.

Mer information om legalAgeGroupClassification, consentProvidedForMinor och ageGroup finns i Användarresurstyp. Mer information om anpassade attribut finns i Använda anpassade attribut för att samla in information om dina konsumenter. När du hanterar utökade attribut med hjälp av Microsoft Graph API måste du använda den långa versionen av attributet, till exempel extension_18b70cf9bb834edd8f38521c2583cd86_dateOfBirth: 2011-01-01T00:00:00Z.

Samla in födelsedatum och lands-/regiondata

Program kan förlita sig på Azure AD B2C för att samla in födelsedatum (DOB) och land/regioninformation från alla användare under registreringen. Om den här informationen inte redan finns kan programmet begära den från användaren under nästa autentiseringsresa (inloggning). Användarna kan inte fortsätta utan att ange information om dob och land/region. Azure AD B2C använder informationen för att avgöra om personen anses vara minderårig enligt lagstiftningen i det landet/regionen.

Ett anpassat användarflöde kan samla in DOB- och land-/regioninformation och använda Azure AD B2C-anspråkstransformering för att fastställa ageGroup och bevara resultatet (eller spara DOB- och land-/regioninformationen direkt) i katalogen.

Följande steg visar logiken som används för att beräkna ageGroup från användarens födelsedatum:

  1. Försök att hitta land/region efter lands-/regionkoden i listan. Om landet/regionen inte hittas återgår du till Standard.

  2. Om noden MinorConsent finns i elementet land/region:

    a. Beräkna det datum då användaren måste ha fötts på för att betraktas som vuxen. Om det aktuella datumet till exempel är 14 mars 2015 och MinorConsent är 18 måste födelsedatumet vara senast den 14 mars 2000.

    b. Jämför det lägsta födelsedatumet med det faktiska födelsedatumet. Om det minsta födelsedatumet är före användarens födelsedatum returnerar beräkningen Mindre som åldersgruppsberäkning.

  3. Om noden MinorNoConsentRequired finns i elementet land/region upprepar du steg 2a och 2b med värdet från MinorNoConsentRequired. Utdata från 2b returnerar MinorNoConsentRequired om det minsta födelsedatumet är före användarens födelsedatum.

  4. Om ingen av beräkningen returnerar true returnerar beräkningen Vuxen.

Om ett program på ett tillförlitligt sätt har samlat in DOB- eller land-/regiondata med andra metoder kan programmet använda Graph API för att uppdatera användarposten med den här informationen. Exempel:

  • Om en användare är känd för att vara vuxen uppdaterar du katalogattributet ageGroup med värdet Vuxen.
  • Om en användare är känd för att vara en del uppdaterar du katalogattributet ageGroup med värdet Minor och anger consentProvidedForMinor efter behov.

Mindre beräkningsregler

Åldersgräns omfattar två åldersvärden: den ålder som någon inte längre betraktas som minderårig och den ålder då en minderårig måste ha föräldramedgivande. I följande tabell visas de åldersregler som används för att definiera en del och en mindre som kräver medgivande.

Land/region Namn på land/region Ålder för mindre medgivande Mindre ålder
Standardvärde Inga Inga 18
AE Förenade Arabemiraten Ingen 21
AT Österrike 14 18
BE Belgien 14 18
BG Bulgarien 16 18
BH Bahrain Ingen 21
CM Kamerun Ingen 21
CY Cypern 16 18
CZ Tjeckien 16 18
DE Tyskland 16 18
DK Danmark 16 18
EE Estland 16 18
EG Egypten Ingen 21
ES Spanien 13 18
FR Frankrike 16 18
GB Storbritannien 13 18
GR Grekland 16 18
HR Kroatien 16 18
HU Ungern 16 18
IE Irland 13 18
IT Italien 16 18
KR Sydkorea 14 18
LT Litauen 16 18
LU Luxemburg 16 18
LV Lettland 16 18
MT Malta 16 18
NA Namibia Ingen 21
NL Nederländerna 16 18
PL Polen 13 18
PT Portugal 16 18
RO Rumänien 16 18
SE Sverige 13 18
SG Singapore Ingen 21
SI Slovenien 16 18
SK Slovakien 16 18
TD Tchad Ingen 21
TH Thailand Ingen 20
TW Taiwan Ingen 20
USA USA 13 18

Samla in användningsvillkor

När du utvecklar ditt program samlar du vanligtvis in användarnas godkännande av användningsvillkor i sina program utan, eller endast mindre, deltagande från användarkatalogen. Det är dock möjligt att använda ett Azure AD B2C-användarflöde för att samla in en användares godkännande av användningsvillkor, begränsa åtkomsten om godkännande inte beviljas och framtvinga godkännande av framtida ändringar av användningsvillkoren, baserat på datumet för det senaste godkännandet och datumet för den senaste versionen av användningsvillkoren.

Användningsvillkoren kan också innehålla "Medgivande att dela data med tredje part". Beroende på lokala regler och affärsregler kan du samla in en användares godkännande av båda villkoren tillsammans, eller så kan du tillåta användaren att acceptera det ena villkoret och inte det andra.

Följande steg beskriver hur du kan hantera användningsvillkor:

  1. Registrera godkännandet av användningsvillkoren och datum för godkännande med hjälp av Graph API och utökade attribut. Du kan göra det med hjälp av både inbyggda användarflöden och anpassade principer. Vi rekommenderar att du skapar och använder attributen extension_termsOfUseConsentDateTime och extension_termsOfUseConsentVersion .

  2. Skapa en obligatorisk kryssruta med etiketten "Godkänn användningsvillkor" och registrera resultatet under registreringen. Du kan göra det med hjälp av både inbyggda användarflöden och anpassade principer.

  3. Azure AD B2C lagrar användningsvillkoren och användarens godkännande. Du kan använda Graph API för att fråga efter status för alla användare genom att läsa tilläggsattributet som används för att registrera svaret (till exempel läsa termernaOfUseTestUpdateDateTime). Du kan göra det med hjälp av både inbyggda användarflöden och anpassade principer.

  4. Kräv godkännande av uppdaterade användningsvillkor genom att jämföra godkännandedatumet med datumet för den senaste versionen av användningsvillkoren. Du kan bara jämföra datumen med hjälp av ett anpassat användarflöde. Använd det utökade attributet extension_termsOfUseConsentDateTime och jämför värdet med anspråket för termernaOfUseTextUpdateDateTime. Om godkännandet är gammalt framtvingar du ett nytt godkännande genom att visa en självbestämt skärm. Annars blockerar du åtkomst med hjälp av principlogik.

  5. Kräv godkännande av uppdaterade användningsvillkor genom att jämföra versionsnumret för godkännandet med det senaste accepterade versionsnumret. Du kan bara jämföra versionsnummer med hjälp av ett anpassat användarflöde. Använd det utökade attributet extension_termsOfUseConsentDateTime och jämför värdet med anspråket för extension_termsOfUseConsentVersion. Om godkännandet är gammalt framtvingar du ett nytt godkännande genom att visa en självbestämt skärm. Annars blockerar du åtkomst med hjälp av principlogik.

Du kan samla in godkännande av användningsvillkor i följande scenarier:

  • En ny användare registrerar sig. Användningsvillkoren visas och godkännanderesultatet lagras.
  • En användare loggar in som tidigare har accepterat de senaste eller aktiva användningsvillkoren. Användningsvillkoren visas inte.
  • En användare loggar in som inte redan har accepterat de senaste eller aktiva användningsvillkoren. Användningsvillkoren visas och godkännanderesultatet lagras.
  • En användare loggar in som redan har accepterat en äldre version av användningsvillkoren, som nu har uppdaterats till den senaste versionen. Användningsvillkoren visas och godkännanderesultatet lagras.

Följande bild visar det rekommenderade användarflödet:

Flödesdiagramdiagram som visar det rekommenderade användarflödet för godkännande

Följande är ett exempel på ett datumbaserat villkor för användningsmedgivande i ett anspråk. Om anspråket extension_termsOfUseConsentDateTime är äldre än 2025-01-15T00:00:00framtvingar du ett nytt godkännande genom att kontrollera det booleska anspråket termsOfUseConsentRequired och visa en självkontrollerad skärm.

<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>

Följande är ett exempel på ett versionsbaserat användningsvillkor i ett anspråk. Om anspråket extension_termsOfUseConsentVersion inte är lika med tvingar du fram ett nytt godkännande genom att V1kontrollera det booleska anspråket termsOfUseConsentRequired och visa en självkontrollerad skärm.

<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>

Nästa steg