Планирование проверки подлинности приложений в SharePoint Server

 

**Применимо к:**SharePoint 2013, SharePoint Foundation 2013, SharePoint Server 2013, SharePoint Server 2016

**Последнее изменение раздела:**2017-06-27

Сводка. Узнайте, как планировать проверку подлинности приложений в SharePoint 2013 и SharePoint Server 2016.

Аутентификация приложения — это проверка удостоверения внешнего приложения приложение для SharePoint и авторизация приложения и пользователя, когда приложение запрашивает доступ к защищенному ресурсу SharePoint. Аутентификация приложения выполняется, когда внешний компонент приложения Магазин SharePoint или каталога Каталог приложений (например, веб-сервер), расположенный в интрасети или Интернете, пытается получить доступ к защищенному ресурсу SharePoint. Например, приложение для SharePoint, компонент которого выполняется в Microsoft Azure, является внешним приложением. Аутентификация приложения поддерживает новый набор функций и сценариев, которые позволяют приложениям включать данные из ресурсов SharePoint в обрабатываемые и отображаемые для пользователей результаты.

Для предоставления запрошенных ресурсов, которые содержит приложение для SharePoint, сервер SharePoint Server должен выполнить указанные ниже действия.

  • Убедиться, что запрашивающее приложение является доверенным.

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

  • Убедиться, что запрашиваемый приложением тип доступа авторизован.

    Для авторизации доступа SharePoint Server использует набор разрешений приложения, определенный в файле манифеста приложения при его установке, а также разрешения, связанные с пользователем, от имени которого действует приложение. SharePoint Server также использует разрешения, предоставленные объекту SPAppPrincipal при установке отношения доверия с помощью командлета Set-SPAppPrincipalPermissionPowerShell.

Обратите внимание, что проверка подлинности приложений в SharePoint Server выполняется отдельно от проверки подлинности пользователей и не используется в качестве протокола единого входа пользователями SharePoint. Для проверки подлинности приложений используется протокол Open Authorization (OAuth) 2.0, который не добавляется в наборы протоколов проверки подлинности пользователя или единого входа, такие как WS-Federation. В SharePoint Server нет новых протоколов проверки подлинности пользователей. Проверка подлинности приложений и протокол OAuth не отображаются в списке поставщиков удостоверений.

В этой статье

  • Введение

  • Определение набора отношений доверия

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

  • Предоставление входящего доступа из внешних приложений, размещенных в Интернете

  • Рекомендации по работе с приложением-службой профилей пользователей

Введение

Планирование проверки подлинности приложений включает в себя следующие задачи.

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

  • Предоставление входящего доступа из внешних приложений, размещенных в Интернете.

Важно!

Веб-приложения, которые содержат конечные точки проверки подлинности приложений (для входящих запросов от приложений приложения для SharePoint), должны быть настроены на использование протокола SSL. Вы можете настроить OAuth в SharePoint Server таким образом, чтобы протокол SSL не требовался. Однако такая настройка рекомендуется только для оценки, упрощения настройки или создания среды разработки приложений.

Примечание

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

Определение набора отношений доверия

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

  • Приложения, размещенные поставщиком, работают на предназначенных для них серверах в Интернете или интрасети, регистрируются в Microsoft Azure и используют службу контроля доступа для получения токена доступа.

    Для приложений, размещенных поставщиком, необходимо настроить ферму SharePoint на доверие экземпляру ACS приложения, размещенного поставщиком.

    Дополнительные сведения о приложениях, размещаемых на ресурсе поставщика, см. в статье Обзор приложений для SharePoint 2013.

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

    Приложения с высоким уровнем доверия используют протокол обмена данными между серверами для запроса ресурсов от лица пользователя. Для приложений с высоким уровнем доверия настройте в ферме SharePoint конечную точку метаданных JSON для сервера, размещающего приложение. Или же настройте отношение доверия вручную. Дополнительные сведения см. в разделе Настройка проверки подлинности приложений в SharePoint Server 2013.

    Дополнительные сведения о приложениях с высоким уровнем доверия см. в статье Практическое руководство. Создание приложений с высоким уровнем доверия для SharePoint 2013 с использованием протокола обмена данными между серверами.

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

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

Таблица 1. Методы проверки подлинности пользователей и их поддержка в локальных приложениях

Метод проверки подлинности Поддерживается в приложениях с размещением в SharePoint Поддерживается в приложениях с размещением у поставщика

NTLM

Да

Да

Kerberos

Да, но только если метод настроен для использования NTLM в качестве резервного метода проверки подлинности. Проверка подлинности с использованием только Kerberos не поддерживается.

Да

Обычный

Да

Да

Анонимный доступ

Да

Да

Проверка подлинности на основе форм с использованием поставщика ASP.NET по умолчанию

Да

Да

Проверка подлинности на основе форм с использованием протокола LDAP

Да

Да

Проверка подлинности SAML

Да, если поставщик удостоверений поддерживает регистрацию групповых URL-адресов и учитывает параметр wreply.

Чтобы настроить SharePoint Server на использование параметра wreply, выполните следующие команды в окне командной строки Microsoft PowerShell:

$p = Get-SPTrustedIdentityTokenIssuer
$p.UseWReplyParameter = $true
$p.Update()

Примечание

Версия Службы федерации Active Directory (AD FS) 2.0 не поддерживает подстановочные знаки для регистрации URL-адресов возврата.

Да

Дополнительные сведения о методах проверки подлинности пользователей в SharePoint Server см. в статье Планирование методов проверки подлинности для пользователей в SharePoint Server.

Предоставление входящего доступа из внешних приложений, размещенных в Интернете

Если внешние приложения, размещенные у поставщика, расположены в Интернете, необходимо настроить обратный веб-прокси для выполнения проверки подлинности приложения и запроса ресурсов из ферм SharePoint интрасети. Настроенный обратный веб-прокси на границе сети должен разрешать входящие подключения по протоколу HTTPS от приложений к фермам SharePoint. Определите URL-адреса, поддерживающие протокол HTTPS, к которым будут получать доступ внешние приложения, и настройте обратный прокси-сервер на публикацию этих URL-адресов и обеспечение необходимого уровня безопасности.

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

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

Для восстановления удостоверения пользователя сервер SharePoint Server извлекает утверждение из входящего маркера доступа и разрешает его до конкретного пользователя SharePoint. По умолчанию SharePoint Server использует для разрешения удостоверений встроенное приложение-службу профилей пользователей.

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

  • Идентификатор безопасности Windows (ИД безопасности)

  • Имя участника-пользователя доменных служб Active Directory

  • SMTP-адрес

  • Адрес SIP

Приложение должно содержать хотя бы один из этих атрибутов пользователя и этот атрибут должен существовать в профилях пользователей. Рекомендуется периодически синхронизировать приложение-службу профилей пользователей с хранилищами удостоверений.

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

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

See also

Обзор проверки подлинности для SharePoint Server

Новые возможности проверки подлинности для SharePoint 2013