Настройка доверия oAuth между фермами в SharePoint 2013
Исходная статья была опубликована в понедельник, 23 июля 2012 года
Одна из вещей, о которой вы наверняка много услышите в связи с SharePoint 2013 и о которой мне в итоге придется много писать, это модель проверки подлинности oAuth. В SharePoint 2013 модель oAuth используется для установления доверия между двумя приложениями с целью установить удостоверение участника (пользователя или приложения). В SharePoint доверие oAuth используется при взаимодействии SharePoint и таких приложений, как Exchange и Lync, со службой ACS или отдельными разработчиками приложений, использующими новую модель облачных приложений, или даже при взаимодействии двух ферм SharePoint, например при работе с функцией удаленного индекса SharePoint в меню "Поиск".
Чем НЕ является модель oAuth, так это поставщиком проверки подлинности для пользователей. Вам по-прежнему нужно использовать New-SPTrustedIdentityTokenIssuer для создания доверия к поставщикам удостоверений. Для доверия oAuth мы предложили новый командлет со сходным названием, а именно New-SPTrustedSecurityTokenIssuer. Устанавливая такой тип доверия при помощи издателя маркеров безопасности, мы называем его доверием типа S2S, что означает "взаимодействие сервера с сервером". Запомните это сокращение, так как оно будет часто встречаться вам в SharePoint 2013. В этой статье я собираюсь рассказать о некоторых особенностях создания такого доверия.
Во-первых, есть смысл подчеркнуть, что многие функции, требующие доверия типа S2S, установят его самостоятельно. Это может произойти путем активации функции, либо группы разработки функций могут предоставить вам сценарий или командлет PowerShell, в результате выполнения которых доверие будет создано как часть процесса включения этой функции. Тем не менее, есть случаи, когда вам придется сделать это самостоятельно. Этому вопросу и посвящена данная статья.
Один из первых вопросов, которые нужно решить, это будете ли вы использовать SSL. На самом деле, в большинстве случаев в SharePoint 2013 лучше использовать SSL. Я говорю так потому, что в SharePoint 2013 очень много сценариев, задействующих oAuth, и если вы используете SSL, то вы обходите файл cookie при помощи маркера доступа. Маркер доступа похож на ключ, открывающий дверь к данным. Он подписан сертификатом, поэтому его нельзя подделать, создав свой собственный маркер доступа, но в любом случае, нежелательно, чтобы маркер доступа передавался открытым текстом. Теоретически кто-нибудь может перехватить данный файл cookie и воспроизвести его в течение времени жизни этого cookie. SSL обеспечивает защиту от этой атаки на файл cookie точно так же и по тем же причинам, по каким вы используете SSL для сайта с проверкой подлинности на основе форм. C другой стороны, есть и причины, по которым вы хотели бы запускать свои сайты через HTTP – вы находитесь в среде тестирования, вы расширяете среду разработки, вы работаете полностью во внутренней сети и не предвидите рисков, и т.п. Я здесь не для того, чтобы судить – я просто объясняю.
ШАГ 1. Настройка службы маркеров безопасности (STS)
В конфигурации службы маркеров безопасности SharePoint (STS) есть несколько настроек, которые вы, возможно, захотите изменить, если вы не используете SSL. Все настройки STS можно получить при помощи этого командлета: Get-SPSecurityTokenServiceConfig. Для установления доверия есть два пути — один при помощи сертификата, а второй при помощи новой конечной точки метаданных oAuth, которой обладают все фермы SharePoint. Использование конечной точки метаданных — самый простой путь, но если эта конечная точка не защищена посредством SSL, необходимо присвоить значение истинности свойству AllowMetadataOverHttp в службе SharePoint STS. Если вы не собираетесь запускать веб-приложения через SSL, вам также понадобится присвоить значение истинности свойству AllowOAuthOverHttp. Вот небольшой сценарий PowerShell, иллюстрирующий, как настроить эти свойства:
$c = Get-SPSecurityTokenServiceConfig
$c.AllowMetadataOverHttp = $true
$c.AllowOAuthOverHttp= $true
$c.Update()
ШАГ 2. Создание доверия
После настройки службы маркеров безопасности можно перейти к установлению доверия между двумя фермами. Как я упоминал ранее, теперь у ферм SharePoint есть конечная точка метаданных, которая используется для предоставления информации и сертификата для подписи маркеров доступа. Эта конечная точка метаданных находится здесь: /_layouts/15/metadata/json/1. Если вы попытаетесь перейти по этому адресу в браузере, вам будет предложено сохранить страницу, что можно сделать в целях изучения. Если открыть файл в "Блокноте", то окажется, что это просто полезная нагрузка JSON. Она содержит идентификатор имени для службы маркеров безопасности (который в STS называется “издатель”), а также серийная версия сертификата для подписания маркера (в STS он описывается как “значение” для ключа “x509certificate”). Если приглядеться к данным, то вы увидите, что издатель на самом деле представляет собой имя службы + “@” + значения областей. Он также соответствует свойству NameIdentifier в STS. Это важная информация, чуть позже я объясню, почему.
Допустим, в нашем примере ферме FARM_B необходимо доверять переходам от FARM_A, поскольку ферма FARM_A собирается использовать ферму FARM_B в качестве удаленного индекса SharePoint. Предположим также, что у фермы FARM_A есть веб-приложение, расположенное по адресу https://FARM_A. Чтобы создать отношение доверия, нужно запустить командлет New-SPTrustedSecurityTokenIssuer на сервере в FARM_B следующим образом (немного позже я объясню, почему я использую “$i = “):
$i = New-SPTrustedSecurityTokenIssuer -Name FARM_A -Description "FARM_A description" -IsTrustBroker:$false -MetadataEndPoint "https://FARM_A/_layouts/15/metadata/json/1"
Теперь предположим, что вы настраиваете доверенное отношение с фермой, являющейся только фермой служб. Вы не хотите создавать веб-приложение, коллекцию сайтов и SSL-сертификат только для того, чтобы создать в них доверие. Итак, у нас есть второй способ настройки доверия, использующий командлет New-SPTrustedSecurityTokenIssuer. Во второй форме можно просто предоставить сертификат для подписи маркера и идентификатор имени. Сертификат для подписания маркера можно получить точно так же, как в SharePoint 2010 – зайдите на сервер в ферме, запустите MMC, добавьте оснастку "Сертификаты" для локального компьютера, а затем посмотрите узел SharePoint…"Сертификаты", и первым сертификатом в списке будет тот, который вам нужен – просто сохраните его на локальный диск без закрытого ключа в виде файла с расширением .cer. Для установления доверия вам понадобится этот сертификат и атрибут NameIdentifier из службы маркеров безопасности, описанный выше. В этом случае командлет выглядит следующим образом (он предполагает, что вы скопировали сертификат STS в файл под названием C:\sts.cer на сервере в ферме FARM_B):
$i = New-SPTrustedSecurityTokenIssuer -name FARM_A -Certificate "C:\sts.cer" -RegisteredIssuerName "00000003-0000-0ff1-ce00-000000000000@72da1552-085a-49de-9ecb-73ba7eca8fef " -Description "FARM_A description" -IsTrustBroker:$false
ШАГ 3. Доверие к сертификату для подписания маркера
По аналогии с SPTrustedIdentityTokenIssuer, вам понадобится добавить доверие, используемое для подписи маркеров oAuth, в список надежных центров сертификации в SharePoint. Здесь у вас опять на выбор два варианта, как это сделать: если вы создаете отношение доверия посредством конечной точки метаданных, установить доверенное отношение можно следующим образом:
New-SPTrustedRootAuthority -Name FARM_A -MetadataEndPoint https://FARM_A/_layouts/15/metadata/json/1/rootcertificate
Другой вариант подразумевает добавление надежных центров сертификации по аналогии с тем, как это происходило в SharePoint 2010:
$root = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:\sts.cer")
New-SPTrustedRootAuthority -Name "Token Signing Root CA Certificate" -Certificate $root
С точки зрения доверия, на этом шаге все готово – отношение доверия установлено, и теперь вы можете создавать новых участников приложения на его основе. Как вы будете его использовать, зависит уже от самого приложения. В случае с удаленным индексом SharePoint я продолжу действовать, чтобы завершить этот сценарий.
ШАГ 4. Создание участника приложения (пример только для удаленного индекса SharePoint):
Этот процесс состоит из двух этапов – создание участника приложения и предоставление ему прав. Как вы помните из нашего сценария, ферме FARM_B необходимо доверять переходам от FARM_A, поскольку она будет получать запросы к удаленному индексу SharePoint. Поэтому для моего участника приложения мне нужно получить ссылку на веб-приложение в ферме FARM_B, которое собирается использовать ферма FARM_A. Когда у меня будет эта ссылка, я смогу предоставить права, чтобы ферма FARM_A могла ей пользоваться.
Чтобы получить ссылку на участника приложения, используйте следующий командлет:
$p = Get-SPAppPrincipal -Site https://FARM_B -NameIdentifier $i.NameId
ВАЖНАЯ ИНФОРМАЦИЯ. Здесь следует упомянуть об одном важном обстоятельстве, которое, на мой взгляд, будет регулярно возникать, особенно в бета-версии SharePoint 2013. При попытке выполнения командлета SPAppPrincipal вы можете натолкнуться на странные ошибки в PowerShell. Я обнаружил, что если объем доступной памяти на сервере упадет ниже 5%, все вызовы WCF будут отклонены. Поскольку этот командлет PowerShell совершает вызов конечной точки приложения-службы, размещенной как служба WCF, командлет Get-SPAppPrincipal не выполняется, если у вас недостаточно памяти. Вы можете проверить по журналу приложений в компоненте "Просмотр событий" Windows, действительно ли в этом состоит причина вашей проблемы. Со мной это происходило несколько раз, поэтому есть все шансы, что и другие тоже обнаружат эту особенность.
Обратите внимание, что я наконец могу использовать переменную $i (ранее упомянутую в этой статье), чтобы получить параметр NameIdentifier службы маркеров безопасности в ферме FARM_A. Теперь, когда у меня есть ссылка на участника приложения для веб-приложения фермы FARM_B, я могу предоставить ему права следующим образом:
Set-SPAppPrincipalPermission -Site https://FARM_B -AppPrincipal $p -Scope SiteSubscription -Right FullControl
На этом все, теперь вы ознакомились с возможными вариантами и способами создания доверия oAuth между двумя фермами SharePoint. В следующих записях блога я продолжу исследовать модель проверки подлинности oAuth, возможности ее использования и проблемы, о которых следует знать.
Это локализованная запись блога. Оригинал находится на странице Setting Up an oAuth Trust Between Farms in SharePoint 2013