Управление доступом пользователей в Azure Active Directory B2C

В этой статье показано, как управлять доступом пользователей к приложениям с помощью Azure Active Directory B2C (Azure AD B2C). Управление доступом в приложении включает следующие аспекты:

  • Выявление несовершеннолетних и ограничение доступа пользователей к приложению.
  • Получение родительского согласия на использование приложений несовершеннолетним пользователем.
  • Сбор данных о дате рождения и стране или регионе пребывания пользователя.
  • Получение соглашения с условиями использования и ограничение доступа.

Примечание

В Azure Active Directory B2C пользовательские политики преимущественно предназначены для выполнения сложных сценариев. В большинстве случаев рекомендуется использовать встроенные пользовательские потоки. Ознакомьтесь со статьей Начало работы с настраиваемыми политиками в Azure Active Directory B2C, чтобы узнать о базовом пакете настраиваемых политик, если еще не сделали этого.

Управление доступом для несовершеннолетних

Разработчики приложений и организации могут ограничивать доступ несовершеннолетних пользователей к определенным приложениям и службам, которые не предназначены для такой аудитории. Также можно разрешить доступ несовершеннолетним с последующим получением родительского согласия и предоставлять им допустимые возможности с учетом бизнес-правил и действующих регламентов.

Если пользователь определяется как несовершеннолетний, для потока пользователя в Azure AD B2C можно задать один из трех вариантов действий:

  • Send a signed JWT id_token back to the application (Отправлять подписанный идентификатор маркера JWT обратно в приложение). Пользователь регистрируется в каталоге, а маркер возвращается в приложение. Приложение самостоятельно выбирает варианты действий, применяя бизнес-правила. Например, приложение может перейти к процессу получения родительского согласия. Чтобы использовать этот метод, выберите получение утверждений ageGroup и consentProvidedForMinor из приложения.

  • Send an unsigned JSON token to the application (Отправить приложению неподписанный маркер JSON). Azure AD B2C уведомит приложение, что пользователь является несовершеннолетним, и предоставит сведения о состоянии родительского согласия для этого пользователя. Приложение самостоятельно выбирает варианты действий, применяя бизнес-правила. Маркер JSON не позволяет приложению успешно завершить аутентификацию. Приложение должно выполнить для такого пользователя некоторые действия с использованием утверждений, включенных в маркер JSON, который может содержать имя, адрес электронной почты, свойства ageGroup и consentProvidedForMinor.

  • Block the user (Заблокировать пользователя). Если пользователь является несовершеннолетним и родительское согласие не предоставлено, Azure AD B2C может уведомить пользователя о том, что он заблокирован. Маркер при этом не выдается и доступ не предоставляется, а если выполнялся процесс регистрации — учетная запись пользователя не создается. Для реализации этого варианта уведомления создайте страницы содержимого HTML и CSS с информацией для пользователя и описанием доступных вариантов действий. Для новых регистраций приложению не нужно выполнять дополнительные действия.

В зависимости от действующих требований к приложению для некоторых действий требуется родительское согласие от взрослого пользователя, возраст которого подтвержден. Azure AD B2C не предоставляет возможность проверять возраст человека, чтобы потом предоставить родительское согласие для несовершеннолетнего. Такая возможность должна быть реализована самим приложением или сторонним поставщиком услуг.

Ниже приведен пример потока пользователя для получения родительского согласия.

  1. Операция в API Microsoft Graph определяет, что пользователь является несовершеннолетним, и возвращает приложению данные этого пользователя в виде неподписанного токена JSON.

  2. Приложение обрабатывает полученный токен JSON и отображает несовершеннолетнему пользователю сообщение о том, что для некоторых действий требуется родительское согласие, а также предлагает возможность предоставить такое согласие через Интернет.

  3. Azure AD B2C отображает интерфейс для входа в систему, с помощью которого пользователь может выполнить обычный вход, и издает токен для приложения, где должно быть следующее: legalAgeGroupClassification = "minorWithParentalConsent" . Приложение собирает адрес электронной почты родителя и проверяет, что тот является взрослым. Для этого используется надежный источник, например национальный или региональный офис идентификации, проверка лицензии или подтверждение кредитной карта. Если проверка выполнена успешно, приложение предложит несовершеннолетнему пользователю выполнить вход, используя интерфейс Azure AD B2C. Если разрешение отклонено (например, если legalAgeGroupClassification = "minorWithoutParentalConsent" ), Azure AD B2C вернет приложению токен JSON (не дающий права на вход), чтобы снова повторить процесс получения согласия. Вы также можете настроить поток пользователя, позволяющий взрослому или самому несовершеннолетнему получить доступ к учетной записи несовершеннолетнего, например отправляя код регистрации на сохраненный адрес электронной почты несовершеннолетнего или взрослого.

  4. Приложение позволяет несовершеннолетнему пользователю отозвать согласие.

  5. Если несовершеннолетний или взрослый отменяет согласие, можно использовать API Microsoft Graph, чтобы изменить значение параметра consetProvidedForMinor на denied. Кроме того, приложение может удалить учетную запись несовершеннолетнего при отзыве разрешения. Вы также можете настроить поток пользователя так, чтобы прошедший аутентификацию несовершеннолетний (или его родитель, войдя с учетной записью несовершеннолетнего) мог отозвать согласие. Azure AD B2C сохраняет для параметра consentProvidedForMinor значение denied.

Дополнительные сведения об утверждениях legalAgeGroupClassification, consentProvidedForMinor и ageGroup см. в разделе User resource type (Типы ресурсов пользователя). Дополнительные сведения о пользовательских атрибутах см. в статье Azure Active Directory B2C: использование настраиваемых атрибутов для сбора данных о потребителях. При обращении к дополнительным атрибутам с помощью API Microsoft Graph необходимо использовать полную версию атрибута, например extension_18b70cf9bb834edd8f38521c2583cd86_dateOfBirth: 2011-01-01T00:00:00Z.

Сбор сведений о дате рождения и стране или регионе пребывания

Во время регистрации приложения могут делегировать Azure AD B2C сбор информации о дате рождения и стране или регионе пребывания всех пользователей. Если эта информация отсутствует, приложение может запросить у пользователя ввести ее во время следующей проверки подлинности (входа). Пользователи не смогут продолжить работу, не предоставив сведения о дате рождения и стране или регионе пребывания. Azure AD B2C использует эти сведения для определения того, считается ли такое лицо несовершеннолетним по законам соответствующих страны или региона.

Можно настроить собственный поток пользователя для сбора данных о дате рождения и стране или регионе пребывания, а затем с помощью преобразования утверждений Azure AD B2C установить соответствующее значение параметра ageGroup и сохранить этот результат в каталоге (либо напрямую сохранить сведения о дате рождения и стране или регионе пребывания).

Ниже описывается логика расчета значения для параметра ageGroup на основе даты рождения пользователя.

  1. Попробуйте найти страну или регион по коду страны или региона в списке. Если страна или регион не найдены, используйте значение Default.

  2. Если для выбранных страны или региона есть узел MinorConsent, сделайте следующее:

    а. Вычислите дату, когда пользователь должен был родиться, чтобы считаться взрослым. Например, если текущая дата — 14 марта 2015 года, а MinorConsent — 18, дата рождения должна быть не позднее 14 марта 2000 года.

    b. Сравните минимальную дату рождения с фактически указанной датой рождения. Если минимальная дата рождения наступает раньше даты рождения пользователя, результатом вычисления считается значение возрастной группы Minor.

  3. Если для страны или региона есть узел MinorNoConsentRequired, повторите шаги 2а и 2б для значения параметра MinorNoConsentRequired. Результатом вычислений на шаге 2б будет считаться значение MinorNoConsentRequired, если минимальная дата рождения наступает до даты рождения пользователя.

  4. Если ни одно из описанных вычислений не возвращает значение true, результатом считается возрастная группа Adult.

Если приложение собирает сведения о дате рождения и стране или регионе пребывания другим способом, оно может использовать API Graph для обновления соответствующих данных в учетной записи пользователя. Пример:

  • Если пользователь достоверно считается взрослым, сохраните для атрибута каталога ageGroup значение Adult.
  • Если пользователь достоверно считается несовершеннолетним, сохраните для атрибута каталога ageGroup значение Minor или consentProvidedForMinor с учетом всех данных.

Правила определения совершеннолетия

При проверке возраста пользователя, пытающегося получить доступ, используются два значения: возраст до наступления совершеннолетия и возраст, для которого требуется согласие родителей. В таблице ниже перечислены правила расчета возраста, которые используются для выявления несовершеннолетних и несовершеннолетних, которым требуется родительское согласие.

Страна или регион Название региона или страны Возраст доступа с согласия Возраст до наступления совершеннолетия
По умолчанию None Нет 18
AE ОАЭ Нет 21
AT Австрия 14 18
BE Бельгия 14 18
BG Болгария 16 18
BH Бахрейн Нет 21
CM Камерун Нет 21
CY Кипр 16 18
CZ Чешская Республика 16 18
DE Германия 16 18
DK Дания 16 18
EE Эстония 16 18
EG Египет Нет 21
ES Испания 13 18
СВ Франция 16 18
ГБ United Kingdom 13 18
GR Греция 16 18
HR Хорватия 16 18
HU Венгрия 16 18
IE Ирландия 13 18
IT Италия 16 18
KR Республика Корея 14 18
LT Литва 16 18
LU Люксембург 16 18
LV Латвия 16 18
MT Мальта 16 18
Н/Д Намибия Нет 21
NL Нидерланды 16 18
PL Польша 13 18
PT Португалия 16 18
RO Румыния 16 18
SE Швеция 13 18
SG Сингапур Нет 21
SI Словения 16 18
SK Словакия 16 18
TD Чад Нет 21
ВП Таиланд Нет 20
TW Тайвань Нет 20
США США 13 18

Сбор согласия с условиями использования

Обычно приложения разрабатываются так, что согласие пользователей с условиями использования подтверждается в самом приложении, без участия или с минимальным участием каталога пользователей. Но у вас есть возможность использовать поток пользователя в Azure AD B2C для сбора данных о согласии пользователей с условиями использования, ограничения доступа при отсутствии такого согласия и запроса на подтверждение согласия при любом изменении условий использования с учетом даты последнего подтверждения и даты публикации последней версии условий использования.

Условия использования также могут включать согласие на передачу данных третьим лицам. В зависимости от локальных правил и бизнес-правил можно собирать согласие пользователей с обоими условиями в сочетании или можно разрешить пользователю принимать одно условие, а не другое.

Следующие шаги описывают, как можно управлять условиями использования.

  1. Сохраните согласие с условиями использования и дату подтверждения, используя API Graph и расширенные атрибуты. Это можно сделать, используя встроенные пользовательские потоки или настраиваемые политики. Рекомендуется создать и использовать атрибуты extension_termsOfUseConsentDateTime и extension_termsOfUseConsentVersion.

  2. Создайте обязательный флажок с надписью "Принять условия использования" и запишите значение, полученное во время регистрации пользователя. Это можно сделать, используя встроенные пользовательские потоки или настраиваемые политики.

  3. Azure AD B2C хранит соглашение условий использования и согласие пользователя. Можно использовать API Graph для запроса состояния подтверждения для любого пользователя, считывая значение соответствующего расширенного атрибута, который используется для записи ответа (например, termsOfUseTestUpdateDateTime). Это можно сделать, используя встроенные пользовательские потоки или настраиваемые политики.

  4. Чтобы затребовать согласие с обновленными условиями использования, сравните дату подтверждения с датой публикации последней версии условий использования. Даты можно сравнивать только с помощью потока пользователя. Используйте расширенный атрибут extension_termsOfUseConsentDateTime и сравните значение с утверждением termsOfUseTextUpdateDateTime. Если согласие устарело, принудительно введите новое подтверждение, отображая самонастраиваемое окно. В противном случае заблокируйте доступ с помощью логики политики.

  5. Чтобы потребовать согласие с обновленными условиями использования, сравните номер версии в сохраненном согласии с самым последним принятым номером версии. Вы можете сравнивать номера версий только с помощью настраиваемого потока пользователя. Используйте расширенный атрибут extension_termsOfUseConsentDateTime и сравните значение с утверждением extension_termsOfUseConsentVersion. Если согласие устарело, принудительно введите новое подтверждение, отображая самонастраиваемое окно. В противном случае заблокируйте доступ с помощью логики политики.

Вы можете зафиксировать условия использования согласия в следующих сценариях.

  • Регистрация нового пользователя. Отображаются условия использования и сохраняется результат согласия.
  • В систему входит пользователь, который ранее подтвердил согласие с актуальными или активными условиями использования. Условия использования не отображаются.
  • В систему входит пользователь, который еще не подтвердил согласие с актуальными или активными условиями соглашения. Отображаются условия использования и сохраняется результат согласия.
  • В систему входит пользователь, который уже подтвердил согласие с более старой версией условий использования, которые теперь обновляются до последней версии. Отображаются условия использования и сохраняется результат согласия.

На следующем изображении представлена рекомендованный поток пользователя:

Блок-схема с рекомендуемым потоком подтверждения согласия

В следующем примере реализуется логика согласия с условиями использования, основанная на утверждении и проверке даты и времени. Если утверждение extension_termsOfUseConsentDateTime старше 2025-01-15T00:00:00, задайте принудительное новое принятие, отметив логическое утверждение termsOfUseConsentRequired и отобразив экран с автоматическим подтверждением.

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

В следующем примере реализуется логика согласия с условиями использования, основанная на утверждении и проверке версии условий. Если утверждение extension_termsOfUseConsentVersion не равно V1, задайте принудительное новое принятие, отметив логическое утверждение termsOfUseConsentRequired и отобразив экран с автоматическим подтверждением.

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

Дальнейшие действия