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

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

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

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

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

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

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

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

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

1. В рабочем каталоге откройте файл политики расширения (TrustFrameworkExtensions.xml).
2. Выполните поиск технического профиля REST API. Например REST-ValidateProfile, или REST-GetProfile.
3. Найдите элемент <Metadata>.
4. Измените тип проверки подлинности на 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>

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

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

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

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

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

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

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

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

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

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. Измените тип проверки подлинности на ClientCertificate.
5. Измените AllowInsecureAuthInProduction на false.
6. Сразу после закрытия </Metadata> элемента добавьте следующий фрагмент XML:

   <CryptographicKeys>
      <Key Id="ClientCertificate" StorageReferenceId="B2C_1A_RestApiClientCertificate" />
   </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">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). При аутентификации с помощью маркера носителя Azure AD B2C отправляет HTTP-запрос с токеном в заголовке авторизации.

Authorization: Bearer <token>

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

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

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

В следующих шагах показано, как использовать учетные данные клиента для получения токена-доступа и передачи его в заголовок Authorization при вызовах 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. Для получения дополнительной информации см. Microsoft identity platform and the OAuth 2.0 client credentials flow.

Прежде чем технический профиль сможет взаимодействовать с Microsoft Entra ID для получения токена доступа, необходимо зарегистрировать приложение. 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 AD 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. Введите в Secret идентификатор клиента, который вы записали ранее.
9. Для использования ключа выберите Signature.
10. Нажмите кнопку "Создать".
11. Создайте другой ключ политики со следующими параметрами:
    • Имя: SecureRESTClientSecret.
    • Секрет: введите секрет клиента, записанный ранее

Для ServiceUrl замените your-tenant-name на имя вашего арендатора 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>

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

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

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

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

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

4. Измените Тип проверки подлинности на носителя, как показано ниже.

   <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. В поле Secret введите ваш секрет клиента, который вы записали ранее.
9. Для использования ключа выберите Encryption.
10. Нажмите кнопку "Создать".

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

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

1. В рабочем каталоге откройте файл политики расширения (TrustFrameworkExtensions.xml).
2. Выполните поиск технического профиля REST API. Например REST-ValidateProfile, или REST-GetProfile.
3. Найдите элемент <Metadata>.
4. Измените тип проверки подлинности на 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" для маскирования доступа к конечным точкам HTTP во время разработки, при этом требуется, чтобы вызывающий объект включал уникальный ключ в качестве HTTP-заголовка или параметра HTTP-запроса. Для Функций Azure это можно сделать, добавив code в качестве параметра запроса в URL-адрес конечной точки ваш соединитель API. Например, https://contoso.azurewebsites.net/api/endpoint?code=0123456789).

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

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

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

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

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

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

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

1. В рабочем каталоге откройте файл политики расширения (TrustFrameworkExtensions.xml).
2. Выполните поиск технического профиля REST API. Например REST-ValidateProfile, или REST-GetProfile.
3. Найдите элемент <Metadata>.
4. Измените тип проверки подлинности на 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>

• Начните с наших примеров.

• Дополнительные сведения об элементе технического профиля RESTful см. в справочнике по пользовательской политике.