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