SharePoint 2010: Безопасность в Business Conectivity Services

Введение

Существует два подхода к аутентификации при работе с внешними источниками данных:

• идентификатор пользователя
• имперсонализация

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

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

Явным примером двух типов аутентификации может являться работа с SQL Server для развертывания SharePoint.

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

Однако при варианте развертывания SharePoint на ферме, появляется необходимость имперсонализации пользователя для доступа к данным из SQL Server. Как правило заводится специализированная доменная учетная запись с необходимыми для работы с SQL Server разрешениями. И соответственно, все действия с данными SharePoint производит именно через неё, независимо от того, какой пользователь в данное время аутентифицирован в нём.

Рассмотрим, как же организовать имперсонализацию при работе с внешними источниками данных в SharePoint 2010.

Single Sign-On или Secure Stored Service

Вы наверняка знаете, что такое SSO (single sign-on), и помните, что в предыдущих версиях SharePoint она называлась именно так. В SharePoint 2010 данная служба сменила своё название, теперь она называется Secure Store Service (русский эквивалент: Служба Безопасного Хранения).

Данная служба занимается проверкой подлинности на сервере приложений, если быть точным, то она обеспечивает взаимодействие пользователей/групп пользователей с различными системами без необходимости повторного входа в систему. Основное назначение данной службы в SharePoint – взаимодействие с внешними системами. Если в вашей организации имеются приложения, данные из которых вы хотели бы предоставить для пользователей SharePoint, а так же обеспечить безопасность доступа, то вы должны воспользоваться SSS (Secure Store Service).

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

Настройка SSS

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

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

Кстати, в отличии от SSO и BDC, который был доступен только в MOSS, Secure Stored Service и Business Connectivity Services будут доступны и в SharePoint Server 2010 и в SharePoint Fundation 2010

SSS можно включить в SharedServices. По-умолчанию данный сервис отмечен галочкой в мастере настройке фермы, так что велика вероятность того, что у вас он уже установлен.

Создадим Secure Store Application, для этого нам понадобится:

1. Пройти к Central Administration — Application Management — Manage Service Applications
2. Перед созданием приложения необходимо так же сгенерировать для него ключик:
3. Далее вам необходимо будет указать администратора и настройки приложения, а так же отображаемые поля (по-умолчанию они называются Windows User Name, Windows Password, название не несёт в себе никакой нагрузки, кроме описательной, в связи с чем можно переименовать их просто в UserName и Password, чтобы не путаться).
4. В конце создания укажите разрешения для приложения:

Вот мы и создали приложение для безопасного хранения, зачем же оно нам может понадобиться?

Рассмотрим пример со сторонним приложением, данные которого хранятся в SQL Server, однако по историческим причинам в нём заведены для доступа отдельные учетные записи. Перед вами стоит задача организовать приложение на BCS для доступа к этим данным.

Для этого вам необходимо:

1. Запустить SharePoint Designer 2010
2. Перейти к секции External Content Types
3. Создать новый тип содержимого
4. В качестве источника данных указать SQL Server
5. В окне доступа к данным уточнить наименование сервера, наименование базы данных, так же имя для отображения. Так же вам потребуется выбрать способ имперсонализации (в данном случае на основе Windows Identity) и указать идентификатор (его наименование, которое вы указывали при его создании) Secure Store Application

 

Если соединение удастся, то вы всё сделали верно, остальные действия ничем не будут отличаться от стандартных, а так же будут действовать все указанные вами в Secure Store Application правила.

Давайте также разберемся с терминологией SharePoint аутентификации

Users Identity (PassThrough)

Пользователь, прошедший идентификацию обращается к BCS со своим идентификатором. Это обозначает, что Windows идентификатор будет передан напрямую через BCS приложение к IIS, который в свою очередь отправит его на SQL Server (к примеру), где в зависимости от его разрешений будут предоставлены данные.

BDC Identity (RevertToSelf)

Как не трудно догадаться в данном случае доступ к внешнему источнику данных будет осуществляться под идентификатором пользователя пула приложения (под ним выполняются службы BCS). Соответственно вам необходимо предоставить доступ к данным для этой учетной записи.

Impersonated Windows Identity (WindowsCredentials)

Под данным термином и подразумевается SSS аутентификация.

Impersonated Custom Identity

В основном под данным пунктом подразумевается Claims based Federated Authentication. К примеру поддерживающий SAML аккаунты пользователей

SAML (англ. Security Assertion Markup Language — язык разметки подтверждения безопасности) — основанный на языке XML стандарт, разработанный OASIS для обмена данными об аутентификации и авторизации между защищенными доменами. Одной из важных проблем, которую пытается решить SAML это обеспечение сквозной аутентификации (Технология единого входа, Single Sign On) при работе через Web-браузер.

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

Если вы будете писать,  к примеру настольное приложение для работы с BCS, то данный вид аутентификации будет вам весьма полезен. Аналогично работают и Office-клиенты (Outlook, SharePoint Workspace). Каждый клиент обращается к Security Token Service на ферме SharePoint, где получает ”доверенный идентификатор”, с которым впоследствии отправляется в BCS.

RdbCredentials

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

Разрешения в BCS

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

Напомню, что основными элементами описания в BCS являются:

• Metadata store – фактически все описания, содержащиеся в BCS
• Model – описание так называемой BDC Model, может содержать несколько внешних типов содержимого, связи с внешними данными, а так же типаутентификации
• External system – источник данных (база данных, веб-сервис, .NET сборка)
• External content type – внешний тип содержимого
• Method – операция над типом содержимого
• Method instance – настройка метода, к примеру параметры по-умолчанию

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

В SharePoint BCS существуют 4 типа разрешений:

1. Edit – практически на всех уровнях иерархии позволяет редактировать элементы, а так же создавать новые
2. Execute – как правило определяет какие методы могут быть вызваны
3. Selectable in clients – означает, что пользователь может создавать на основе данного типа содержимого списки
4. Set permissions – пользователь может указывать разрешения для других пользователей на данном элементе

Так же существуют специализированные группы разрешений для SharePoint:

• Администртор фермы – привилегированный пользователь BCS, имеет полный набор прав по-умолчанию. Данные полномочия предоставлены для возможности восстановления прав. Однако администратор фермы не имеет прав Execute, пока ему их не предоставит администратор экземпляра BDC
• Клиенты объектной модели – сюда попадают скриптовые сценарии (PowerShell, IronPython, STSADM Extensions), а так же приложения, написанные на .NET (C#, VB). Они так же имеют полный набор разрешений
• Пользователи, под которыми запущены пулы приложений на серверах приложений – имеют те же права, что и администраторы ферм, это связанно, с тем, что есть необходимость в разрешениях для установки определений
• Пользователи SharePoint Designer – имеют, как правило, полный набор прав, за исключением предоставления прав (set permissions), хотя могут убирать права

Редактировать разрешения можно через SharePoint Designer, узел администрирования, редактируя описание BDC Model’и, а так же через объектную модель. Первые два средства соответственно не дают возможностей тонкой настройки.

Материалы

http://www.lightningtools.com/blog/ – блог о SharePoint BDC, BCS от создателей BDC MetaMan и MCS MetaMan

http://technet.microsoft.com/en-us/library/ee681491(office.14).aspx – планирование BCS на Technet

---