OAuth и воссоздание пользователя в SharePoint 2013 – как это происходит и с чем его едят

Исходная статья была опубликована в четверг, 16 августа 2012 года

Прежде всего, хочу сказать, что одна из причин, по которой мне нравится писать в блоге SharePoint про всякие штуки, это то, что я могу использовать совершенно разговорные обороты, как в названии этой статьи. Это практически не может остаться безнаказанным, если, конечно, вы не разрабатываете новую версию SharePoint. Кто-нибудь видел эти до смешного будничные выражения в SharePoint 2013? “Прошу прощения, что заставил вас ждать, я почти готов”, и все в этом же духе. Мне кажется это еще более смешным, поскольку перемежается такими сообщениями, как HRESULT, которое как-то довелось увидеть моему приятелю Тому. Что же, чем больше мир меняется, тем больше он остается прежним.

Перейдем ближе к делу. Я уже раз или два упоминал oAuth в этом блоге, когда мы обсуждали некоторые новые функции SharePoint 2013. Но поскольку я сейчас не собираюсь рассказывать по полной программе, “что такое oAuth” (над этим у нас работает целая бригада писателей), я не хочу даже попутно распространяться о случаях, в которых используется эта модель проверки подлинности. Вероятно, лучшим примером использования oAuth является удаленный индекс SharePoint для поиска – то, что позволяет пользователю в одной ферме создать запрос, который направляется на другую ферму SharePoint, и в этой удаленной ферме SharePoint удостоверение пользователя реконструируется таким образом, чтобы обеспечить правильную фильтрацию по ролям безопасности в результатах поиска. Она также используется в других сценариях, например модели новых приложений (есть ли у пользователя право доступа к содержимому, которое запрашивает приложение), при взаимодействии серверных приложений, таких как SharePoint и Exchange (есть ли у пользователя право доступа к содержимому ящика электронной почты) и многих других. Однако мне удачным примером представляется удаленный индекс SharePoint, поскольку, возможно, это лучший сценарий, который демонстрирует, почему необходимо делать то, что мы делаем, чтобы все работало ожидаемым образом.

Так что давайте начнем с самого начала – как в ферме А “сделать Стива”, который будет выглядеть “Стивом” в ферме B? Следует начать с приложения профилей пользователей. Скажем, Стив находится в ферме B и создает запрос. Этот запрос пересылается на ферму A, а вместе с ним ряд атрибутов, принадлежащих Стиву. По умолчанию этими атрибутами являются SMTP-адрес, адрес SIP, имя учетной записи и идентификатор имени Стива. Когда ферма A получает этот запрос, первым делом она выполняет поиск в локальном приложении профилей пользователей, чтобы найти профиль, соответствующий переданным значениям для Стива. Именно поэтому так важно убедиться, что ваше приложение профилей пользователей работоспособно и заполнено в SharePoint 2013, о чем я написал отдельную статью: https://blogs.msdn.com/b/sharepoint_ru/archive/2012/09/20/saml-ad-sharepoint-2013.aspx.

Хорошо, когда ферма A нашла пользовательский профиль Стива, что с ним делать? Правильный ответ – "смотря по обстоятельствам", вот почему так важно распланировать этот аспект в вашей организации. Этими обстоятельствами является тип проверки подлинности, который вы используете, и вот какая между ними связь:

• Утверждения Windows – если вы используете утверждения Windows, то основное, что вам потребуется, содержится в профиле пользователя. Здесь имеются в виду ваше имя учетной записи и группы AD, в которых вы состоите. Чуть позже я поясню, что подразумеваю под словом "основное". Короче говоря, если вы используете утверждения Windows, все будет в порядке.
• Проверка подлинности на основе форм (FBA) – если вы используете FBA, вам следует знать несколько вещей. Во-первых, вам нужен способ заполнить свое приложение UPA и обновлять его. Если вы просто используете FBA для поставщика LDAP, а ваш каталог фактически является каталогом Windows Active Directory, то все относительно просто. Вы можете создать подключение профиля к Active Directory и просто связать его с поставщиком FBA способом, аналогичным тому, что описан в упомянутой выше статье. Однако в большинстве случаев AD не будет являться вашим поставщиком, а значит, придется написать собственный код для заполнения UPA. Этого должно быть достаточно для получения того единственного атрибута, который в действительности необходим для пользователей FBA, то есть имени учетной записи. Но, как вы уже знаете, "в основном" (опять же, скоро объясню подробнее) остальные ваши данные поступают от поставщика ролей. Что здесь здорово, так это то, что при воссоздании пользователя FBA мы также вызываем связанного поставщика ролей, и выходит так, будто пользователь FBA выполняет вход локально. Это позволяет нам получить все утверждения ролей для пользователя FBA.
• Утверждения SAML – это похоже на ситуацию с FBA тем, что в первую очередь следует заполнить свое приложение UPA. Если вам повезет, ваши пользователи попадут в AD, и вы сможете просто импортировать их напрямую, следуя инструкции в упомянутой выше записи блога. Если вам не так повезло, придется найти способ подключиться к исходному каталогу и импортировать пользователей оттуда. Конечно, это сложнее всего сделать в случае с утверждениями SAML, поскольку у вас может быть несколько каталогов, и вы можете владеть не всеми из них (например, у вас есть партнеры, вы выполнили интеграцию с ACS и используете Facebook или другого поставщика, и т.п.). Как бы ни обстояло дело, если вы хотите, чтобы все это "хозяйство" работало, нужно придумать способ заполнить UPA. Здесь есть и второй, более важный момент – когда вы выполняете вход в качестве пользователя SAML, вы получаете набор утверждений от своего поставщика удостоверения (IdP). При таком процессе воссоздания пользователя нет никакого способа имитировать этот вход в систему. Конечно, таково устройство SAML – пользователь может перенаправляться не один раз и получать любое количество приглашений проверки подлинности и типов проверки подлинности (например, двухфакторную проверку подлинности), которые невозможно принять во внимание. Что же это значит для вас? Вам действительно необходимо добавить свои утверждения при помощи дополнения утверждений, если вы хотите использовать их для обеспечения безопасности своего содержимого и установить санкционированный доступ к этому содержимому посредством этого процесса воссоздания пользователя. Во время воссоздания вы не сможете получить утверждения от поставщика удостоверения, поэтому если они вам нужны, следует предоставить их локально. Это та самая оговорка "в основном", которую я упоминал выше, а теперь поясню подробнее.
• Что же это значит – "в основном"? Надеюсь, теперь это стало ясно – вне зависимости от того, используете ли вы проверку подлинности Windows, FBA или SAML, в дополнение к утверждениям, которые вам предоставляет поставщик проверки подлинности, вы также получаете дополнительные утверждения путем их дополнения: https://blogs.technet.com/b/speschka/archive/2010/03/13/writing-a-custom-claims-provider-for-sharepoint-2010-part-1.aspx. Другая вещь, которую мы делаем во время процесса воссоздания, это вызов всех зарегистрированных настраиваемых поставщиков утверждений, так что мы можем также получить любые дополнительные утверждения для воссозданного пользователя, которые он получил бы, выполнив локальный вход в систему и совершив вызов всех этих поставщиков.

Вот почему мне так нравится сценарий с удаленным индексом SharePoint – на этом примере удобно объяснить смысл планирования, которое здесь требуется. Как вы понимаете, в пределах фермы можно предоставить права доступа к содержимому, основанные на группе Windows, роли FBA, утверждении SAML или любом утверждении, добавленном при помощи дополнения. Если у вас нет этих утверждений, когда вы запрашиваете содержимое, то оно будет отфильтровано по ролям безопасности, и вы не получите к нему доступа. Так что вы видите, как это важно, что каждое утверждение, которое вам предоставляется при локальном входе в систему, вы также получаете при воссоздании вашей учетной записи.

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

Это локализованная запись блога. Оригинал находится на странице OAuth and the Rehydrated User in SharePoint 2013 – How’d They do That and What do I Need to Know