Создание надстроек SharePoint, использующих авторизацию с высоким уровнем доверия

  • Статья

Надстройка с высоким уровнем доверия это Надстройка SharePoint, которая устанавливается в локальной ферме SharePoint. Ее нельзя установить в Microsoft SharePoint Online или продавать в Магазин Office. Такие надстройки устанавливают доверие с помощью сертификата, а не токена контекста.

Примечание.

В этой статье рассказывается о системе авторизации с высоким уровнем доверия для надстроек SharePoint. Практические сведения о создании и развертывании надстроек с высоким уровнем доверия см. в указанных ниже статьях.

В SharePoint служба токенов безопасности предоставляет маркеры доступа для проверки подлинности "сервер-сервер". Служба токенов безопасности позволяет с помощью маркеров временного доступа получать доступ к другим службам приложений, например к надстройкам SharePoint, Exchange и Lync. Администратор фермы устанавливает отношения доверия между SharePoint и другим приложением или надстройкой с помощью командлетов Windows PowerShell и сертификата. Каждый используемый сертификат должен быть доверенным для SharePoint с помощью командлета New-SPTrustedRootAuthority . Кроме того, все сертификаты необходимо зарегистрировать в SharePoint как издателей маркеров с помощью командлета New-SPTrustedSecurityTokenIssuer.

Примечание.

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

Два типа издателей маркеров

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

Существует два типа издателей маркеров: некоторые из них могут издавать маркеры только для определенной надстройки SharePoint, другие, называемые брокерами доверия, могут издавать маркеры для нескольких надстроек SharePoint.

На практике администраторы ферм SharePoint определяют тип создаваемых издателей маркеров с помощью параметров и значений параметров, которые указываются в командлете New-SPTrustedSecurityTokenIssuer. Чтобы создать издатель маркера, представляющий собой брокер доверия, добавьте параметр -IsTrustBroker в командной строке и укажите для параметра -Name уникальное значение, отличное от идентификатора клиента надстройки. Ниже приведен измененный пример.

New-SPTrustedSecurityTokenIssuer -IsTrustBroker -RegisteredIssuerName "<full_token_issuer_name> " --other parameters omitted--

При создании издателя маркера, не являющегося брокером, параметр -IsTrustBroker не используется. Есть еще одно отличие. Значение параметра -RegisteredIssuerName всегда имеет форму двух GUID, разделенных символом "@": GUID@GUID. GUID справа — всегда идентификатор области проверки подлинности фермы SharePoint (или подписки сайта). GUID слева — всегда определенный идентификатор для издателя маркера.

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

$fullIssuerIdentifier = "<client_ID_of_SP_app> " + "@" + "<realm_GUID> "
New-SPTrustedSecurityTokenIssuer -RegisteredIssuerName $fullIssuerIdentifier --other parameters omitted--

Обычно командлет New-SPTrustedSecurityTokenIssuer используется в скрипте, выполняющем другие задачи по настройке SharePoint для надстроек с высоким уровнем доверия. Дополнительные сведения о таких скриптах и полные примеры командлета New-SPTrustedSecurityTokenIssuer см. в статье Скрипты настройки для SharePoint с высоким уровнем доверия.

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

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

  • использование одного и того же сертификата для нескольких надстроек SharePoint;

  • использование отдельных сертификатов для каждого Надстройка SharePoint.

В этом разделе рассказывается о преимуществах и недостатках каждой стратегии.

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

Чтобы все еще надежные надстройки SharePoint снова работали, администратору потребуется создать New-SPTrustedSecurityTokenIssuer объект с помощью нового сертификата и включить -IsTrustBroker флаг. Новый сертификат необходимо зарегистрировать на каждом сервере, на котором размещаются заслуживающие доверия надстройки, и каждую из таких надстроек необходимо связать с новым сертификатом.

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

Сертификаты — это корневые центры в SharePoint

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

Каждый сертификат в цепочке добавляется в список доверенных корневых центров SharePoint с помощью вызова командлета New-SPTrustedRootAuthority . Например, предположим, что сертификат веб-приложения это сертификат домена, выданный корпоративным доменным центром сертификации в локальной сети, и что его сертификат в свою очередь был выдан автономным центром сертификации верхнего уровня в локальной сети. В этом сценарии сертификаты ЦС верхнего уровня, промежуточного ЦС и веб-приложения следует добавить в список доверенных корневых центров сертификации SharePoint. Это можно сделать с помощью следующего кода Windows PowerShell.

$rootCA = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("<path_to_top-level_CA's_cer_file>")
New-SPTrustedRootAuthority -Name "<name_of_certificate>" -Certificate $rootCA

$intermediateCA = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("path_to_intermediate_CA's_cer_file")
New-SPTrustedRootAuthority -Name "<name_of_certificate>" -Certificate $intermediateCA

$certificate = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("path_to_web_application's_cer_file") 
New-SPTrustedRootAuthority -Name "<name_of_certificate>" -Certificate $certificate

Корневой и промежуточный сертификаты следует добавить на ферме SharePoint только один раз. Обычно сертификат веб-приложения добавляется в отдельный скрипт, который также выполняет настройку другой конфигурации, например вызова New-SPTrustedSecurityTokenIssuer. Примеры см. в статье Скрипты настройки для SharePoint с высоким уровнем доверия.

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

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

Веб-приложению необходимо знать, что это издатель маркеров

Компонент удаленного веб-приложения надстройки SharePoint привязан к соответствующему цифровому сертификату в IIS. Этого достаточно для достижения обычных целей, для которых предназначен сертификат: безопасная идентификация веб-приложения и кодирование HTTP-запросов и откликов.

Однако в надстройке SharePoint с высоким уровнем доверия у сертификата есть дополнительная задача, согласно которой он выступает в качестве официального "издателя" маркеров доступа, которые веб-приложение отправляет в SharePoint. Для этой цели у веб-приложения должны быть сведения об идентификаторе издателя для сертификата. Этот идентификатор используется при регистрации сертификата в качестве издателя маркеров в SharePoint. Веб-приложение получает этот идентификатор из раздела appSettings файла web.config, в котором есть ключ с названием IssuerId.

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

Обратите внимание на то, что если пользователь придерживается стратегии использования отдельного сертификата для каждой надстройки SharePoint с высоким уровнем доверия, значение ClientId также используется в качестве значения IssuerId. Это не так, когда для нескольких надстроек используется один и тот же сертификат, потому что у каждой надстройки SharePoint должен быть собственный уникальный идентификатор клиента, но идентификатор издателя — это идентификатор для объекта SPTrustedSecurityTokenIssuer.

Далее приведен пример раздела appSettings для Надстройка SharePoint с высоким уровнем доверия. В нем сертификат используется несколькими надстройками, поэтому значение IssuerId не совпадает с ClientId. Обратите внимание, что ключа ClientSecret в Надстройка SharePoint с высоким уровнем доверия нет.

<appSettings>
  <add key="ClientId" value="6569a7e8-3670-4669-91ae-ec6819ab461" />
  <add key="ClientSigningCertificatePath" value="C:\MyCerts\HighTrustCert.pfx" />
  <add key="ClientSigningCertificatePassword" value="3VeryComplexPa$$word82" />
  <add key="IssuerId" value="e9134021-0180-4b05-9e7e-0a9e5a524965" />
</appSettings>

Примечание.

В предыдущем примере предполагается, что сертификат хранится в файловой системе. Это приемлемо при разработке и отладке. В рабочей надстройке SharePoint с высоким уровнем доверия сертификат обычно размещается в хранилище сертификатов Windows, а ключи ClientSigningCertificatePath и ClientSigningCertificatePassword обычно заменяют ключом ClientSigningCertificateSerialNumber.

Обязанности сотрудников ИТ-подразделения в системе высоким уровнем доверия

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

  • Создание или приобретение одного или нескольких сертификатов, которые будут использоваться для доверенных надстроек SharePoint.

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

  • Управление распределением этих сертификатов среди разработчиков, создающих надстройки SharePoint.

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

См. также