Управление проверкой подлинности для каталога бизнес-данных.

Статья
06/12/2012

Каталог бизнес-данных для Microsoft Office SharePoint Server 2007 поддерживает две модели проверки подлинности и три режима проверки подлинности, которые используют единый вход для хранения учетных данных пользователей.

Содержание:

Выбор предпочтительной модели и режима проверки подлинности
Настройка учетных записей для серверного приложения
Включение и настройка службы единого входа
Создание и настройка определений корпоративных приложений
Изменение и импорт определения приложения для приложения
Требования задачи

Чтобы управлять проверкой подлинности для каталога бизнес-данных, используя единый вход, выполняйте действия, описанные в данном документе, для каждой базы данных или веб-службы, интегрируемой в развертывание.

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

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

Выбор модели проверки подлинности

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

Каталог бизнес-данных поддерживает следующие модели проверки подлинности:

Доверенная подсистема
Олицетворение и делегирование

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

Преимущества модели доверенной подсистемы.

Пул подключений к базе данных.
Упрощение администрирования.
Администраторы внутреннего сервера для приложений должны управлять разрешениями только для одной учетной записи

Доверенная подсистема является хорошим выбором для новых развертываний. Администраторам приложений не требуется настраивать разрешения авторизации на внутреннем сервере для большого числа пользователей. Вместо этого они могут настроить одну учетную запись для каждого приложения, а затем настроить авторизацию в Office SharePoint Server.

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

Преимущества модели олицетворения и делегирования.

Аудит на внутреннем сервере.
Авторизация каждого пользователя на внутреннем сервере без какой-либо дополнительной настройки.

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

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

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

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

Режим проверки подлинности	Описание	Использование единого входа
Сквозной режим	Используются учетные данные вошедшего пользователя для проверки подлинности в отношении приложения на внутреннем сервере. Этот режим доступен только для модели проверки подлинности олицетворения и делегирования. Для сквозного режима проверки подлинности должно быть включено делегирование Kerberos.	Нет
RevertToSelf	Используется учетная запись удостоверения пула приложений для проверки подлинности пользователей на внутреннем сервере. Поскольку вместо отдельной учетной записи всегда используется учетная запись службы, режим RevertToSelf использует модель проверки подлинности доверенной подсистемы.	Нет
Учетные данные Windows	Используется для баз данных и веб-служб. Каталог бизнес-данных олицетворяет учетную запись пользователя Windows с учетными данными из определения корпоративного приложения и выполняет проверку подлинности Windows.	Да
Учетные данные	Используется для веб-служб, которые используют обычную или дайджест проверку подлинности вместо проверки подлинности Windows. Для поддержания безопасности при проверке подлинности в режиме учетных данных настоятельно рекомендуется, чтобы канал передачи данных между каталогом бизнес-данных и внутренним сервером был защищен протоколом SSL или IPSec.	Да
RdbCredentials	Используется только для серверных баз данных. Каталог бизнес-данных использует учетные данные из определения корпоративного приложения для проверки подлинности.	Да

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

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

Выбранный режим проверки подлинности влияет на учетные записи и учетные данные, настроенные на внутреннем сервере, и настройки для единого входа. Свойства, которые необходимо настроить для XML-файла определения приложения, описаны далее, в разделе "Изменение и импорт XML-файла определения приложения" данного документа.

Дополнительные сведения о моделях и режимах проверки подлинности см. в Проверка подлинности каталога бизнес-данных (на английском языке) (https://go.microsoft.com/fwlink/?linkid=100498&clcid=0x419).

Настройка учетных записей для приложения

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

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

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

Включение и настройка службы единого входа

Если для каталога бизнес-данных выбран режим проверки подлинности, использующий единый вход, необходимо включить и настроить службу единого входа Microsoft (SSOSrv) на всех интерфейсных веб-серверах фермы. Кроме того, если используется поиск для каталога бизнес-данных, необходимо включить службу SSOrv на сервере индекса.

Учетной записью входа для службы должна быть:

Учетная запись пользователя домена. Она не может быть групповой.
Учетная запись фермы Office SharePoint Server.
Член локальной группы администраторов на сервере ключа шифрования (сервер ключа шифрования — это первый сервер, на котором запущена служба SSOSrv.)
Участник роли администраторов безопасности и роли db_creator на компьютере, на котором выполняется Microsoft SQL Server.
Либо та же учетная запись, что и учетная запись администратора единого входа, либо член учетной записи группы, которая является учетной записью администратора единого входа.

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

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

Учетная запись либо отдельного пользователя, либо глобальной группы Windows. Этой учетной записью не может быть учетная запись локальной группы домена или список рассылки.
Та же учетная запись, что и учетная запись службы единого входа, если указан пользователь. Если указана группа, то учетная запись службы единого входа должна входить в эту группу.
Та же учетная запись, что и учетная запись конфигурации для единого входа, если указан пользователь. Если указана группа, учетная запись конфигурации для единого входа должна входить в эту группу.
Участник группы администраторов фермы SharePoint.

Дополнительные сведения о включении и активации службы единого входа см. в Настройка и запуск службы единого входа Microsoft. Дополнительные сведения о настройке службы единого входа см. в Настройка единого входа (Office SharePoint Server).

Создание и настройка определений корпоративных приложений

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

Примечание

Определение корпоративного приложения для единого входа не то же самое, что XML-файл определения приложения, импортируемый в каталог бизнес-данных для каждого приложения или службы. Необходимо создать определение корпоративного приложения и отдельно сослаться на определение корпоративного приложения в XML-файле определения приложения.

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

Дополнительные сведения о создании определений корпоративных приложений см. в Создание определения корпоративного приложения для каталога бизнес-данных. Дополнительные сведения о настройке определений корпоративных приложений см. в Настройка определения корпоративного приложения для каталога бизнес-данных.

Изменение и импорт XML-файла определения приложения

После настройки единого входа и создания и настройки определений корпоративных приложений необходимо изменить определение приложения, чтобы включить режим проверки подлинности для приложения, реализацию для интерфейса ISsoProvider, используемого приложением и ИД корпоративного приложения для приложения. Эти свойства настраиваются в объекте LOBSystemInstance в XML-файле определения приложения.

Кроме того, можно изменить другие свойства для приложения. Таблицу, в которой приведен полный список свойств, доступных для настройки проверки подлинности баз данных и веб-служб, см. в LOBSystemInstance (на английском языке) (https://go.microsoft.com/fwlink/?linkid=124545&clcid=0x419) . Здесь также приведены примеры.

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

Дополнительные сведения о создании, изменении и импорте определений приложений для каталога бизнес-данных см. в Управление определениями приложений.

Общие задачи авторизации для XML-файлов определений приложений описаны в следующих подразделах:

Настройка проверки подлинности единого входа для базы данных
Настройка проверки подлинности единого входа для веб-службы
Настройка поставщика единого входа для приложения
Настройка проверки подлинности RevertToSelf
Настройка проверки подлинности в сквозном режиме
Настройка проверки подлинности на уровне приложений для приложения

Настройка проверки подлинности единого входа для базы данных

Чтобы использовать единый вход с системами баз данных, требуется выполнение следующих условий.

В качестве AuthenticationMode для объекта LOBSystemInstance задан WindowsCredentials или RdbCredentials.
Для SsoProviderImplementation задано полное имя интерфейса ISsoProvider.

Примечание

Если используется интерфейс стороннего ISsoProvider вместо интерфейса Office SharePoint Server ISsoProvider, тогда необходимо включить полное имя для этого поставщика.
Для SsoApplicationId задано значение ИД корпоративного приложения для приложения. При создании определения корпоративного приложения ему задано имя.

Настройка проверки подлинности единого входа для веб-службы

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

В качестве WebServiceAuthenticationMode для объекта LOBSystemInstance задан WindowsCredentials или Credentials.
Для SsoProviderImplementation задано полное имя интерфейса ISsoProvider.

Примечание

Если используется интерфейс стороннего ISsoProvider вместо интерфейса Office SharePoint Server ISsoProvider, тогда необходимо включить полное имя для этого поставщика.
Для WebServiceSsoApplicationId задано значение ИД корпоративного приложения для приложения.

Настройка поставщика единого входа для приложения

Бизнес-приложения, использующие единый вход для проверки подлинности пользователей, могут задавать такие свойство SsoProviderImplementation и интерфейс ISsoProvider, чтобы использовать любого стороннего поставщика единого входа. Чтобы использовать другого поставщика единого входа, а не поставщика единого входа Office SharePoint Server, необходимо настроить этого поставщика, а затем включить его полное имя в определение приложения для этого свойства. Дополнительные сведения см. в Участники ISsoProvider (на английском языке.) (https://go.microsoft.com/fwlink/?linkid=124546&clcid=0x419).

Настройка проверки подлинности RevertToSelf для приложения

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

Чтобы проверить подлинность базы данных задайте свойству AuthenticationMode объекта LOBSystemInstance значение RevertToSelf.
Чтобы проверить подлинность веб-службы задайте свойству WebServiceAuthenticationMode объекта LOBSystemInstance значение RevertToSelf.

Настройка проверки подлинности сквозного режима для приложения

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

Чтобы проверить подлинность базы данных задайте свойству AuthenticationMode объекта LOBSystemInstance значение PassThrough.
Чтобы проверить подлинность веб-службы задайте свойству WebServiceAuthenticationMode объекта LOBSystemInstance значение PassThrough.

Настройка проверки подлинности на уровне приложений для приложения

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

В свойстве SecondarySsoApplicationId объекта LobSystemInstance укажите приложение единого входа, которое содержит учетные данные.
Настройте свойства UsernameCredentialFilter и PasswordCredentialFilter и сопоставьте каждое с входным параметром.

Настройка анонимного доступа

Пакет обновления 1 (SP1) для серверов Microsoft Office 2007 добавляет новое свойство AllowAnonymousExecute для определения приложения, позволяющее выполнять анонимный доступ к бизнес-данным в веб-частях бизнес-данных. При установке для этого свойства значения true анонимный доступ включается. Ниже представлен XML-код свойства:

<Properties>

<Property Name="AllowAnonymousExecute" Type="System.Boolean">true</Property>

</Properties>

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

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

<MethodInstance Type="SpecificFinder" ReturnParameterName="ArtistRead" Name="ArtistRead">