Герасимов В.В. Технологии построения интеренет-порталов
Подождите немного. Документ загружается.
Рабочая версия документа. Не для публикации.
121
Реестр в виде базы данных
Реестр в виде базы данных обычно поддерживается портальны-
ми платформами по умолчанию. Формат базы данных является спе-
цифическим для каждой портальной платформы. Преимуществом та-
кого подхода является высокая скорость доступа к каталогу, т.к. пор-
тал обращается напрямую к базе данных. Кроме того, это упрощает
установку портала на начальном этапе, т.к. нет необходимости уста-
навливать и настраивать сервер LDAP.
Очевидным недостатком данного подхода является то, что фор-
мат базы данных различен для разных платформ. При этом, зачастую
отсутствует описание данного формата в документации. Т.о. для рабо-
ты с каталогом пользователей приходится пользоваться стандартными
средствами, встроенными в портальную платформу. Соответственно,
невозможна или затруднена интеграция существующих баз данных с
информацией о пользователях портала (например, базы данных по со-
трудникам организации).
Реестр в виде каталога LDAP
Протокол LDAP является стандартом де-факто для работы с ка-
талогами пользователей. Существует множество серверов, поддержи-
вающих данный протокол, например IBM Directory Server, Lotus Dom-
ino, Microsoft Active Directory, Sun One Directory Server, Novell eDirec-
tory.
LDAP-каталог позволяет хранить реестр пользователей и групп,
а также профили пользователей. При этом набор атрибутов пользова-
телей можно произвольно изменять, что позволяет подстраивать про-
фили пользователей под требования заказчиков.
Преимуществом каталога LDAP является использование стан-
дартного протокола для обращения к базе данных пользователей, что
позволяет управлять данным каталогом любыми стандартными сред-
ствами, а также относительно легко интегрировать существующие ба-
зы данных этот каталог.
Недостатком является дополнительная нагрузка на сервер пор-
тала в виде отдельной базы данных и самого сервера LDAP. Также,
учитывая некоторую ограниченность протокола LDAP по сравнению с
SQL, некоторые сложные запросы к каталогу пользователей прихо-
дится выполнять в несколько этапов, что дополнительно снижает про-
изводительность.
Рабочая версия документа. Не для публикации.
122
Интеграция реестров пользователей
Часто, при внедрении портального решения на предприятии,
требуется интеграция существующих каталогов LDAP и баз данных
пользователей в единый реестр пользователей. Для этого существуют
соответствующие программные решения. В качестве примера рас-
смотрим IBM Tivoli Directory Integrator [7].
IBM Tivoli Directory Integrator синхронизирует идентификаци-
онные данные, расположенные в каталогах, базах данных, системах
совместной работы и других приложениях предприятия. IBM Tivoli
Directory Integrator, выполняя роль гибкого промежуточного уровня
синхронизации между структурой идентификационных данных ком-
пании и источниками этих данных в приложениях, позволяет отка-
заться от необходимости создания центрального хранилища данных.
Программа Tivoli Directory Integrator может отслеживать раз-
личные источники данных, в том числе серверы LDAP различных
фирм и базы данных с практически любой схемой. Используя настро-
енные «сборочные линии», Directory Integrator совмещает информа-
цию из этих источников данных на одном сервере вывода, который
может применяться в качестве сервера LDAP. Принцип работы функ-
ции Tivoli Directory Integrator изображен на следующем рисунке.
Рабочая версия документа. Не для публикации.
123
Рис. 6.3. Схема использования Tivoli Directory Integrator
Таким образом, IBM Tivoli Directory Integrator создает каталог,
который служит «теневой копией» данных из различных источников.
Если сборочные линии IBM Tivoli Directory Integrator правильно на-
строены, IBM Tivoli Directory Integrator может отслеживать источник
данных и отражать вносимые в него изменения практически в режиме
реального времени.
6.5. Организация доступа к ресурсам
Аутентифицированный пользователь может быть авторизован
для доступа к тому или иному ресурсу портала. Заметим, что пользо-
ватель, не прошедший аутентификацию, также может быть аутенти-
фицирован - как анонимный пользователь (гость).
Существует множество вариантов организации прав доступа к
ресурсам. Как правило, при построении портала выбирается вариант,
наиболее подходящий по техническому заданию. Если программная
платформа портала разрабатывается «с нуля», то организация прав
доступа может быть реализована в полном соответствии с требова-
ниями ТЗ. Однако, при использовании существующей платформы ча-
ще всего предлагается уже готовое решение по организации доступа.
Рабочая версия документа. Не для публикации.
124
Далее будет рассмотрено несколько вариантов организации дос-
тупа к ресурсам портала, в том числе на примере платформ WebSphere
Portal и SharePoint Portal.
Простейший пример распределения прав доступа
Рассмотрим простейший пример организации доступа на пор-
тал. Допустим, определенный уровень доступа предоставляется поль-
зователю сразу для всех ресурсов портала. Разделим всех пользовате-
лей на 4 категории:
Анонимный пользователь имеет доступ на чтение информа-
ции, размещенной на портале.
Зарегистрированный пользователь имеет возможность участ-
вовать в форумах, размещать свои личные данные, настраивать пер-
сональную страницу и т.д.
Редактор портала является зарегистрированным пользовате-
лем, имеющим возможность публиковать информацию на портале.
Администратор имеет доступ ко всем настройкам портала, в
том числе, может назначать редакторов.
Очевидными достоинствами данной модели являются простота
реализации и управления. Недостатки – невозможность назначать
права доступа на отдельные ресурсы и недостаточное количество
уровней иерархии, что не позволяет, в отдельных случаях, эффектив-
но распределять обязанности по работе с порталом.
Усложним модель. Пусть уровень доступа определяется для ка-
ждого ресурса портала. При этом количество уровней доступа можно
расширить (нет доступа; читатель; редактор; менеджер; администра-
тор и т.д.). Если количество ресурсов небольшое, или они объединены
в группы (форумы, новости, веб-контент и т.д.), уровни доступа мож-
но хранить в виде таблицы:
Таблица 6.1
Пример простого распределения прав доступа
Ресурс 1 Ресурс 2 Ресурс 3
Пользователь
1
Редактор Читатель Администратор
Пользователь
Читатель Администратор
нет доступа
Рабочая версия документа. Не для публикации.
125
2
Пользователь
3
Администратор
Администратор
Читатель
Достоинства – произвольное количество уровней доступа, про-
стота реализации, высокая скорость доступа. Недостатки – сложность
администрирования при большом количестве пользователей и ресур-
сов.
При разработке портальной платформы следует учитывать пер-
спективы развития портала. Если предполагается расширение портала,
увеличение количества пользователей, рекомендуется выбрать одну
из схем, предоставляемых промышленными портальными платфор-
мами. Далее будет рассмотрена организация прав доступа в порталь-
ных платформах WebSphere Portal и SharePoint Portal.
Организация прав доступа в WebSphere Portal
В WebSphere Portal используется сложная модель распределения
прав доступа, которую можно использовать при реализации порталов
любого масштаба.
Пользователи и группы
Все пользователи портала могут принадлежать одной или не-
скольким группам. В группу пользователей могут входить другие
группы, т.е. поддерживаются вложенные группы. Все члены вложен-
ной группы считаются членами родительской группы и обладают со-
ответствующими правами.
Виртуальные пользователи и группы
В портале также предусмотрен ряд заранее определенных вир-
туальных пользователей и групп:
• Пользователь «Анонимный пользователь портала»
• Группа «Все идентифицированные пользователи портала»
• Группа «Все группы пользователей портала»
Они позволяют задать параметры управления доступом для аб-
страктных наборов пользователей. Виртуальные пользователи и груп-
пы отсутствуют в реестре пользователей. Они существуют только в
контексте управления доступом. Атрибуты виртуальных пользовате-
лей и групп, такие как родительская группа, изменять нельзя.
Рабочая версия документа. Не для публикации.
126
Анонимный пользователь олицетворяет пользователя портала,
который еще не вошел в систему (не был аутентифицирован). При-
своение прав доступа этому пользователю для ресурса позволяет пре-
доставить доступ к этому ресурсу всем пользователям, не авторизо-
ванным на портале. Этот пользователь может применяться при публи-
кации общих страниц портала, доступных всем пользователям. Ано-
нимный пользователь не входит ни в одну группу пользователей пор-
тала, однако он наследует права доступа, назначенные виртуальному
ресурсу «Пользователи».
В виртуальную группу «Все идентифицированные пользова-
тели портала» входят все пользователи, зарегистрированные в реест-
ре пользователей портала. После успешного входа в систему портала
пользователь портала перестает быть анонимным и становится аутен-
тифицированным. Такие пользователи считаются членами виртуаль-
ной группы пользователей «Все идентифицированные пользователи».
Роли, назначенные этой группе пользователей, определяют права дос-
тупа, которые должны быть предоставлены всем идентифицирован-
ным пользователям. Другими словами, они позволяют настроить на
портале права доступа по умолчанию для пользователей, прошедших
аутентификацию.
В виртуальную группу «Все группы пользователей» входят
все не виртуальные группы пользователей портала. Т.о. любой поль-
зователь портала, входящий в любую группу портала, будет принад-
лежать группе «Все группы пользователей». Однако если пользова-
тель не входит ни в одну группу, то он не входит и в группу «Все
группы пользователей».
Аутентификация пользователей
Аутентификация пользователей производится с помощью
HTML-формы. По умолчанию WebSphere Portal применяет средства
идентификации WebSphere Application Server. Однако при необходи-
мости можно настроить внешний администратор защиты, например
Tivoli Access Manager, который будет выполнять аутентификацию
пользователей для WebSphere Portal.
Роли
Для управления доступом в WebSphere Portal версии 5.0 и выше
применяются роли. Роль предоставляет фиксированный набор прав
доступа к определенному ресурсу WebSphere Portal. Такой набор прав
доступа называется типом роли. Таким образом, в WebSphere Portal
имеется возможность назначить права доступа любого пользователя
или группы пользователей к любому ресурсу или группе ресурсов.
Рабочая версия документа. Не для публикации.
127
Далее будем обозначать роль как Тип_роли@Ресурс. Напри-
мер, роль редактора страницы «Новости рынка» записывается как
«Редактор@Страница_Новости_рынка».
В роли Администратор@Портал всегда должен быть по крайней
мере один пользователь. Если в этой роли нет ни одного пользователя,
то работа с порталом будет невозможна.
Типы ролей WebSphere Portal описаны в следующей таблице.
Таблица 6.2
Типы ролей пользователей в WebSphere Portal
Тип роли Права доступа
Администратор
(Administrator)
Неограниченные права доступа к ресурсам.
В том числе, возможность создания, настройки
и удаления ресурсов. Кроме того, администра-
торам разрешено изменять параметры управ-
ления доступом.
Администратор за-
щиты (Security
Administrator)
Назначение ролей для ресурсов.
Администратор защиты может назначать роли
субъектов (пользователей и групп) для ресур-
сов портала. При этом администратор защиты
должен иметь роль «Распределитель ролей»
для назначаемых субъектов. Кроме того, адми-
нистратор защиты должен обладать той ролью
для ресурса, которую он назначает пользовате-
лю.
Например, для назначения роли ресурса субъ-
екту, у администратора защиты должны быть
роли:
Администратор_защиты@Ресурс +
Распределитель_Ролей@Субъект +
Тип_роли@Ресурс.
Роль «Администратор защиты» для ресурса не
дает прямого доступа к нему.
Распределитель ро-
лей (Delegator)
Для назначения роли субъекту портала, у ад-
министратора защиты должна быть роль «Рас-
пределитель ролей» для этого субъекта (см.
Рабочая версия документа. Не для публикации.
128
роль «Администратор защиты»).
Указание роли распределителя ролей для ре-
сурсов, не являющихся пользователями или
группами, не имеет практической ценности.
Роль «Распределитель ролей» для ресурса не
дает прямого доступа к нему.
Менеджер (Manager) Создание новых ресурсов, конфигурирование и
удаление существующих ресурсов, которые
используется другими пользователями.
Редактор (Editor) Аналогично менеджеру, но без возможности
удаления ресурсов.
Привилегированный
пользователь
(Privileged user)
Просмотр информационного наполнения пор-
тала, настройка портлетов и страниц, создание
новых личных страниц.
Пользователь (User) Просмотр информационного наполнения пор-
тала, например просмотр заданной страницы.
Роль не назначена Пользователь не может взаимодействовать с
ресурсом.
Роли назначаются пользователям и группам, указанным в реест-
ре пользователей. Существует три способа назначения ролей:
– Явное назначение администратором (или пользователем с
соответствующими правами доступа).
– Неявное назначение ролей при добавлении пользователя или
группы в другую группу. Если группе назначена какая-либо
роль, то все члены этой группы автоматически получают эту
роль. Вложенные группы (группы, которые являются членом
другой группы) наследуют роли родительской группы.
– Наследование роли, предоставленной по отношению к роди-
тельскому ресурсу. Роль, связанная с ресурсом, по умолча-
нию относится и ко всем дочерним ресурсам. Например, если
пользователь является привилегированным пользователем
для страницы, он по умолчанию будет являться привилеги-
рованным пользователем и для всех ее дочерних страниц.
Пользователю или группе можно назначить несколько ролей,
связанных с одним ресурсом. Например, пользователь может выпол-
нять как роль редактора страницы, так и роль менеджера этой страни-
Рабочая версия документа. Не для публикации.
129
цы. Одна из этих ролей может быть унаследована по иерархии ресур-
сов, а вторая может быть явно назначена администратором портала.
Роли рекомендуется назначать группам пользователей. Отдель-
ным пользователям роли следует назначать только в исключительных
случаях. Распределение ролей на уровне групп уменьшает количество
операций по преобразованию ролей и упрощает администрирование.
Иерархия ролей
Перечисленные выше роли выстроены в иерархию, показанную
на следующем рисунке. Права доступа, предоставляемые определен-
ной ролью, включают права доступа, определенные в роли, располо-
женной ниже по иерархии. Например, привилегированные пользова-
тели и редакторы могут выполнять все действия, которые разрешено
выполнять обычным пользователям. Менеджеры могут выполнять все
действия, которые разрешено выполнять редакторам и пользователям,
но не привилегированным пользователям.
Рис. 6.4. Иерархия ролей в WebSphere Portal
Наследование ролей
Ресурсы WebSphere Portal являются частью иерархической
структуры. По умолчанию любой ресурс иерархии наследует роли,
связанные с родительским ресурсом. Автоматическое наследование
позволяет сократить объем работы администратора. Когда админист-
Рабочая версия документа. Не для публикации.
130
ратор назначает группе роль для родительского ресурса, она по умол-
чанию наследуется для дочерних ресурсов.
Для разделения доступа, наследование по структуре ресурсов
можно заблокировать на любом уровне.
Рис. 6.5. Пример блокирования роли пользователя для ресурса
При передаче ресурсов под внешнее управление доступом (с
помощью внешнего администратора защиты), изменяется порядок на-
следования. Если ресурс переведен под внешнее управление, а его ро-
дительские ресурсы остались под внутренним управлением, то такой
ресурс больше не будет наследовать назначение ролей своих роди-
тельских ресурсов. Ресурсы, находящиеся под внешним управлением
доступом, могут обрабатывать только следующие операции:
– Наследовать назначение ролей от других ресурсов с внешним
управлением.
– Передавать назначение ролей другим ресурсам с внешним
управлением.
Ресурсы, находящиеся под внутренним управлением, не могут
наследовать назначение ролей от ресурсов под внешним управлением
или передавать назначение ролей таким ресурсам.
Блокирование ролей
Блокирование ролей запрещает наследование роли по иерархии
ресурсов. Существует два типа блокировок: