Пользовательская проверка подлинности в статических веб-приложениях Azure

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

  • Пользовательская проверка подлинности позволяет также настроить параметры настраиваемых поставщиков, которые поддерживают OpenID Connect. Такая конфигурация позволяет регистрировать несколько внешних поставщиков.

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

Примечание.

Настраиваемая аутентификация доступна только в тарифном плане "Стандартный" для статических веб-приложений Azure.

Настройка поставщика пользовательских удостоверений

Пользовательские поставщики удостоверений настраиваются в auth разделе конфигурационного файла.

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

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

Имя параметра Значение
AZURE_CLIENT_ID Идентификатор приложения (клиента) для регистрации приложения Microsoft Entra.
AZURE_CLIENT_SECRET_APP_SETTING_NAME Имя параметра приложения, который содержит секрет клиента для регистрации приложения Microsoft Entra.

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

Поставщики Microsoft Entra доступны в двух разных версиях. Версия 1 явно определяет userDetailsClaim, что позволяет возвращать в полезной нагрузке сведения о пользователе. Версия 2 по умолчанию возвращает сведения о пользователе и обозначается v2.0 в URL-адресе openIdIssuer.

Microsoft Entra версии 1

{
  "auth": {
    "identityProviders": {
      "azureActiveDirectory": {
        "userDetailsClaim": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
        "registration": {
          "openIdIssuer": "https://login.microsoftonline.com/<TENANT_ID>",
          "clientIdSettingName": "AZURE_CLIENT_ID",
          "clientSecretSettingName": "AZURE_CLIENT_SECRET_APP_SETTING_NAME"
        }
      }
    }
  }
}

Обязательно замените <TENANT_ID> на идентификатор клиента арендатора Microsoft Entra.

Microsoft Entra версия 2

{
  "auth": {
    "identityProviders": {
      "azureActiveDirectory": {
        "registration": {
          "openIdIssuer": "https://login.microsoftonline.com/<TENANT_ID>/v2.0",
          "clientIdSettingName": "AZURE_CLIENT_ID",
          "clientSecretSettingName": "AZURE_CLIENT_SECRET_APP_SETTING_NAME"
        }
      }
    }
  }
}

Обязательно замените <TENANT_ID> на идентификатор клиента арендатора Microsoft Entra.

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

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

Следующие шаги предполагают, что вы уже настроили регистрацию приложения Microsoft Entra для вашего статического веб-приложения.

  1. Создание управляемой идентичности, назначенной пользователем.

  2. В портале Azure откройте ваше статическое веб-приложение.

  3. В разделе Настройки выберите пункт Идентификация.

  4. На вкладке «Назначенное пользователем » выберите «Добавить», выберите управляемый идентификатор, а затем «Добавить».

    Внимание

    Назначьте управляемую идентичность, назначаемую пользователем, только статическому веб-приложению, которое использует эту регистрацию приложения. Назначение идентичности другому ресурсу даёт этому ресурсу доступ к регистрации приложения.

  5. Запишите идентификатор объекта и идентификатор клиента управляемой идентичности. Вы используете идентификатор объекта для создания федеративного идентификатора, а идентификатор клиента — для настройки статического веб-приложения.

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

  7. В вашем статическом веб-приложении, в разделе Настройки, выберите переменные окружения.

  8. Добавьте назначение приложения под названием OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID. Задайте для него значение Client ID управляемой идентичности. Не используйте идентификатор клиента при регистрации приложения.

  9. В разделе azureActiveDirectory регистрации вашего staticwebapp.config.json файла установите clientSecretSettingName на OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID. Рассмотрим пример.

    {
  "auth": {
    "identityProviders": {
      "azureActiveDirectory": {
        "registration": {
          "openIdIssuer": "https://login.microsoftonline.com/<TENANT_ID>/v2.0",
          "clientIdSettingName": "AZURE_CLIENT_ID",
          "clientSecretSettingName": "OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID"
        }
      }
    }
  }
}

  10. Развернуть обновлённую конфигурацию и убедиться, что пользователи могут войти.

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

Дополнительные сведения о настройке Microsoft Entra ID см. в документации по аутентификации/авторизации в службе приложений с использованием существующей регистрации.

Чтобы настроить, какие учетные записи могут входить, см. «Изменение учетных записей, поддерживаемых приложением» и «Ограничение приложения Microsoft Entra определенной группой пользователей в арендаторе Microsoft Entra».

Примечание.

Хотя раздел конфигурации для идентификатора Microsoft Entra ID azureActiveDirectory, платформа указывает псевдоним aad в URL-адресах для входа, выхода и очистки сведений о пользователе. Дополнительные сведения см. в разделе проверки подлинности и авторизации .

Пользовательский сертификат

Чтобы добавить пользовательский сертификат в регистрацию приложения идентификатора Microsoft Entra, выполните следующие действия.

  1. Если это еще не так, отправьте сертификат в Microsoft Key Vault.

  2. Добавьте управляемую идентификацию в ваше статическое веб-приложение.

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

    Пропустите этот шаг, если управляемое удостоверение назначено системой.

  3. Предоставьте управляемому удостоверению следующие полномочия доступа:

    • Секреты: Get/List
    • Сертификаты: Get/List

  4. Обновите раздел проверки подлинности в секции конфигурации azureActiveDirectory с помощью значения clientSecretCertificateKeyVaultReference, как показано в следующем примере:

    {
  "auth": {
    "rolesSource": "/api/GetRoles",
    "identityProviders": {
      "azureActiveDirectory": {
        "userDetailsClaim": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
        "registration": {
          "openIdIssuer": "https://login.microsoftonline.com/common/v2.0",
          "clientIdSettingName": "AZURE_CLIENT_ID",
          "clientSecretCertificateKeyVaultReference": "@Microsoft.KeyVault(SecretUri=https://<KEY_VAULT_NAME>.azure.net/certificates/<CERTIFICATE_NAME>/<CERTIFICATE_VERSION_ID>)",
          "clientSecretCertificateThumbprint": "*"
        }
      }
    }
  }
}

    Обязательно замените значения для заполнителей, окруженных <>.

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

    Установите clientSecretCertificateThumbprint равным *, чтобы всегда получать последнюю версию отпечатка сертификатов.

Обратные вызовы проверки подлинности

Поставщики идентификации требуют URL перенаправления для завершения запроса входа или выхода. Большинству поставщиков требуется добавление URL-адресов обратного вызова в список разрешённых. Следующие конечные точки доступны в качестве назначений перенаправления.

Тип Шаблон URL-адреса
Вход https://<YOUR_SITE>/.auth/login/<PROVIDER_NAME_IN_CONFIG>/callback
Выход https://<YOUR_SITE>/.auth/logout/<PROVIDER_NAME_IN_CONFIG>/callback

Если вы используете идентификатор Microsoft Entra, используйте aad в качестве значения заполнителя <PROVIDER_NAME_IN_CONFIG> .

Примечание.

Эти URL-адреса предоставляются статическими веб-приложениями Azure для получения ответа от поставщика проверки подлинности. Вам не нужно создавать страницы на этих маршрутах.

Сведения о входе, выходе и пользователе

Чтобы использовать настраиваемый провайдер удостоверений, используйте следующие шаблоны URL-адресов.

Действие Расписание
Вход /.auth/login/<PROVIDER_NAME_IN_CONFIG>
Выход /.auth/logout
Сведения о пользователе /.auth/me
Очистка сведений о пользователе /.auth/purge/<PROVIDER_NAME_IN_CONFIG>

Если вы используете идентификатор Microsoft Entra, используйте aad в качестве значения заполнителя <PROVIDER_NAME_IN_CONFIG> .

Управление ролями

Каждому пользователю, обращающемуся к Статическому веб-приложению, присваивается одна или несколько ролей. Существует две встроенные роли, которые назначаются пользователям:

  • анонимный: все пользователи автоматически принадлежат анонимнойроли.
  • проверка подлинности: все пользователи, вошедшие в систему, относятся к роли, прошедшей проверку подлинности .

Помимо встроенных ролей, можно назначить пользовательские роли пользователям и ссылаться на них в файле staticwebapp.config.json .

Добавление пользователя к роли

Чтобы добавить пользователя к роли, создаются приглашения, позволяющие ассоциировать пользователей с конкретными ролями. Роли определяются и сохраняются в файле staticwebapp.config.json.

Создание приглашения

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

Поставщик авторизации Раскрывает
Microsoft Entra ID Адрес электронной почты
GitHub имя пользователя
X имя пользователя

Чтобы создать приглашение, выполните следующие действия.

  1. Перейдите к ресурсу Статические веб-приложения в портал Azure.
  2. В разделе "Параметры" выберите "Управление ролями".
  3. Выберите Пригласить.
  4. В списке параметров выберите поставщика авторизации.
  5. Добавьте имя пользователя или адрес электронной почты получателя в поле сведений о приглашенном.
    • Для GitHub и X введите имя пользователя. Для остальных — адрес электронной почты получателя.
  6. Выберите домен статического сайта в раскрывающемся меню "Домен ".
    • Выбранный домен отображается в приглашении. Если у вас есть личный домен, связанный с сайтом, выберите личный домен.
  7. Добавьте разделенный запятыми список имен ролей в поле Роль.
  8. Введите максимальное количество часов, в течение которых приглашение будет действительным.
    • Максимально возможное ограничение составляет 168 часов, что составляет семь дней.
  9. Выберите Создать.
  10. Скопируйте ссылку из поля Invite link (Ссылка приглашения).
  11. Отправьте ссылку на приглашение пользователю, которому вы предоставляете доступ.

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

Внимание

Убедитесь, что правила маршрутизации не конфликтуют с выбранными поставщиками проверки подлинности. Блокировка поставщика с помощью правила маршрутизации запрещает пользователям принимать приглашения.

Обновление назначений ролей

  1. Перейдите к ресурсу Статические веб-приложения в портал Azure.
  2. В разделе "Параметры" выберите "Управление ролями".
  3. Выберите пользователя в списке.
  4. Измените список ролей в поле Роль.
  5. Выберите Обновить.

Удалить пользователя

  1. Перейдите к ресурсу Статические веб-приложения в портал Azure.
  2. В разделе "Параметры" выберите "Управление ролями".
  3. Найдите пользователя в списке.
  4. Установите флажок в строке пользователя.
  5. Выберите команду Удалить.

При удалении пользователя учитывайте следующие моменты:

  • Удаление пользователя сделает недействительными их разрешения.
  • Распространение по всему миру может занять несколько минут.
  • При повторном добавлении пользователя в приложение происходят измененияuserId.

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

Установка ролей пользователей программным способом

  • Последнее обновление: