Публикация приложений с использованием предварительной проверки подлинности AD FS

  • Статья

Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016

Данный материал относится к локальной версии прокси-сервера веб-приложения. Чтобы обеспечить безопасный доступ к локальным приложениям в облаке, см . содержимое прокси приложения Microsoft Entra.

В этом разделе описывается, как публиковать приложения с помощью прокси веб-приложения с помощью предварительной проверки подлинности службы федерации Active Directory (AD FS) (AD FS).

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

Общий поток предварительной проверки подлинности AD FS выглядит следующим образом:

Примечание.

Этот поток проверки подлинности неприменимо для клиентов, использующих приложения Microsoft Store.

  1. Клиентское устройство пытается получить доступ к опубликованному веб-приложению по определенному URL-адресу ресурса; например https://app1.contoso.com/.

    URL-адрес ресурса — это общедоступный адрес, на котором прокси-сервер веб-приложения прослушивает входящие HTTPS-запросы.

    Если включена перенаправление HTTP в HTTPS, прокси-сервер веб-приложения также будет прослушивать входящие HTTP-запросы.

  2. Прокси веб-приложения перенаправляет HTTPS-запрос на сервер AD FS с параметрами, закодированными URL-адресами, включая URL-адрес ресурса и appRealm (идентификатор проверяющей стороны).

    Пользователь проходит проверку подлинности с помощью метода проверки подлинности, требуемого сервером AD FS; Например, имя пользователя и пароль, двухфакторная проверка подлинности с одноразовым паролем и т. д.

  3. После проверки подлинности пользователя сервер AD FS выдает маркер безопасности, маркер edge, содержащий следующие сведения и перенаправляет HTTPS-запрос обратно на прокси-сервер веб-приложения:

    • Идентификатор ресурса, к которому пытался обратиться пользователь.

    • Удостоверение пользователя в качестве имени участника-пользователя (UPN).

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

    • Подпись информации в граничном токене.

  4. Прокси веб-приложения получает перенаправленный HTTPS-запрос от сервера AD FS с пограничным маркером и проверяет и использует маркер следующим образом:

    • Проверяет, является ли подпись маркера edge из службы федерации, настроенной в конфигурации прокси-сервера веб-приложения.

    • Проверяет, выдан ли токен для правильного приложения.

    • Проверяет, не истек ли срок действия токена.

    • При необходимости использует удостоверение пользователя, например для получения билета Kerberos, если внутренний сервер настроен для использования встроенной проверки подлинности Windows.

  5. Если маркер края действителен, прокси-сервер веб-приложения перенаправит HTTPS-запрос в опубликованное веб-приложение с помощью HTTP или HTTPS.

  6. Клиент получает доступ к опубликованному веб-приложению, однако опубликованное приложение может потребовать от пользователя пройти дополнительную проверку подлинности. Например, если опубликованное веб-приложение представляет собой сайт SharePoint и для него не требуется дополнительная проверка подлинности, то в браузере пользователя откроется сайт SharePoint.

  7. Прокси веб-приложения сохраняет файл cookie на клиентском устройстве. Файл cookie используется прокси-сервером веб-приложения для определения того, что этот сеанс уже был предварительно проверен и что дополнительная предварительная идентификация не требуется.

Внимание

Во время настройки внешнего URL-адреса и URL-адреса внутреннего сервера необходимо указывать полное доменное имя, а не IP-адрес.

Примечание.

В этом разделе приводятся примеры командлетов Windows PowerShell, которые можно использовать для автоматизации некоторых описанных процедур. Дополнительные сведения см. в разделе Использование командлетов.

Публикация приложения на основе утверждений для клиентов с веб-браузерами

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

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

  1. Клиент пытается получить доступ к приложению на основе утверждений с помощью веб-браузера; например, https://appserver.contoso.com/claimapp/.

  2. Веб-браузер отправляет HTTPS-запрос на прокси-сервер веб-приложения, который перенаправляет запрос на сервер AD FS.

  3. Сервер AD FS проверяет подлинность пользователя и устройства и перенаправляет запрос обратно в прокси веб-приложения. Теперь запрос содержит граничный токен. Сервер AD FS добавляет файл cookie единого входа в запрос, так как пользователь уже выполнил проверку подлинности на сервере AD FS.

  4. Прокси веб-приложения проверяет маркер, добавляет собственный файл cookie и пересылает запрос на внутренний сервер.

  5. Сервер сервер перенаправляет запрос на сервер AD FS, чтобы получить маркер безопасности приложения.

  6. Запрос перенаправляется на внутренний сервер сервер сервером AD FS. Теперь запрос содержит токен приложения и файл cookie для единого входа. Пользователю предоставляется доступ к приложению без необходимости вводить имя пользователя или пароль.

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

  • Создано доверие проверяющей стороны для приложения в консоли управления AD FS.

  • Убедитесь, что сертификат на прокси-сервере веб-приложения подходит для приложения, которое вы хотите опубликовать.

Публикация приложения на основе утверждений

  1. На прокси-сервере веб-приложения в консоли управления удаленным доступом в области навигации щелкните "Прокси веб-приложения", а затем в области "Задачи" нажмите кнопку "Опубликовать".

  2. В окне мастера публикации нового приложения на странице приветствия нажмите кнопку Далее.

  3. На странице предварительной проверки подлинности щелкните службы федерации Active Directory (AD FS) (AD FS) и нажмите кнопку "Далее".

  4. На странице Поддерживаемые клиенты выберите Веб и MSOFBA, а затем нажмите кнопку Далее.

  5. На странице Проверяющая сторона выберите из списка проверяющую сторону для публикуемого приложения и нажмите кнопку Далее.

  6. На странице Параметры публикации выполните указанные ниже действия и нажмите кнопку Далее.

    • В поле Имя введите понятное имя для приложения.

      Это имя используется только в списке опубликованных приложений на консоли управления удаленным доступом.

    • В поле "Внешний URL-адрес" введите внешний URL-адрес для этого приложения, например https://sp.contoso.com/app1/.

    • В списке Внешние сертификаты выберите сертификат, субъект которого содержит внешний URL-адрес.

    • В поле URL-адрес внутреннего сервера введите URL-адрес внутреннего сервера. Обратите внимание, что это значение автоматически вводится при вводе внешнего URL-адреса и следует изменить его только в том случае, если внутренний URL-адрес сервера отличается; Например https://sp/app1/.

      Примечание.

      Прокси-сервер веб-приложения может переводить имена узлов в URL-адресах, но не может переводить имена путей. Следовательно, можно указывать другие имена узлов, но путь должен оставаться тем же. Например, можно ввести внешний URL-адрес и URL-адрес https://apps.contoso.com/app1/ внутреннего сервера https://app-server/app1/. Однако вы не можете ввести внешний URL-адрес и URL-адрес https://apps.contoso.com/app1/https://apps.contoso.com/internal-app1/внутреннего сервера.

  7. Просмотрите настройки на странице Подтверждение, а затем нажмите кнопку Опубликовать. Можно скопировать команду PowerShell для настройки дополнительных опубликованных приложений.

  8. На странице Результаты убедитесь в успешной публикации приложения, а затем нажмите кнопку Закрыть.

Эквивалентные команды Windows PowerShell

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

Add-WebApplicationProxyApplication
    -BackendServerURL 'https://sp.contoso.com/app1/'
    -ExternalCertificateThumbprint '1a2b3c4d5e6f1a2b3c4d5e6f1a2b3c4d5e6f1a2b'
    -ExternalURL 'https://sp.contoso.com/app1/'
    -Name 'SP'
    -ExternalPreAuthentication ADFS
    -ADFSRelyingPartyName 'SP_Relying_Party'

Публикация приложения со встроенной проверкой подлинности Windows для клиентов с веб-браузерами

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

Чтобы разрешить прокси-серверу веб-приложения выполнять единый вход (SSO) и выполнять делегирование учетных данных с помощью ограниченного делегирования Kerberos, прокси-сервер веб-приложения должен быть присоединен к домену. См. раздел "План Active Directory".

Чтобы пользователи могли получать доступ к приложениям, используюющим интегрированные проверка подлинности Windows, прокси-сервер веб-приложений должен иметь возможность предоставлять делегирование для пользователей в опубликованное приложение. Эту настройку можно выполнить на контроллере домена для любого приложения. Это также можно сделать на серверном сервере, если он работает в Windows Server 2012 R2 или Windows Server 2012. Дополнительные сведения см. в разделе Новые возможности аутентификации Kerberos.

Пошаговое руководство по настройке прокси веб-приложения для публикации приложения с помощью интегрированных проверка подлинности Windows см. в статье "Настройка сайта для использования интегрированных проверка подлинности Windows".

При использовании встроенной проверка подлинности Windows на внутренних серверах проверка подлинности между прокси веб-приложениями и опубликованным приложением не основана на утверждениях, а использует ограниченное делегирование Kerberos для проверки подлинности конечных пользователей в приложении. Общий поток работы описан ниже:

  1. Клиент пытается получить доступ к приложению, отличному от утверждений, с помощью веб-браузера; например, https://appserver.contoso.com/nonclaimapp/.

  2. Веб-браузер отправляет HTTPS-запрос на прокси-сервер веб-приложения, который перенаправляет запрос на сервер AD FS.

  3. Сервер AD FS проходит проверку подлинности пользователя и перенаправляет запрос обратно в прокси веб-приложения. Теперь запрос содержит граничный токен.

  4. Прокси веб-приложения проверяет маркер.

  5. Если маркер действителен, прокси-сервер веб-приложения получает билет Kerberos от имени пользователя контроллера домена.

  6. Прокси веб-приложения добавляет билет Kerberos в запрос в рамках маркера простого и защищенного механизма согласования GSS-API (SPNEGO) и перенаправляет запрос на внутренний сервер. Запрос содержит билет Kerberos, поэтому пользователю предоставляется доступ к приложению без необходимости дополнительной проверки подлинности.

В этой процедуре описывается публикация приложения, использующего встроенную проверку подлинности Windows, например Outlook Web App, к которому будут обращаться клиенты с веб-браузерами. Перед началом работы убедитесь, что выполнены следующие действия.

  • Создано доверие проверяющей стороны, не поддерживающей утверждения, для приложения в консоли управления AD FS.

  • Настройте внутренний сервер для поддержки ограниченного делегирования Kerberos на контроллере домена или используйте командлет Set-ADUser с параметром -PrincipalsAllowedToDelegateToAccount. Обратите внимание, что если сервер сервер работает на сервере Windows Server 2012 R2 или Windows Server 2012, вы также можете запустить эту команду PowerShell на сервере серверной части.

  • Убедитесь, что прокси-серверы веб-приложения настроены для делегирования имени субъекта-службы серверных серверов.

  • Убедитесь, что сертификат на прокси-сервере веб-приложения подходит для приложения, которое вы хотите опубликовать.

Публикация приложения, не использующего утверждения

  1. На прокси-сервере веб-приложения в консоли управления удаленным доступом в области навигации щелкните "Прокси веб-приложения", а затем в области "Задачи" нажмите кнопку "Опубликовать".

  2. В окне мастера публикации нового приложения на странице приветствия нажмите кнопку Далее.

  3. На странице предварительной проверки подлинности щелкните службы федерации Active Directory (AD FS) (AD FS) и нажмите кнопку "Далее".

  4. На странице Поддерживаемые клиенты выберите Веб и MSOFBA, а затем нажмите кнопку Далее.

  5. На странице Проверяющая сторона выберите из списка проверяющую сторону для публикуемого приложения и нажмите кнопку Далее.

  6. На странице Параметры публикации выполните указанные ниже действия и нажмите кнопку Далее.

    • В поле Имя введите понятное имя для приложения.

      Это имя используется только в списке опубликованных приложений на консоли управления удаленным доступом.

    • В поле "Внешний URL-адрес" введите внешний URL-адрес для этого приложения, например https://owa.contoso.com/.

    • В списке Внешние сертификаты выберите сертификат, субъект которого содержит внешний URL-адрес.

    • В поле URL-адрес внутреннего сервера введите URL-адрес внутреннего сервера. Обратите внимание, что это значение автоматически вводится при вводе внешнего URL-адреса и следует изменить его только в том случае, если внутренний URL-адрес сервера отличается; Например https://owa/.

      Примечание.

      Прокси-сервер веб-приложения может переводить имена узлов в URL-адресах, но не может переводить имена путей. Следовательно, можно указывать другие имена узлов, но путь должен оставаться тем же. Например, можно ввести внешний URL-адрес и URL-адрес https://apps.contoso.com/app1/ внутреннего сервера https://app-server/app1/. Однако вы не можете ввести внешний URL-адрес и URL-адрес https://apps.contoso.com/app1/https://apps.contoso.com/internal-app1/внутреннего сервера.

    • В поле Имя субъекта-службы внутреннего сервера введите имя субъекта-службы для внутреннего сервера, например HTTP/owa.contoso.com.

  7. Просмотрите настройки на странице Подтверждение, а затем нажмите кнопку Опубликовать. Можно скопировать команду PowerShell для настройки дополнительных опубликованных приложений.

  8. На странице Результаты убедитесь в успешной публикации приложения, а затем нажмите кнопку Закрыть.

Эквивалентные команды Windows PowerShell

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

Add-WebApplicationProxyApplication
    -BackendServerAuthenticationSpn 'HTTP/owa.contoso.com'
    -BackendServerURL 'https://owa.contoso.com/'
    -ExternalCertificateThumbprint '1a2b3c4d5e6f1a2b3c4d5e6f1a2b3c4d5e6f1a2b'
    -ExternalURL 'https://owa.contoso.com/'
    -Name 'OWA'
    -ExternalPreAuthentication ADFS
    -ADFSRelyingPartyName 'Non-Claims_Relying_Party'

Публикация приложения, использующего MS-OFBA

Прокси веб-приложения поддерживает доступ от клиентов Microsoft Office, таких как Microsoft Word, которые получают доступ к документам и данным на внутренних серверах. Единственное различие между этими приложениями и стандартным браузером заключается в том, что перенаправление на stS выполняется не через регулярное перенаправление HTTP, а с особыми заголовками MS-OFBA, как указано в следующих https://msdn.microsoft.com/library/dd773463(v=office.12).aspxпараметрах. Внутреннее приложение может быть основано на утверждениях или на встроенной проверке подлинности Windows. Чтобы опубликовать приложение для клиентов, использующих MS-OFBA, необходимо добавить доверие проверяющей стороны для приложения в службу федерации. В зависимости от приложения можно использовать проверку подлинности на основе утверждений или встроенную проверку подлинности Windows. Таким образом, необходимо добавить отношение доверия с проверяющей стороной, соответствующее приложению.

Чтобы разрешить прокси-серверу веб-приложения выполнять единый вход (SSO) и выполнять делегирование учетных данных с помощью ограниченного делегирования Kerberos, прокси-сервер веб-приложения должен быть присоединен к домену. См. раздел "План Active Directory".

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

Поток проверки подлинности для клиентов, использующих протокол MS-OFBA с использованием проверки подлинности на основе утверждений, описан ниже. В данном сценарии проверки подлинности может использоваться токен приложения либо в URL-адресе, либо в основной части.

  1. Пользователь работает в программе Office и в списке Недавние документы открывает файл на сайте SharePoint.

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

    Примечание.

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

  3. Прокси веб-приложения перенаправляет запрос на сервер AD FS, который выполняет проверку подлинности.

  4. Сервер AD FS перенаправляет запрос обратно в прокси веб-приложения. Теперь запрос содержит граничный токен.

  5. Сервер AD FS добавляет файл cookie единого входа в запрос, так как пользователь уже выполнил проверку подлинности на сервере AD FS.

  6. Прокси веб-приложения проверяет маркер и перенаправляет запрос на внутренний сервер.

  7. Сервер сервер перенаправляет запрос на сервер AD FS, чтобы получить маркер безопасности приложения.

  8. Запрос перенаправляется внутреннему серверу. Теперь запрос содержит токен приложения и файл cookie для единого входа. Пользователю предоставляется доступ к сайту SharePoint без необходимости вводить имя пользователя или пароль для просмотра файла.

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

Публикация приложения, использующего HTTP Basic

HTTP Basic — это протокол авторизации, используемый многими протоколами, для подключения богатых клиентов, включая смартфоны, с почтовым ящиком Exchange. Дополнительные сведения о HTTP Basic см. в rfC 2617. Прокси веб-приложения традиционно взаимодействует с AD FS с помощью перенаправлений; большинство богатых клиентов не поддерживают файлы cookie или управление состоянием. Таким образом прокси-сервер веб-приложения позволяет HTTP-приложению получать доверие проверяющей стороны, отличные от утверждений, для приложения в службу федерации. См. раздел "План Active Directory".

Поток проверки подлинности для клиентов, использующих HTTP Basic, описан ниже и на этой схеме:

Authentication diagram for HTTP Basic

  1. Пользователь пытается получить доступ к опубликованному веб-приложению телефонного клиента.

  2. Приложение отправляет HTTPS-запрос на URL-адрес, опубликованный прокси веб-приложением.

  3. Если запрос не содержит учетных данных, прокси веб-приложения возвращает ответ HTTP 401 приложению, содержащий URL-адрес сервера AD FS.

  4. Пользователь снова отправляет httpS-запрос в приложение, указав для параметра "Базовый" и "Имя пользователя" и "Базовый 64 зашифрованный пароль" пользователя в заголовке запроса www-аутентификации.

  5. Так как устройство не может быть перенаправлено в AD FS, прокси веб-приложения отправляет запрос проверки подлинности в AD FS с учетными данными, включающими имя пользователя и пароль. Маркер приобретается от имени устройства.

  6. Чтобы свести к минимуму количество запросов, отправленных в AD FS, прокси веб-приложения, проверяет последующие клиентские запросы с использованием кэшированных маркеров до тех пор, пока маркер действителен. Прокси веб-приложения периодически очищает кэш. Размер кэша можно просмотреть с помощью счетчика производительности.

  7. Если маркер действителен, прокси-сервер веб-приложения перенаправляет запрос на внутренний сервер, а пользователь получает доступ к опубликованному веб-приложению.

В следующей процедуре объясняется, как публиковать базовые приложения HTTP.

Публикация приложения HTTP Basic

  1. На прокси-сервере веб-приложения в консоли управления удаленным доступом в области навигации щелкните "Прокси веб-приложения", а затем в области "Задачи" нажмите кнопку "Опубликовать".

  2. В окне мастера публикации нового приложения на странице приветствия нажмите кнопку Далее.

  3. На странице предварительной проверки подлинности щелкните службы федерации Active Directory (AD FS) (AD FS) и нажмите кнопку "Далее".

  4. На странице "Поддерживаемые клиенты" выберите HTTP Basic и нажмите кнопку "Далее".

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

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

  6. На странице Параметры публикации выполните указанные ниже действия и нажмите кнопку Далее.

    • В поле Имя введите понятное имя для приложения.

      Это имя используется только в списке опубликованных приложений на консоли управления удаленным доступом.

    • В поле "Внешний URL-адрес" введите внешний URL-адрес для этого приложения, например mail.contoso.com

    • В списке Внешние сертификаты выберите сертификат, субъект которого содержит внешний URL-адрес.

    • В поле URL-адрес внутреннего сервера введите URL-адрес внутреннего сервера. Обратите внимание, что это значение автоматически вводится при вводе внешнего URL-адреса и следует изменить его только в том случае, если внутренний URL-адрес сервера отличается; например, mail.contoso.com.

  7. Просмотрите настройки на странице Подтверждение, а затем нажмите кнопку Опубликовать. Можно скопировать команду PowerShell для настройки дополнительных опубликованных приложений.

  8. На странице Результаты убедитесь в успешной публикации приложения, а затем нажмите кнопку Закрыть.

Эквивалентные команды Windows PowerShell

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

Этот скрипт Windows PowerShell обеспечивает предварительную проверку подлинности для всех устройств, а не только для подключенных к рабочему месту устройств.

Add-WebApplicationProxyApplication
     -BackendServerUrl 'https://mail.contoso.com'
     -ExternalCertificateThumbprint '697F4FF0B9947BB8203A96ED05A3021830638E50'
     -ExternalUrl 'https://mail.contoso.com'
     -Name 'Exchange'
     -ExternalPreAuthentication ADFSforRichClients
     -ADFSRelyingPartyName 'EAS_Relying_Party'

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

Add-WebApplicationProxyApplication
     -BackendServerUrl 'https://mail.contoso.com'
     -ExternalCertificateThumbprint '697F4FF0B9947BB8203A96ED05A3021830638E50'
     -EnableHTTPRedirect:$true
     -ExternalUrl 'https://mail.contoso.com'
     -Name 'Exchange'
     -ExternalPreAuthentication ADFSforRichClients
     -ADFSRelyingPartyName 'EAS_Relying_Party'

Публикация приложения, использующего OAuth2, например приложение Microsoft Store

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

Чтобы разрешить прокси-серверу веб-приложения выполнять единый вход (SSO) и выполнять делегирование учетных данных с помощью ограниченного делегирования Kerberos, прокси-сервер веб-приложения должен быть присоединен к домену. См. раздел "План Active Directory".

Примечание.

Прокси веб-приложения поддерживает публикацию только для приложений Microsoft Store, использующих протокол OAuth 2.0.

В консоли управления AD FS необходимо убедиться, что конечная точка OAuth включена. Для этого откройте консоль управления AD FS, разверните раздел Служба, щелкните пункт Конечные точки, в списке Конечные точки найдите конечную точку OAuth и убедитесь, что в столбце С включенным прокси указано значение Да.

Поток проверки подлинности для клиентов, использующих приложения Microsoft Store, описан ниже.

Примечание.

Прокси веб-приложения перенаправляется на сервер AD FS для проверки подлинности. Так как приложения Microsoft Store не поддерживают перенаправления, при использовании приложений Microsoft Store необходимо задать URL-адрес сервера AD FS с помощью командлета Set-WebApplicationProxyConfiguration и параметра OAuthAuthenticationURL.

Приложения Microsoft Store можно публиковать только с помощью Windows PowerShell.

  1. Клиент пытается получить доступ к опубликованному веб-приложению с помощью приложения Microsoft Store.

  2. Приложение отправляет HTTPS-запрос на URL-адрес, опубликованный прокси веб-приложением.

  3. Прокси веб-приложения возвращает ответ HTTP 401 на приложение, содержащее URL-адрес сервера AD FS. Этот процесс называется обнаружением.

    Примечание.

    Если приложение знает URL-адрес сервера AD FS и уже содержит маркер со списком, содержащий маркер OAuth и маркер edge, шаги 2 и 3 пропускаются в этом потоке проверки подлинности.

  4. Приложение отправляет HTTPS-запрос на сервер AD FS.

  5. Приложение использует брокер веб-проверки подлинности для создания диалогового окна, в котором пользователь вводит учетные данные для проверки подлинности на сервере AD FS. Сведения о брокере веб-проверки подлинности см. в статье Брокер веб-проверки подлинности.

  6. После успешной проверки подлинности сервер AD FS создает маркер со списком, содержащий маркер OAuth и пограничный маркер, и отправляет маркер в приложение.

  7. Приложение отправляет HTTPS-запрос, содержащий маркер со списком, на URL-адрес, опубликованный прокси веб-приложением.

  8. Прокси веб-приложения разделяет маркер со списком на две части и проверяет пограничный маркер.

  9. Если маркер края действителен, прокси-сервер веб-приложения перенаправляет запрос на внутренний сервер только с маркером OAuth. Пользователю предоставляется доступ к опубликованному веб-приложению.

В этой процедуре описывается публикация приложения для OAuth2. Этот тип приложения можно опубликовать только с помощью Windows PowerShell. Перед началом работы убедитесь, что выполнены следующие действия.

  • Создано доверие проверяющей стороны для приложения в консоли управления AD FS.

  • Убедитесь, что конечная точка OAuth включена в консоли управления AD FS и запишите путь URL-адреса.

  • Убедитесь, что сертификат на прокси-сервере веб-приложения подходит для приложения, которое вы хотите опубликовать.

Публикация приложения OAuth2

  1. На прокси-сервере веб-приложения в консоли управления удаленным доступом в области навигации щелкните "Прокси веб-приложения", а затем в области "Задачи" нажмите кнопку "Опубликовать".

  2. В окне мастера публикации нового приложения на странице приветствия нажмите кнопку Далее.

  3. На странице предварительной проверки подлинности щелкните службы федерации Active Directory (AD FS) (AD FS) и нажмите кнопку "Далее".

  4. На странице "Поддерживаемые клиенты" выберите OAuth2 и нажмите кнопку "Далее".

  5. На странице Проверяющая сторона выберите из списка проверяющую сторону для публикуемого приложения и нажмите кнопку Далее.

  6. На странице Параметры публикации выполните указанные ниже действия и нажмите кнопку Далее.

    • В поле Имя введите понятное имя для приложения.

      Это имя используется только в списке опубликованных приложений на консоли управления удаленным доступом.

    • В поле "Внешний URL-адрес" введите внешний URL-адрес для этого приложения, например https://server1.contoso.com/app1/.

    • В списке Внешние сертификаты выберите сертификат, субъект которого содержит внешний URL-адрес.

      Чтобы убедиться, что пользователи могут получить доступ к приложению, даже если они игнорируют ввод HTTPS в URL-адресе, выберите поле "Включить перенаправление HTTP в HTTPS".

    • В поле URL-адрес внутреннего сервера введите URL-адрес внутреннего сервера. Обратите внимание, что это значение автоматически вводится при вводе внешнего URL-адреса и следует изменить его только в том случае, если внутренний URL-адрес сервера отличается; Например https://sp/app1/.

      Примечание.

      Прокси-сервер веб-приложения может переводить имена узлов в URL-адресах, но не может переводить имена путей. Следовательно, можно указывать другие имена узлов, но путь должен оставаться тем же. Например, можно ввести внешний URL-адрес и URL-адрес https://apps.contoso.com/app1/ внутреннего сервера https://app-server/app1/. Однако вы не можете ввести внешний URL-адрес и URL-адрес https://apps.contoso.com/app1/https://apps.contoso.com/internal-app1/внутреннего сервера.

  7. Просмотрите настройки на странице Подтверждение, а затем нажмите кнопку Опубликовать. Можно скопировать команду PowerShell для настройки дополнительных опубликованных приложений.

  8. На странице Результаты убедитесь в успешной публикации приложения, а затем нажмите кнопку Закрыть.

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

Чтобы задать URL-адрес сервера проверки подлинности OAuth для fs.contoso.com и URL-адрес /adfs/oauth2/:

Set-WebApplicationProxyConfiguration -OAuthAuthenticationURL 'https://fs.contoso.com/adfs/oauth2/'

Чтобы опубликовать приложение:

Add-WebApplicationProxyApplication
    -BackendServerURL 'https://storeapp.contoso.com/'
    -ExternalCertificateThumbprint '1a2b3c4d5e6f1a2b3c4d5e6f1a2b3c4d5e6f1a2b'
    -ExternalURL 'https://storeapp.contoso.com/'
    -Name 'Microsoft Store app Server'
    -ExternalPreAuthentication ADFS
    -ADFSRelyingPartyName 'Store_app_Relying_Party'
    -UseOAuthAuthentication