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

Безопасные API, используемые для соединителей API в Azure AD B2C

  • Статья

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

Необходимые компоненты

Выполните действия, описанные в руководстве по добавлению соединителя API для регистрации пользователя .

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

Обычная аутентификация через HTTP

Обычная аутентификация через HTTP определяется стандартом RFC 2617. Обычная аутентификация работает следующим образом:

  • Azure AD B2C отправляет HTTP-запрос с учетными данными клиента (username и password) в заголовке Authorization.

  • Учетные данные имеют формат строки username:password в кодировке Base64.

  • Затем ваш API проверяет эти значения для выполнения других решений об авторизации.

Чтобы настроить соединитель API с обычной проверкой подлинности HTTP, выполните следующие действия.

  1. Войдите на портал Azure.
  2. В разделе Службы Azureвыберите Azure AD B2C или найдите Azure AD B2C.
  3. Щелкните Соединители API, а затем выберите соединитель API, который нужно настроить.
  4. Для параметра Тип проверки подлинности выберите значение Обычная.
  5. Укажите имя пользователя и пароль для конечной точки REST API. Providing basic authentication configuration for an API connector.
  6. Выберите Сохранить.

Добавление ключей политики для имени пользователя и пароля REST API

Чтобы настроить в техническом профиле REST API обычную аутентификацию через HTTP, создайте следующие криптографические ключи для хранения имени пользователя и пароля:

  1. Войдите на портал Azure.
  2. Если у вас есть доступ к нескольким клиентам, выберите значок Параметры в верхнем меню, чтобы переключиться на клиент Azure AD B2C из меню каталогов и подписок.
  3. Выберите Все службы в левом верхнем углу окна портала Azure, а затем найдите и выберите Azure AD B2C.
  4. На странице "Обзор" выберите Identity Experience Framework.
  5. Выберите Ключи политики, а затем щелкните Добавить.
  6. В пункте Параметры выберите Manual (Вручную).
  7. В поле Имя введите RestApiUsername. Префикс B2C_1A_ может быть добавлен автоматически.
  8. В поле Секрет введите имя пользователя REST API.
  9. Для параметра Использование ключа задайте значение Шифрование.
  10. Нажмите кнопку создания.
  11. Снова щелкните Ключи политики.
  12. Выберите Добавить.
  13. В пункте Параметры выберите Manual (Вручную).
  14. В поле Имя введите RestApiPassword. Префикс B2C_1A_ может быть добавлен автоматически.
  15. В поле Секрет введите пароль REST API.
  16. Для параметра Использование ключа задайте значение Шифрование.
  17. Нажмите кнопку создания.

Настройка обычной аутентификации через HTTP в техническом профиле REST API

После создания необходимых ключей настройте метаданные технического профиля REST API, чтобы они ссылались на эти учетные данные.

  1. В рабочей папке откройте файл политики расширения (TrustFrameworkExtensions.xml).
  2. Выполните поиск технического профиля REST API, например REST-ValidateProfile или REST-GetProfile.
  3. Найдите элемент <Metadata>.
  4. Установите для параметра AuthenticationType значение Basic.
  5. Установите для параметра AllowInsecureAuthInProduction значение false.
  6. Сразу после закрытия </Metadata> элемента добавьте следующий фрагмент XML: 
    <CryptographicKeys>
    <Key Id="BasicAuthenticationUsername" StorageReferenceId="B2C_1A_RestApiUsername" />
    <Key Id="BasicAuthenticationPassword" StorageReferenceId="B2C_1A_RestApiPassword" />
</CryptographicKeys>

Ниже приведен пример, написанный на языке XML, технического профиля RESTful,в котором настроена обычная аутентификация через HTTP.

<ClaimsProvider>
  <DisplayName>REST APIs</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="REST-GetProfile">
      <DisplayName>Get user extended profile Azure Function web hook</DisplayName>
      <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
      <Metadata>
        <Item Key="ServiceUrl">https://your-account.azurewebsites.net/api/GetProfile?code=your-code</Item>
        <Item Key="SendClaimsIn">Body</Item>
        <Item Key="AuthenticationType">Basic</Item>
        <Item Key="AllowInsecureAuthInProduction">false</Item>
      </Metadata>
      <CryptographicKeys>
        <Key Id="BasicAuthenticationUsername" StorageReferenceId="B2C_1A_RestApiUsername" />
        <Key Id="BasicAuthenticationPassword" StorageReferenceId="B2C_1A_RestApiPassword" />
      </CryptographicKeys>
      ...
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

Аутентификация через HTTPS на основе сертификата клиента

Аутентификация на основе сертификата клиента выполняется взаимно, и в ее ходе служба Azure AD B2C, выполняющая роль клиента, предоставляет серверу сертификат клиента для подтверждения личности. Это происходит в процессе приветствия SSL. Ваш API отвечает за проверку сертификатов, принадлежащих допустимому клиенту, например Azure AD B2C, и за принятие решений об авторизации. Сертификат клиента — это цифровой сертификат X.509.

Важно!

В рабочих средах сертификат должен быть подписан центром сертификации.

Создание сертификата

Чтобы создать сертификат, можно использовать хранилище Azure Key Vault, которое поддерживает функции самозаверяющих сертификатов и интеграцию с поставщиками издателей сертификатов для использования подписанных сертификатов. Рекомендуется использовать следующие параметры.

  • Тема: CN=<yourapiname>.<tenantname>.onmicrosoft.com
  • Тип содержимого: PKCS #12
  • Тип действия по времени существования: Email all contacts at a given percentage lifetime или Email all contacts a given number of days before expiry
  • Тип ключа: RSA
  • Размер ключа: 2048
  • Экспортируемый закрытый ключ: Yes (чтобы иметь возможность экспортировать файл в формате .pfx)

Затем можно экспортировать сертификат.

Вариант 2. Подготовка самозаверяющего сертификата с помощью модуля PowerShell

Если у вас еще нет сертификата, можно использовать самозаверяющий сертификат. Самозаверяющий сертификат — это сертификат безопасности, не подписанный центром сертификации (ЦС) и не предоставляющий гарантий безопасности сертификата, подписанного центром сертификации.

В Windows для создания сертификата используется командлет PowerShell New-SelfSignedCertificate.

  1. Выполните следующую команду PowerShell, чтобы создать самозаверяющий сертификат. Измените аргумент -Subject, указав реальные значения приложения и имени арендатора Azure  AD B2C, например contosowebapp.contoso.onmicrosoft.com. Можно также скорректировать дату -NotAfter, чтобы указать другой срок действия сертификата.

    New-SelfSignedCertificate `
    -KeyExportPolicy Exportable `
    -Subject "CN=yourappname.yourtenant.onmicrosoft.com" `
    -KeyAlgorithm RSA `
    -KeyLength 2048 `
    -KeyUsage DigitalSignature `
    -NotAfter (Get-Date).AddMonths(12) `
    -CertStoreLocation "Cert:\CurrentUser\My"

  2. На компьютере Windows найдите элемент Управление сертификатами пользователей и выберите его.

  3. В области Сертификаты — текущий пользователь выберите Личное>Сертификаты>имя_приложения.имя_арендатора.onmicrosoft.com.

  4. Выберите сертификат, а затем выберите Действие > Все задачи > Экспортировать.

  5. Нажмите Далее>Да, экспортировать закрытый ключ>Далее.

  6. Примите значения по умолчанию для параметра Формат экспортируемого файла и нажмите кнопку Далее.

  7. Включите параметр Пароль, введите пароль для сертификата, а затем нажмите кнопку Далее.

  8. Чтобы указать расположение для сохранения сертификата, нажмите кнопку Обзор и перейдите в нужный каталог.

  9. В окне Сохранить как введите значение в поле Имя файла и нажмите кнопку Сохранить.

  10. Выберите Далее>Готово.

Чтобы служба Azure AD B2C принимала пароль файла с расширением PFX, пароль необходимо зашифровать с помощью TripleDES-SHA1 в служебной программе экспорта хранилища сертификатов Windows, а не с помощью AES256-SHA256.

Настройка соединителя API

Чтобы настроить соединитель API с проверкой подлинности с помощью сертификата клиента, выполните следующие действия.

  1. Войдите на портал Azure.
  2. В разделе Службы Azure выберите Azure AD B2C.
  3. Щелкните Соединители API, а затем выберите соединитель API, который нужно настроить.
  4. Для параметра Тип проверки подлинности выберите значение Сертификат.
  5. В поле Загрузить сертификат выберите PFX-файл сертификата с закрытым ключом.
  6. В поле Введите пароль введите пароль сертификата. Providing certificate authentication configuration for an API connector.
  7. Выберите Сохранить.

Выполнение решений об авторизации

Чтобы защитить конечные точки API, интерфейс API должен реализовывать авторизацию на основе отправленных клиентских сертификатов. Для Службы приложений Azure и Функций Azure см. сведения о том, как включить и проверить сертификат из кода API, в разделе Настройка взаимной проверки подлинности TLS. Вы также можете использовать Управление API Azure в качестве уровня перед любой службой API, чтобы проверить свойства сертификата клиента по нужным значениям.

Обновление сертификатов

Рекомендуется настроить предупреждения с напоминаниями о сроке истечения действия вашего сертификата. Необходимо создать новый сертификат и повторить описанные выше действия при истечении срока действия используемых сертификатов. Чтобы развернуть использование нового сертификата, служба API может продолжать принимать старые и новые сертификаты в течение ограниченного промежутка времени во время развертывания нового сертификата.

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

Providing a new certificate to an API connector when one already exists.

Добавление ключа политики для сертификата клиента

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

Настройка аутентификации с использованием сертификата клиента в техническом профиле REST API

После создания необходимых ключей настройте метаданные технического профиля REST API, чтобы они ссылались на сертификат клиента.

  1. В рабочей папке откройте файл политики расширения (TrustFrameworkExtensions.xml).
  2. Выполните поиск технического профиля REST API, например REST-ValidateProfile или REST-GetProfile.
  3. Найдите элемент <Metadata>.
  4. Установите для параметра AuthenticationType значение ClientCertificate.
  5. Установите для параметра AllowInsecureAuthInProduction значение false.
  6. Сразу после закрытия </Metadata> элемента добавьте следующий фрагмент XML: 
    <CryptographicKeys>
   <Key Id="ClientCertificate" StorageReferenceId="B2C_1A_RestApiClientCertificate" />
</CryptographicKeys>

Ниже приведен пример, написанный на языке XML, технического профиля RESTful,в котором настроена аутентификация с использованием сертификата клиента.

<ClaimsProvider>
  <DisplayName>REST APIs</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="REST-GetProfile">
      <DisplayName>Get user extended profile Azure Function web hook</DisplayName>
      <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
      <Metadata>
        <Item Key="ServiceUrl">https://your-account.azurewebsites.net/api/GetProfile?code=your-code</Item>
        <Item Key="SendClaimsIn">Body</Item>
        <Item Key="AuthenticationType">ClientCertificate</Item>
        <Item Key="AllowInsecureAuthInProduction">false</Item>
      </Metadata>
      <CryptographicKeys>
        <Key Id="ClientCertificate" StorageReferenceId="B2C_1A_RestApiClientCertificate" />
      </CryptographicKeys>
      ...
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

Аутентификация по носителю OAuth2

Проверка подлинности маркера носителя определена в платформе авторизации OAuth2.0: использование маркера носителя (RFC 6750). При использовании аутентификации по маркеру носителя OAuth2 служба Azure AD B2C отправляет HTTP-запрос с маркером в заголовке авторизации.

Authorization: Bearer <token>

Маркер носителя является непрозрачной строкой. Это может быть маркер доступа JWT или любая строка, которую REST API ожидает от Azure AD B2C в качестве заголовка авторизации. Azure AD B2C поддерживает следующие типы:

  • Маркер носителя. Чтобы иметь возможность отправить маркер носителя в технический профиль RESTful, политика должна сначала получить маркер носителя, а затем применить его в техническом профиле RESTful.
  • Статический маркер носителя. Используйте этот подход, если ваш REST API выдает долгосрочный маркер доступа. Чтобы использовать статический маркер носителя, создайте ключ политики и создайте ссылку на него в техническом профиле RESTful.

Использование носителя OAuth2

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

Определение утверждения для хранения маркера носителя

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

  1. Откройте файл расширения политики. Например, SocialAndLocalAccounts/TrustFrameworkExtensions.xml.
  2. Найдите элемент BuildingBlocks. Если такой элемент не существует, добавьте его.
  3. Найдите элемент ClaimsSchema. Если такой элемент не существует, добавьте его.
  4. Добавьте следующие утверждения в элемент ClaimsSchema.
<ClaimType Id="bearerToken">
  <DisplayName>Bearer token</DisplayName>
  <DataType>string</DataType>
</ClaimType>
<ClaimType Id="grant_type">
  <DisplayName>Grant type</DisplayName>
  <DataType>string</DataType>
</ClaimType>
<ClaimType Id="scope">
  <DisplayName>scope</DisplayName>
  <DataType>string</DataType>
</ClaimType>

Получение маркера доступа

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

Получение маркера доступа Microsoft Entra

В следующем примере используется технический профиль REST API для выполнения запроса к конечной точке маркера Microsoft Entra с использованием учетных данных клиента, переданных в качестве базовой проверки подлинности HTTP. Дополнительные сведения см. в статье Платформа удостоверений Майкрософт и поток учетных данных клиента OAuth 2.0.

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

  1. Войдите на портал Azure.
  2. Если у вас есть доступ к нескольким клиентам, выберите значок Параметры в верхнем меню, чтобы переключиться на клиент Azure AD B2C из меню каталогов и подписок.
  3. В меню слева выберите идентификатор Microsoft Entra. Или выберите все службы и найдите и выберите идентификатор Microsoft Entra.
  4. Щелкните Регистрация приложений и выберите Новая регистрация.
  5. Введите имя приложения. Например, Client_Credentials_Auth_app.
  6. В разделе Поддерживаемые типы учетных записей выберите Учетные записи только в этом каталоге организации.
  7. Выберите Регистр.
  8. Запишите идентификатор приложения (клиента).

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

  1. На странице Регистрация приложений идентификатора Microsoft Entra выберите созданное приложение, например Client_Credentials_Auth_app.
  2. В меню слева в разделе Управление выберите Сертификаты и секреты.
  3. Щелкните Создать секрет клиента.
  4. Введите описание секрета клиента в поле Описание. Например, clientsecret1.
  5. В разделе Истекает выберите срок действия секрета, а затем выберите Добавить.
  6. Запишите значение секрета, чтобы затем использовать его в коде клиентского приложения. Это значение секрета больше нигде не отображается после закрытия страницы. Это значение используется в качестве секрета приложения в коде приложения.

Создание ключей политики Azure Active Directory B2C

Вам необходимо сохранить значение секрета и идентификатора клиента, которые ранее были записаны в клиенте Azure AD B2C.

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

Для ServiceUrl замените имя клиента на имя клиента Microsoft Entra. Доступные варианты описаны в документации по техническому профилю RESTful.

<TechnicalProfile Id="REST-AcquireAccessToken">
  <DisplayName></DisplayName>
  <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
  <Metadata>
    <Item Key="ServiceUrl">https://login.microsoftonline.com/your-tenant-name.onmicrosoft.com/oauth2/v2.0/token</Item>
    <Item Key="AuthenticationType">Basic</Item>
     <Item Key="SendClaimsIn">Form</Item>
  </Metadata>
  <CryptographicKeys>
    <Key Id="BasicAuthenticationUsername" StorageReferenceId="B2C_1A_SecureRESTClientId" />
    <Key Id="BasicAuthenticationPassword" StorageReferenceId="B2C_1A_SecureRESTClientSecret" />
  </CryptographicKeys>
  <InputClaims>
    <InputClaim ClaimTypeReferenceId="grant_type" DefaultValue="client_credentials" AlwaysUseDefaultValue="true" />
    <InputClaim ClaimTypeReferenceId="scope" DefaultValue="https://graph.microsoft.com/.default" AlwaysUseDefaultValue="true" />
  </InputClaims>
  <OutputClaims>
    <OutputClaim ClaimTypeReferenceId="bearerToken" PartnerClaimType="access_token" />
  </OutputClaims>
  <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>

Примечание.

При использовании утверждений grant_type и scope в других технических профилях рекомендуется также указывать DefaultValue и использовать AlwaysUseDefaultValue="true", чтобы избежать потенциальных конфликтов при привязке к неверному значению.

Изменение технического профиля RESTful для использования аутентификации по маркеру носителя

Чтобы поддерживать проверку подлинности маркера носителя в пользовательской политике, измените технический профиль REST API, выполнив следующие действия.

  1. В рабочей папке откройте файл политики расширения TrustFrameworkExtensions.xml.

  2. Найдите узел <TechnicalProfile>, содержащий Id="REST-API-SignUp".

  3. Найдите элемент <Metadata>.

  4. Измените значение AuthenticationType на Bearer, как показано ниже.

    <Item Key="AuthenticationType">Bearer</Item>

  5. Для параметра UseClaimAsBearerToken укажите значение bearerToken, как показано ниже. BearerToken — это имя утверждения, из которого извлекается маркер носителя (выходное утверждение изREST-AcquireAccessToken).

    <Item Key="UseClaimAsBearerToken">bearerToken</Item>

  6. Добавьте утверждение из предыдущего шага в качестве входного утверждения:

    <InputClaim ClaimTypeReferenceId="bearerToken"/>

После обновления политики технический профиль должен выглядеть следующим XML-кодом:

<ClaimsProvider>
  <DisplayName>REST APIs</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="REST-GetProfile">
      <DisplayName>Get user extended profile Azure Function web hook</DisplayName>
      <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
      <Metadata>
        <Item Key="ServiceUrl">https://your-account.azurewebsites.net/api/GetProfile?code=your-code</Item>
        <Item Key="SendClaimsIn">Body</Item>
        <Item Key="AuthenticationType">Bearer</Item>
        <Item Key="UseClaimAsBearerToken">bearerToken</Item>
        <Item Key="AllowInsecureAuthInProduction">false</Item>
      </Metadata>
      <InputClaims>
        <InputClaim ClaimTypeReferenceId="bearerToken"/>
      </InputClaims>
      ...
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

Вызов технического профиля REST

Чтобы вызвать REST-GetProfile технический профиль, сначала необходимо получить маркер доступа Microsoft Entra с помощью технического REST-AcquireAccessToken профиля. В следующем примере показано, как вызвать технический профиль REST-GetProfile из технического профиля проверки:

<ValidationTechnicalProfiles>
  <ValidationTechnicalProfile ReferenceId="REST-AcquireAccessToken" />
  <ValidationTechnicalProfile ReferenceId="REST-GetProfile" />
</ValidationTechnicalProfiles>

В следующем примере показано, как вызвать технический профиль REST-GetProfile из пути взаимодействия пользователя или вложенного пути:

<OrchestrationSteps>
  <OrchestrationStep Order="2" Type="ClaimsExchange">
    <ClaimsExchanges>
      <ClaimsExchange Id="REST-AcquireAccessTokens" TechnicalProfileReferenceId="REST-AcquireAccessToken" />
    </ClaimsExchanges>
  </OrchestrationStep>

  <OrchestrationStep Order="3" Type="ClaimsExchange">
    <ClaimsExchanges>
      <ClaimsExchange Id="REST-GetProfile" TechnicalProfileReferenceId="REST-GetProfile" />
    </ClaimsExchanges>
  </OrchestrationStep>
</OrchestrationSteps>

Использование статического носителя OAuth2

Добавление ключа политики маркера носителя OAuth2

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

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

Настройка технического профиля REST API для использования ключа политики маркера носителя

После создания необходимых ключей настройте метаданные технического профиля REST API, чтобы они ссылались на маркер носителя.

  1. В рабочей папке откройте файл политики расширения (TrustFrameworkExtensions.xml).
  2. Выполните поиск технического профиля REST API, например REST-ValidateProfile или REST-GetProfile.
  3. Найдите элемент <Metadata>.
  4. Установите для параметра AuthenticationType значение Bearer.
  5. Установите для параметра AllowInsecureAuthInProduction значение false.
  6. Сразу после закрытия </Metadata> элемента добавьте следующий фрагмент XML: 
    <CryptographicKeys>
   <Key Id="BearerAuthenticationToken" StorageReferenceId="B2C_1A_RestApiBearerToken" />
</CryptographicKeys>

Ниже приведен пример, написанный на языке XML, технического профиля RESTful,в котором настроена аутентификация по маркеру носителя.

<ClaimsProvider>
  <DisplayName>REST APIs</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="REST-GetProfile">
      <DisplayName>Get user extended profile Azure Function web hook</DisplayName>
      <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
      <Metadata>
        <Item Key="ServiceUrl">https://your-account.azurewebsites.net/api/GetProfile?code=your-code</Item>
        <Item Key="SendClaimsIn">Body</Item>
        <Item Key="AuthenticationType">Bearer</Item>
        <Item Key="AllowInsecureAuthInProduction">false</Item>
      </Metadata>
      <CryptographicKeys>
        <Key Id="BearerAuthenticationToken" StorageReferenceId="B2C_1A_RestApiBearerToken" />
      </CryptographicKeys>
      ...
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

Добавьте ссылку на технический профиль проверки в технический профиль регистрации, который вызывает REST-AcquireAccessToken. Такое поведение означает, что Azure AD B2C переходит к созданию учетной записи в каталоге только после успешной проверки.

Например:

```XML
<ValidationTechnicalProfiles>
   ....
   <ValidationTechnicalProfile ReferenceId="REST-AcquireAccessToken" />
   ....
</ValidationTechnicalProfiles>

Проверка подлинности с использованием ключа API

Некоторые службы используют механизм "ключ API" для маскирования доступа к конечным точкам HTTP во время разработки, при этом требуется, чтобы вызывающий объект включал уникальный ключ в качестве HTTP-заголовка или параметра HTTP-запроса. Для Функций Azure это можно сделать, добавив code в качестве параметра запроса в URL-адрес конечной точки ваш соединитель API. Например, https://contoso.azurewebsites.net/api/endpoint?code=0123456789).

Это не такой механизм, который можно использовать по отдельности в рабочей среде. Поэтому всегда необходимо производить настройку для обычной аутентификации или аутентификации по сертификатам. Если вы не хотите реализовывать какой-либо способ проверки подлинности (что не рекомендуется) на этапе разработки, можно выбрать "обычную" проверку подлинности в конфигурации соединителя API и использовать временные значения параметров username и password, которые ваш API будет игнорировать, пока вы не реализуете соответствующую авторизацию в API.

Ключ API — это уникальный идентификатор, используемый для проверки подлинности пользователя при доступе к конечной точке REST API. Ключ отправляется в настраиваемом заголовке HTTP. Например, триггер HTTP для функций Azure использует заголовок HTTP x-functions-key для обнаружения запрашивающей стороны.

Добавление ключей политики ключей API

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

  1. Войдите на портал Azure.
  2. Если у вас есть доступ к нескольким клиентам, выберите значок Параметры в верхнем меню, чтобы переключиться на клиент Azure AD B2C из меню каталогов и подписок.
  3. Выберите Все службы в левом верхнем углу окна портала Azure, а затем найдите и выберите Azure AD B2C.
  4. На странице "Обзор" выберите Identity Experience Framework.
  5. Выберите Ключи политики, а затем щелкните Добавить.
  6. В пункте Параметры выберите Manual (Вручную).
  7. В поле Имя введите RestApiKey. Префикс B2C_1A_ может быть добавлен автоматически.
  8. В поле Секрет введите ключ REST API.
  9. Для параметра Использование ключа задайте значение Шифрование.
  10. Нажмите кнопку создания.

Настройка аутентификации с использованием ключа API в техническом профиле REST API

После создания необходимого ключа настройте метаданные технического профиля REST API, чтобы они ссылались на эти учетные данные.

  1. В рабочей папке откройте файл политики расширения (TrustFrameworkExtensions.xml).
  2. Выполните поиск технического профиля REST API, например REST-ValidateProfile или REST-GetProfile.
  3. Найдите элемент <Metadata>.
  4. Установите для параметра AuthenticationType значение ApiKeyHeader.
  5. Установите для параметра AllowInsecureAuthInProduction значение false.
  6. Сразу после закрытия </Metadata> элемента добавьте следующий фрагмент XML: 
    <CryptographicKeys>
    <Key Id="x-functions-key" StorageReferenceId="B2C_1A_RestApiKey" />
</CryptographicKeys>

Идентификатор криптографического ключа определяет заголовок HTTP. В этом примере ключ API отправляется в виде x-functions-key.

Ниже приведен пример, написанный на языке XML, технического профиля RESTful, настроенного для вызова функции Azure с проверкой подлинности с помощью ключа API:

<ClaimsProvider>
  <DisplayName>REST APIs</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="REST-GetProfile">
      <DisplayName>Get user extended profile Azure Function web hook</DisplayName>
      <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
      <Metadata>
        <Item Key="ServiceUrl">https://your-account.azurewebsites.net/api/GetProfile?code=your-code</Item>
        <Item Key="SendClaimsIn">Body</Item>
        <Item Key="AuthenticationType">ApiKeyHeader</Item>
        <Item Key="AllowInsecureAuthInProduction">false</Item>
      </Metadata>
      <CryptographicKeys>
        <Key Id="x-functions-key" StorageReferenceId="B2C_1A_RestApiKey" />
      </CryptographicKeys>
      ...
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

Следующие шаги