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

  • Статья

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

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

На портале нельзя напрямую настроить несколько поставщиков входа для пользователей (например, через Facebook и Twitter). Однако эту функцию можно легко добавить к функциональным возможностям вашего приложения. Для этого необходимо сделать следующее:

Во-первых, на странице Authentication / Authorization (Проверка подлинности и авторизация) на портале Azure настройте все поставщики удостоверений, которые нужно включить.

В раскрывающемся списке Action to take when request is not authenticated (Предпринимаемое действие, если проверка подлинности для запроса не выполнена) выберите Разрешить анонимные запросы (нет действия).

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

<a href="/.auth/login/aad">Log in with the Microsoft Identity Platform</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/twitter">Log in with Twitter</a>
<a href="/.auth/login/apple">Log in with Apple</a>

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

Чтобы перенаправить пользователя после входа по пользовательскому URL-адресу, используйте параметр строки запроса post_login_redirect_uri (не следует путать с 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>"}

Формат токена незначительно отличается в соответствии с поставщиком. Дополнительные сведения см. в таблице, приведенной ниже.

Значение поставщика Требуется в тексте запроса Комментарии
aad {"access_token":"<access_token>"} Свойства id_token, refresh_token и expires_in являются необязательными.
microsoftaccount {"access_token":"<access_token>"} или {"authentication_token": "<token>" Предпочтительнее использовать authentication_token, а не access_token. Свойство expires_in необязательное.
При запросе маркера из служб Live всегда запрашиваются области wl.basic.
google {"id_token":"<id_token>"} Свойство authorization_code необязательное. Если указать значение authorization_code, маркеры доступа и обновления будут добавлены в хранилище маркеров. Если указано свойство authorization_code, оно может сопровождаться свойством redirect_uri.
facebook {"access_token":"<user_access_token>"} Используйте допустимый токен доступа пользователя из Facebook.
twitter {"access_token":"<access_token>", "access_token_secret":"<access_token_secret>"}

Примечание.

Поставщик GitHub для проверки подлинности Служба приложений не поддерживает настраиваемый вход и выход.

При успешной проверке токена поставщика API возвращается с authenticationToken в тексте ответа, который является вашим токеном сеанса.

{
    "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-адреса внешнего перенаправления для приложения. В следующем примере показано перенаправление на адрес https://myexternalurl.com, который не размещен в одном и том же домене:

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_FRAGMENT значение true. Это можно сделать на портале Azure или просто выполнив следующую команду в 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. В https://resources.azure.com в верхней части страницы выберите Read/Write (Чтение и запись).

  2. В левой части браузера перейдите к разделу 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.

Так вы сможете добавить параметр строки запроса domain_hint к URL-адресу перенаправления для входа.

Внимание

Клиент может удалить параметр domain_hint после получения URL-адреса перенаправления, а затем войти с помощью другого домена. Это удобная, но не безопасная функция.

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

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

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

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

  1. Перейдите на страницу https://<app-name>.scm.azurewebsites.net/DebugConsole.

  2. В обозревателе файлов Службы приложений перейдите в раздел site/wwwroot. Если файл Web.config не существует, создайте его, выбрав +>New File (Создать файл).

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

    <?xml version="1.0" encoding="utf-8"?>
<configuration>
   <system.web>
      <authorization>
        <allow users="user1@contoso.com,user2@contoso.com"/>
        <deny users="*"/>
      </authorization>
   </system.web>
</configuration>

Уровень поставщика удостоверений

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

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

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

Дополнительные ресурсы