Пользовательская проверка подлинности в статических веб-приложениях 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 см. в документации по Служба приложений аутентификации и авторизации с использованием существующей регистрации.
Сведения о настройке входа учетных записей см. в статье "Изменение учетных записей, поддерживаемых приложением " и ограничение приложения Microsoft Entra набору пользователей в клиенте Microsoft Entra.
Примечание.
Хотя раздел конфигурации для идентификатора Microsoft Entra id azureActiveDirectory, платформа псевдонимирует это aad в URL-адресе для входа, выхода и очистки сведений о пользователе. Дополнительные сведения см. в разделе проверки подлинности и авторизации .
Пользовательский сертификат
Чтобы добавить пользовательский сертификат в регистрацию приложения идентификатора Microsoft Entra, выполните следующие действия.
Если это еще не так, отправьте сертификат в Microsoft Key Vault.
Добавьте управляемое удостоверение в статическое веб-приложение.
Для управляемых удостоверений, назначенных пользователем, задайте
keyVaultReferenceIdentityсвойство статического объектаresourceIdсайта управляемому удостоверению, назначенному пользователем.Пропустите этот шаг, если управляемое удостоверение назначено системой.
Предоставьте управляемому удостоверению следующие политики доступа:
- Секреты: Get/List
- Сертификаты: Get/List
Обновите раздел конфигурации проверки подлинности раздела
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 | username |
| X | username |
Чтобы создать приглашение, выполните следующие действия.
- Перейдите к ресурсу Статические веб-приложения в портал Azure.
- В разделе "Параметры" выберите "Управление ролями".
- Выберите Пригласить.
- В списке параметров выберите поставщика авторизации.
- Добавьте имя пользователя или адрес электронной почты получателя в поле сведений о приглашенном.
- Для GitHub и X введите имя пользователя. Для остальных — адрес электронной почты получателя.
- Выберите домен статического сайта в раскрывающемся меню "Домен ".
- Выбранный домен отображается в приглашении. Если у вас есть личный домен, связанный с сайтом, выберите личный домен.
- Добавьте разделенный запятыми список имен ролей в поле Роль.
- Введите максимальное количество часов, в течение которых приглашение будет действительным.
- Максимально возможное ограничение составляет 168 часов, что составляет семь дней.
- Выберите Создать.
- Скопируйте ссылку из поля Invite link (Ссылка приглашения).
- Отправьте ссылку на приглашение пользователю, которому вы предоставляете доступ.
Когда пользователь выбирает ссылку в приглашении, им будет предложено войти с соответствующей учетной записью. После успешного входа пользователь связан с выбранными ролями.
Внимание
Убедитесь, что правила маршрутизации не конфликтуют с выбранными поставщиками проверки подлинности. Блокировка поставщика с помощью правила маршрутизации запрещает пользователям принимать приглашения.
Обновление назначений ролей
- Перейдите к ресурсу Статические веб-приложения в портал Azure.
- В разделе "Параметры" выберите "Управление ролями".
- Выберите пользователя в списке.
- Измените список ролей в поле Роль.
- Выберите Обновить.
Удалить пользователя
- Перейдите к ресурсу Статические веб-приложения в портал Azure.
- В разделе "Параметры" выберите "Управление ролями".
- Найдите пользователя в списке.
- Установите флажок в строке пользователя.
- Выберите команду Удалить.
При удалении пользователя учитывайте следующие моменты:
- Удаление пользователя сделает недействительными их разрешения.
- Распространение по всему миру может занять несколько минут.
- При обратном добавлении пользователя в приложение изменяется
userId.