Поделиться через


Руководство по настройке IDEMIA Mobile ID с помощью Azure Active Directory B2C

Это важно

Начиная с 1 мая 2025 г. Azure AD B2C больше не будет доступен для приобретения для новых клиентов. Дополнительные сведения см. в разделе "Вопросы и ответы".

Перед тем как начать

Azure Active Directory B2C (Azure AD B2C) имеет два метода для определения взаимодействия пользователей с приложениями: предопределенных потоков пользователей или настраиваемых политик. Общие сведения о потоках пользователей и пользовательских политиках

Интеграция Azure AD B2C с IDEMIA Mobile ID

IDEMIA предоставляет биометрические службы проверки подлинности, такие как идентификатор лица и отпечатки пальцев, что снижает использование мошенничества и повторного использования учетных данных. С мобильным идентификатором граждане получают преимущества доверенного, выданного правительством цифрового идентификатора, в дополнение к их физическому идентификатору. Мобильный идентификатор проверяет личность с помощью самостоятельно выбранного ПИН-кода, отпечатка пальца или идентификатора лица. Граждане управляют своими личностями, разделяя информацию, необходимую для транзакции. Многие государственные отделы транспортных средств (DMV) используют мобильный идентификатор.

Дополнительные сведения см. в idemia.com: IDEMIA

Описание сценария

Интеграция с мобильным идентификатором включает следующие компоненты:

  • Azure AD B2C — сервер авторизации, проверяющий учетные данные пользователя
    • Он также называется поставщиком удостоверений (IdP)
  • IdEMIA Mobile ID — поставщик OpenID Connect (OIDC), настроенный как внешний поставщик Azure AD B2C
  • Приложение IDEMIA Mobile ID — цифровая версия лицензии водителя или идентификатора, выданного государством, в приложении на телефоне

Мобильный идентификатор — это цифровой идентификационный документ, переносимый мобильный идентификатор, используемый DMV для проверки индивидуальных личностей. Подписанный цифровой идентификатор хранится на мобильных телефонах пользователя в качестве удостоверения в пределах сети. Подписанные учетные данные упрощают доступ к службам идентификации, таким как подтверждение возраста, проверка финансовой благонадежности клиента, доступ к учетной записи и т. д.

На следующей схеме показаны потоки пользователей регистрации и входа с помощью Мобильного идентификатора.

Схема потоков пользователей регистрации и входа с помощью Mobile ID.

  1. Пользователь посещает страницу входа Azure AD B2C (отвечающую сторону) с устройством и мобильным идентификатором для проведения транзакции.
  2. Azure AD B2C выполняет проверку идентификатора. Он перенаправляет пользователя на маршрутизатор IDEMIA с потоком кода авторизации OIDC.
  3. Маршрутизатор отправляет биометрический вызов мобильному приложению пользователя с сведениями о проверке подлинности и авторизации.
  4. В зависимости от безопасности пользователю может быть предложено предоставить дополнительные сведения: введите ПИН-код, выполните динамическое селфи или оба.
  5. Ответ проверки подлинности предоставляет подтверждение владения, присутствия и согласия. Ответ возвращается маршрутизатору.
  6. Маршрутизатор проверяет сведения о пользователе и передает результат в Azure AD B2C.
  7. Пользователю предоставлен или запрещен доступ.

Включение мобильного идентификатора

Чтобы приступить к работе, перейдите на страницу idemia.com Связаться с нами, чтобы запросить демонстрацию. В текстовом поле формы запроса укажите интерес к интеграции Azure AD B2C.

Интеграция мобильного идентификатора с Azure AD B2C

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

Предпосылки

Чтобы начать, вам нужно:

  • Доступ для пользователей с государственными мобильными идентификаторами (mID), выданными компанией IDEMIA и властями штатов США.

    • Или на этапе тестирования демонстрационное приложение mID из IDEMIA
  • подписка Azure

  • Клиент Azure AD B2C, связанный с подпиской Azure

  • Бизнес-веб-приложение, зарегистрированное в клиенте Azure AD B2C

    • Для тестирования настройте https://jwt.ms, это веб-приложение Microsoft с декодированными данными токена.

    Замечание

    Содержимое токена не покидает браузер.

Отправка заявки доверяющей стороны для mID

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

Недвижимость Описание
Имя приложения Azure AD B2C или другое имя приложения
Идентификатор_клиента Уникальный идентификатор поставщика удостоверений (IdP)
Секрет клиента Пароль приложения доверяющей стороны используется для аутентификации с помощью IDEMIA IdP
Конечная точка метаданных URL, указывающий на документ конфигурации издателя токенов, также называемый конечной точкой конфигурации OpenID
URI перенаправления https://your-B2C-tenant-name.b2clogin.com/your-B2C-tenant-name.onmicrosoft.com/oauth2/authresp
Например: https://fabrikam.b2clogin.com/fabrikam.onmicrosoft.com/oauth2/authresp

Если вы используете личный домен, введите https://your-domain-name/your-tenant-name.onmicrosoft.com/oauth2/authresp.
URI перенаправления после выхода из системы https://your-B2C-tenant-name.b2clogin.com/your-B2C-tenant-name.onmicrosoft.com/{policy}/oauth2/v2.0/logout
Отправьте запрос на выход.

Замечание

Чтобы настроить поставщика удостоверений в Azure AD B2C, вам понадобятся ID клиента и секрет клиента.

Создание ключа политики

Сохраните отмеченный секрет клиента IDEMIA в клиенте Azure AD B2C. Для выполнения следующих инструкций используйте каталог с клиентом Azure AD B2C.

  1. Войдите на портал Azure.
  2. На панели инструментов портала выберите каталоги и подписки.
  3. На странице "Параметры портала" "Каталоги и подписки " в списке имен каталогов найдите каталог Azure AD B2C
  4. Выберите Переключиться.
  5. В левом верхнем углу портала Azure выберите все службы.
  6. Найдите и выберите Azure AD B2C.
  7. На странице "Обзор" выберите Identity Experience Framework.
  8. Выберите Ключи политики.
  9. Нажмите кнопку "Добавить".
  10. В разделе "Параметры" выберите "Вручную".
  11. Введите имя для ключа политики. Например: IdemiaAppSecret. Префикс B2C_1A_ добавляется в имя ключа.
  12. В секрет введите секрет клиента, который вы указали.
  13. Для использования ключа выберите "Подпись".
  14. Нажмите кнопку "Создать".

Настройка Мобильного ID в качестве внешнего поставщика идентификационных данных

Чтобы пользователи могли войти в систему с помощью мобильного идентификатора, определите IDEMIA в качестве поставщика утверждений. Это действие гарантирует взаимодействие Azure AD B2C через конечную точку, которая предоставляет утверждения Azure AD B2C для проверки проверки подлинности пользователей с помощью биометрии.

Чтобы определить IDEMIA в качестве поставщика утверждений, добавьте его в элемент ClaimsProvider в файле расширения политики.

     <TechnicalProfile Id="Idemia-Oauth2">
          <DisplayName>IDEMIA</DisplayName>
          <Description>Login with your IDEMIA identity</Description>
          <Protocol Name="OAuth2" />
          <Metadata>
            <Item Key="METADATA">https://idp.XXXX.net/oxauth/.well-known/openid-configuration</Item>
            <!-- Update the Client ID below to the Application ID -->
            <Item Key="client_id">00001111-aaaa-2222-bbbb-3333cccc4444</Item>
            <Item Key="response_types">code</Item>
            <Item Key="scope">openid id_basic mt_scope</Item>
            <Item Key="response_mode">form_post</Item>
            <Item Key="HttpBinding">POST</Item>
            <Item Key="UsePolicyInRedirectUri">false</Item>
            <Item Key="token_endpoint_auth_method">client_secret_basic</Item>
            <Item Key="ClaimsEndpoint">https://idp.XXXX.net/oxauth/restv1/userinfo</Item>
            <Item Key="ValidTokenIssuerPrefixes">https://login.microsoftonline.com/</Item>
          </Metadata>
          <CryptographicKeys>
            <Key Id="client_secret" StorageReferenceId="B2C_1A_IdemiaAppSecret" />
</CryptographicKeys>
          <InputClaims>
            <InputClaim ClaimTypeReferenceId="acr" PartnerClaimType="acr_values" DefaultValue="loa-2" />
          </InputClaims>
          <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="sub" />
            <OutputClaim ClaimTypeReferenceId="tenantId" PartnerClaimType="tid" />
            <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="firstName1" />
            <OutputClaim ClaimTypeReferenceId="surName" PartnerClaimType="lastName1" />
            <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication" AlwaysUseDefaultValue="true" />
            <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="idemia" />
            <OutputClaim ClaimTypeReferenceId="documentId" />
            <OutputClaim ClaimTypeReferenceId="address1" />
          </OutputClaims>
          <OutputClaimsTransformations>
            <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName" />
            <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName" />
            <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId" />
            <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId" />
          </OutputClaimsTransformations>
          <UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin" />
        </TechnicalProfile>
           

Установите client_id как идентификатор приложения из регистрации приложения.

Недвижимость Описание
Область действия Для OpenID Connect (OIDC) минимальным требованием является установка параметра области openid. Добавьте дополнительные области в виде списка, разделенного пробелами.
redirect_uri (URI перенаправления) В этом расположении агент пользователя отправляет код авторизации в Azure AD B2C.
тип_ответа Для потока кода авторизации выберите код
acr_values Этот параметр управляет методами проверки подлинности, которые пользователь должен выполнять во время проверки подлинности.

Выберите одно из следующих значений:

Значение параметра Влияние на процесс проверки подлинности пользователей
loa-2 Только многофакторная аутентификация Microsoft Entra на основе криптографии.
loa-3 MFA на основе шифрования, а также еще один фактор
loa-4 MFA на основе криптографии, плюс пользователь выполняет аутентификацию с помощью ПИН-кода и биометрии.

Конечная точка /userinfo предоставляет утверждения для областей, запрошенных в запросе авторизации. <Для mt_scope> есть утверждения, такие как имя, фамилия и номер лицензии водителя, среди других элементов. Утверждения, заданные для области, публикуются в разделе scope_to_claims_mapping API обнаружения. Azure AD B2C запрашивает утверждения с узла утверждений и возвращает их в элементе «OutputClaims». Возможно, вам потребуется сопоставить имя утверждения в политике с именем в поставщике идентификаций. Определите тип утверждения в элементе ClaimSchema:

<ClaimType Id="documentId">
     <DisplayName>documentId</DisplayName>
     <DataType>string</DataType>
</ClaimType>
<ClaimType Id="address1">
     <DisplayName>address</DisplayName>
     <DataType>string</DataType>
</ClaimType>

Добавить пользовательский сценарий

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

  1. В начальном пакете откройте TrustFrameworkBase.xml файл.
  2. Найдите и скопируйте содержимое UserJourneys элемента, включающее ID=SignUpOrSignIn.
  3. Откройте TrustFrameworkExtensions.xml.
  4. Найдите элемент UserJourneys . Если нет элемента, добавьте его.
  5. Вставьте содержимое элемента UserJourney в качестве дочернего элемента UserJourneys.
  6. Переименуйте идентификатор пути пользователя. Например: ID=CustomSignUpSignIn.

Добавление поставщика удостоверений в пользовательский сценарий

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

  1. В пути взаимодействия пользователя найдите элемент шага оркестрации с типом=CombinedSignInAndSignUpили Type=ClaimsProviderSelection. Обычно это первый шаг оркестрации. Элемент ClaimsProviderSelections содержит список поставщиков удостоверений, с помощью которых пользователи могут войти в систему. Порядок элементов управления — это порядок кнопок входа, которые видит пользователь.
  2. Добавьте XML-элемент ClaimsProviderSelection .
  3. Задайте для значения TargetClaimsExchangeId понятное имя.
  4. Добавьте элемент ClaimsExchange .
  5. Установите идентификатор в значение целевого идентификатора обмена заявками.
  6. Обновите значение TechnicalProfileReferenceId на идентификатор технического профиля, который вы создали.

Следующий XML-код демонстрирует первые два шага оркестрации пользовательского маршрута с поставщиком удостоверений личности.

<OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
  <ClaimsProviderSelections>
    ...
    <ClaimsProviderSelection TargetClaimsExchangeId="IdemiaExchange" />
  </ClaimsProviderSelections>
  ...
</OrchestrationStep>

<OrchestrationStep Order="2" Type="ClaimsExchange">
  ...
  <ClaimsExchanges>
    <ClaimsExchange Id="IdemiaExchange" TechnicalProfileReferenceId="Idemia-Oauth2" />
  </ClaimsExchanges>
</OrchestrationStep>

Настройте политику доверяющей стороны

Политика доверяющей стороны, например SignUpSignIn.xml, указывает путь пользователя, который выполняет Azure AD B2C.

  1. Найдите элемент DefaultUserJourney в проверяющей стороне.
  2. Обновите referenceId , чтобы он соответствовал идентификатору пути пользователя, в котором вы добавили идентификатор поставщика удостоверений.

В следующем примере для CustomSignUpOrSignIn пути пользователя для параметра ReferenceId задано CustomSignUpOrSignInзначение .

<RelyingParty>
  <DefaultUserJourney ReferenceId="CustomSignUpSignIn" />
  ...
</RelyingParty>

Отправка настраиваемой политики

Для выполнения следующих инструкций используйте каталог с клиентом Azure AD B2C.

  1. Войдите на портал Azure.

  2. На панели инструментов портала выберите каталоги и подписки.

  3. На странице "Параметры портала" "Каталоги и подписки " в списке имен каталога найдите каталог Azure AD B2C.

  4. Выберите Переключиться.

  5. В портале Azure найдите и выберите Azure AD B2C.

  6. В разделе "Политики" выберите Identity Experience Framework.

  7. Выберите "Отправить настраиваемую политику".

  8. Отправьте два измененных файла политики в следующем порядке:

    • Политика расширения, например TrustFrameworkExtensions.xml
    • Политика проверяющей стороны, например SignUpSignIn.xml

Проверка настраиваемой политики

  1. Выберите политику доверенной стороны, например B2C_1A_signup_signin.
  2. Для приложения выберите зарегистрированное веб-приложение.
  3. https://jwt.msотображается для URL-адреса ответа.
  4. Выберите Запустить немедленно.
  5. На странице регистрации или входа выберите IDEMIA.
  6. Браузер перенаправляется в https://jwt.ms. См. содержимое токена, возвращаемое Azure AD B2C.

Дополнительные сведения. Руководство. Регистрация веб-приложения в Azure AD B2C

Дальнейшие шаги