Настройка входа и выхода для аутентификации в службе приложений Azure

В этой статье показано, как настроить вход пользователей и выходы при использовании встроенной проверки подлинности и авторизации в Службе приложений Azure.

Использование нескольких поставщиков входа

Конфигурация портала Azure не предлагает готовый способ предоставления пользователям нескольких поставщиков входа. Например, вы можете предложить как Facebook, так и X в качестве параметров. Чтобы добавить в приложение несколько поставщиков входа:

1. На портале Azure в веб-приложении выберите "Параметрыпроверки подлинности>".

2. Для параметров проверки подлинности нажмите кнопку "Изменить".

3. Для ограничения доступа выберите "Разрешить доступ без проверки подлинности".

4. На странице входа на панели навигации или любом другом расположении в приложении добавьте ссылку на вход для каждого из включенных поставщиков (/.auth/login/<provider>). Например:

   <a href="/.auth/login/aad">Log in with Microsoft Entra</a>
   <a href="/.auth/login/facebook">Log in with Facebook</a>
   <a href="/.auth/login/google">Log in with Google</a>
   <a href="/.auth/login/x">Log in with X</a>
   <a href="/.auth/login/apple">Log in with Apple</a>
   

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

Чтобы перенаправить пользователя на пользовательский URL-адрес после входа, используйте post_login_redirect_uri параметр строки запроса. Например, чтобы переместить пользователя в /Home/Index после входа, используйте следующий HTML код.

<a href="/.auth/login/<provider>?post_login_redirect_uri=/Home/Index">Log in</a>

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

При управляемом клиентом входе приложение регистрирует пользователя в поставщике удостоверений с помощью SDK, специфичного для данного поставщика. Затем код приложения отправляет полученный маркер проверки подлинности в службу приложений для проверки с помощью HTTP-запроса POST . Эта проверка сама не предоставляет пользователям доступ к нужным ресурсам приложения. Успешная проверка дает пользователям маркер сеанса, который они могут использовать для доступа к ресурсам приложения. Дополнительные сведения см. в разделе Поток проверки подлинности.

Чтобы проверить маркер поставщика, приложение службы приложений сначала должно быть настроено с нужным поставщиком. Получив токен проверки подлинности у своего поставщика, во время выполнения отправьте токен по адресу /.auth/login/<provider> для проверки. Например:

POST https://<appname>.azurewebsites.net/.auth/login/aad HTTP/1.1
Content-Type: application/json

{"id_token":"<token>","access_token":"<token>"}

Формат токена немного зависит от поставщика:

Если маркер поставщика проверен успешно, API возвращает значение authenticationToken в теле ответа. This value is your session token. Для получения дополнительной информации об утверждениях пользователей см. в статье "Работа с удостоверениями пользователей в службе приложений Azure".

{
    "authenticationToken": "...",
    "user": {
        "userId": "sid:..."
    }
}

После получения этого маркера сеанса вы можете получить доступ к защищенным ресурсам приложения, добавив X-ZUMO-AUTH заголовок в HTTP-запросы. Например:

GET https://<appname>.azurewebsites.net/api/products/1
X-ZUMO-AUTH: <authenticationToken_value>

Выход из сеанса

Пользователи могут сделать выход, отправив запрос GET в конечную точку /.auth/logout приложения. Запрос GET :

• Очищает файлы cookie проверки подлинности в текущем сеансе.
• Удаляет текущие маркеры пользователя из хранилища маркеров.
• Выполняет выход на стороне сервера у поставщика аутентификации для Microsoft Entra и Google.

Ниже приведена простая ссылка для выхода на веб-странице:

<a href="/.auth/logout">Sign out</a>

После успешного выхода клиент по умолчанию перенаправляется на URL-адрес /.auth/logout/complete. Можно изменить страницу перенаправления после выхода, добавив параметр запроса post_logout_redirect_uri. Например:

GET /.auth/logout?post_logout_redirect_uri=/index.html

Рекомендуется закодировать значение post_logout_redirect_uri.

При использовании полных URL-адресов URL-адрес должен размещаться в том же домене или быть настроен как внешний URL-адрес, разрешённый для перенаправления в вашем приложении. Следующий пример перенаправляет на https://myexternalurl.com URL, который не размещён в том же домене:

GET /.auth/logout?post_logout_redirect_uri=https%3A%2F%2Fmyexternalurl.com

Выполните следующую команду в Azure Cloud Shell:

az webapp auth update --name <app_name> --resource-group <group_name> --allowed-external-redirect-urls "https://myexternalurl.com"

Сохранение фрагментов URL-адреса

После входа в приложение пользователи обычно желают быть перенаправленными в один и тот же раздел той же страницы, например /wiki/Main_Page#SectionZ. Тем не менее, так как фрагменты URL-адресов (например, #SectionZ) никогда не отправляются на сервер, они не сохраняются по умолчанию после завершения входа OAuth и перенаправления обратно в приложение. Затем пользователи получают неоптимальный интерфейс, когда им нужно снова перейти к нужной привязке. Это ограничение распространяется на все решения аутентификации на стороне сервера.

При аутентификации в службе приложений можно сохранять фрагменты URL-адресов в процессе входа через OAuth, установив значение WEBSITE_AUTH_PRESERVE_URL_FRAGMENTtrue. Вы используете этот параметр приложения на портале Azure или выполните следующую команду в Cloud Shell:

az webapp config appsettings set --name <app_name> --resource-group <group_name> --settings WEBSITE_AUTH_PRESERVE_URL_FRAGMENT="true"

Установить подсказку домена для учетных записей входа

Учетные записи Майкрософт и Microsoft Entra позволяют пользователям входить из нескольких доменов. Например, учетная запись Майкрософт разрешает учетные записи outlook.com, live.com, и hotmail.com. Microsoft Entra разрешает любое количество пользовательских доменов для учетных записей входа. Однако вам может потребоваться ускорить переход пользователей непосредственно на вашу фирменную страницу входа в Microsoft Entra (например, contoso.com).

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

1. В обозревателе ресурсов в верхней части страницы выберите "Чтение и запись".

2. On the left pane, go to subscriptions>subscription-name>resourceGroups>resource-group-name>providers>Microsoft.Web>sites>app-name>config>authsettingsV2.

3. Выберите Изменить.

4. Добавьте loginParameters массив с элементомdomain_hint:

   "identityProviders": {
       "azureActiveDirectory": {
           "login": {
               "loginParameters": ["domain_hint=<domain-name>"],
           }
       }
   }
   

5. Нажмите кнопку Put.

This setting appends the domain_hint query string parameter to the sign-in redirect URL.

Авторизация или блокировка пользователей

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

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

Уровень сервера (только для приложений Windows)

Для любого приложения Windows можно определить поведение авторизации веб-сервера IIS, изменив web.config файл. Приложения Linux не используют службы IIS и не могут быть настроены с помощью web.config.

1. Чтобы перейти в консоль отладки Kudu для приложения, выберите "Средства разработки>Дополнительные средства" и выберите "Перейти". Затем выберите консоль отладки.

   Вы также можете открыть эту страницу с помощью этого URL-адреса: https://<app-name>-<random-hash>.scm.<region>.azurewebsites.net/DebugConsole Чтобы получить значения случайного хэша и региона, в обзоре приложения скопируйте домен по умолчанию.

2. In the browser explorer of your App Service files, go to site/wwwroot. Если web.config не существует, создайте его, выбрав +>Новый файл.

3. Выберите карандаш для web.config, чтобы редактировать файл. Добавьте следующий код конфигурации и нажмите кнопку "Сохранить". Если web.config уже существует, просто добавьте элемент <authorization> со всем содержимым. В элементе <allow> добавьте учетные записи, которые требуется разрешить.

   <?xml version="1.0" encoding="utf-8"?>
   <configuration>
      <system.web>
         <authorization>
           <allow users="[email protected],[email protected]"/>
           <deny users="*"/>
         </authorization>
      </system.web>
   </configuration>
   

Identity provider level

Поставщик удостоверений может предоставить определенную авторизацию под ключом. Например:

• Для Microsoft Entra можно напрямую управлять доступом на уровне предприятия . Дополнительные сведения см. в разделе "Удаление доступа пользователей к приложениям".
• Для Google проекты API Google, принадлежащие организации , можно настроить для предоставления доступа только пользователям в вашей организации. Дополнительные сведения см. в разделе "Управление клиентами OAuth".

Уровень приложения

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

Связанный контент

• Учебное пособие: проверка подлинности и авторизация пользователей от начала до конца в службе приложений Azure
• Переменные среды и параметры приложений для проверки подлинности