Функции безопасности других продуктов Lotus

Использование прокси-серверов сторонней аутентификации

Вместо того чтобы применять средства аутентификации WebSphere Application Server, можно настроить сторонний сервер аутентификации (например, Policy Director WebSEAL). При использовании стороннего сервера аутентификации WebSphere Application Server обычно применяет модуль Trust Association Interceptor (TAI) для установления доверительных отношений с внешним прокси-сервером аутентификации и настройки контекста безопасности. Исключение составляет прокси-сервер сторонней аутентификации или сервер, настроенный на предоставление собственных токенов идентификации WebSphere Application Server, в частности LTPA-токенов. В настоящее время эта возможность реализована только в Policy Director WebSEAL.

Модуль Trust Association Interceptor представляет собой функцию WebSphere Application Server, активируемую через центр безопасности (Security Center) консоли администрирования WebSphere Application Server и настраиваемую через trustedservers. properties.

Когда запрос пытается получить доступ к защищенному ресурсу, WebSphere Application Server вызывает модуль TAI, у которого запрашивается подтверждение допустимости запроса, т. е. что запрос был получен через допустимый сторонний проксисервер аутентификации, и подтверждение того, что идентичность пользователя аутентифицирована. Модуль TAI должен возвращать либо отличительное имя (Distinguished Name, DN), либо короткое имя. Затем WebSphere Application Server выполняет просмотр в реестре для проверки отличительного имени или преобразования короткого имени в отличительное имя, прежде чем осуществлять поиск членства в группах для этого пользователя. Важно понимать, что просмотр отличительного имени должен пройти успешно, иначе WebSphere Application Server откажет в доверии идентификационным данным. Если просмотр реестра выполняется успешно, WebSphere Application Server генерирует для этого пользователя LTPA-токен и сохраняет его в виде cookie-файла для последующей аутентификации во время сеанса пользователя.

WebSphere Application Server упаковывает TAI для Tivoli Access Manager и Tivoli Policy Director. WebSphere Portal Server упаковывает TAI для SiteMinder, так что любой TAI может быть интегрирован как альтернативная служба аутентификации для Portal Server.

Модули TAI используются только в целях аутентификации. При таком сценарии прокси-сервер аутентификации определяет механизм запроса, а Portal Server применяет прокси-сервер аутентификации для передачи информации об успешной или неудачной проверке идентификатора пользователя через TAI или через LTPA-токен. С точки зрения WebSphere Application Server все запросы являются аутентифицированными, однако WebSphere Application Server и Portal Server все же выполняют просмотр пользователей и групп. Даже если аутентификация пользователя на прокси-сервере аутентификации прошла успешно, WebSphere Application Server и WebSphere Portal Server запретят доступ, если они не смогут получить успешный запрос учетных данных пользователя в реестре.

Также можно создать модули TAI, позволяющие другим собственным службам аутентификации взаимодействовать с WebSphere Application Server. Если вы решите использовать конфигурацию безопасности, отличную от SiteMinder или Tivoli Access Manager, вам необходимо будет предоставить и реализовать TAI для связи с проксисервером аутентификации.

Пользовательские хранилища и аутентификация

Сервер WebSphere Portal Server поддерживает либо внутреннюю базу данных Portal Server, либо LDAP-каталог, либо собственный реестр для использования в качестве реестра аутентификации (для хранения идентификаторов и паролей пользователей). WebSphere Application Server должен применять CustomRegistry для доступа к базе данных или собственному реестру. В LDAP или собственных конфигурациях реестра WebSphere Portal Server использует тот же реестр аутентификации, что и WebSphere Application Server, однако употребляет отдельную базу данных для пользовательских профилей и предпочтений.

Информация из пользовательского профиля и предпочтений называется информацией пользовательского хранилища в отличие от информации пользовательского реестра. Некоторая информация профиля может храниться в том же физическом хранилище, в котором хранится и пользовательский реестр. Например, LDAP-каталог может содержать множество информации о каждом пользователе, а не только имя пароля. Компонент Member Services продукта Portal Server, который обрабатывает такую информацию профиля, можно настроить на различные варианты размещения данных в пользовательском реестре и базе данных.

При входе пользователя WebSphere Application Server выполняет аутентификацию. Эту аутентификацию можно выполнить по внешнему пользовательскому реестру (например, по существующему LDAP-каталогу) или по пользовательскому реестру в Portal, поддерживаемому через WebSphere Portal Server, обеспечивающему функцию Customer User Registry (CUR). Однако компонент Member Services также выполняет проверку базы данных на участие в портале. Если пользователь не найден в реестре аутентификации, происходит отказ аутентификации. Если пользователь найден в реестре аутентификации, но не найден в базе данных участников, пользователю запрещается доступ к порталу. Для успешного входа пользователя на сервер WebSphere Portal Server оба просмотра должны пройти успешно.

Единая регистрация

Поддержка единой регистрации (single sign-on) в WebSphere Portal Server обеспечивает механизм, позволяющий портлету получить одно из нескольких представлений аутентифицированных идентификационных данных пользователя, которое портлет затем может передать в приложение заднего плана.

В этом случае WebSphere Portal Server и портлет выступают в роли прокси-серверов аутентификации для приложения заднего плана. Применяя единую регистрацию, пользователь может выполнить аутентификацию один раз при входе в WebSphere Portal Server, после чего идентификационные данные пользователя передаются в приложения, не требуя дополнительной проверки идентификационных данных для пользователя. WebSphere Portal Server поддерживает единую регистрацию через WebSphere Application Server, а также через другие прокси-серверы аутентификации, такие, как Tivoli Access Manager и SiteMinder. Также используются возможности единой регистрации между WebSphere Application Server и Domino.

Единая регистрация с использованием WebSphere Portal Server имеет два уровня. Первый уровень представлен службой Credential Service, которая инкапсулирует функции единой регистрации для создателя портлета в объекте, предоставляемом службой, и для которой существует образец кода, который позволяет сделать эти объекты легкими в употреблении и кодировании для создателя портлета. Второй уровень является более гибким, однако требует от создателей портлетов прямого использования функций единой регистрации WebSphere Portal Server и управления собственными подключениями и аутентификацией в приложениях заднего плана.

Функции единой регистрации Portal Server используют поднабор Java Authentication and Authorization Services (JAAS). Этот поднабор отвечает за аутентификацию. WebSphere Portal Server не поддерживает истинную авторизацию JAAS. WebSphere Portal Server создает контейнер JAAS Subject для каждого подключенного пользователя. JAAS Subject содержит компоненты Principal и Credential. Компонент Principal содержит такие данные, как идентификатор пользователя или DN пользователя, применяемые для идентификации пользователя. Компонент Credential содержит такие данные, как пароль или CORBA Credential, которые можно применять для аутентификации пользователя. JAAS Subject включает компоненты Principal и Credential, которые можно применять в портлете напрямую или через службу Credential Service.

Служба Credential Service

Объекты службы Credential Service предназначены для выполнения базовой аутентификации, аутентификации с применением LTPA-токенов и простых запросов идентификаторов и паролей пользователей на основе форм.

Получение учетных данных может осуществляться из компонента Principal контейнера JAAS Subject, из конфигурации портлета либо от службы хранилища учетных данных (credential vault service). Создатели портлетов могут применять службу Credential Service для получения учетных данных из хранилища учетных данных или из контейнера JAAS Subject. Объекты Credential Service также могут использоваться для передачи токенов единой регистрации Tivoli Access Manager или SiteMinder из контейнера JAAS Subject в приложение заднего плана в соответствующих заголовках.

Хранилище учетных данных

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

WebSphere Portal Server содержит одну простую реализацию хранилища на основе базы данных для постановки в соответствии секретам для других приложений предприятия. Хранилище по умолчанию (Default Vault) поставляется как предварительно сконфигурированное и содержит сегмент, управляемый администратором, и сегмент, управляемый пользователем. Хранилище, управляемое пользователем, дает возможность пользователям добавлять определения приложений, например почтовую учетную запись POP3, в пользовательское хранилище, а также сохранить постановку в соответствие. Хранилища, управляемые администратором, позволяют пользователям обновлять постановку в соответствие; однако пользователи не могут добавлять новые приложения в это хранилище. Хранилище по умолчанию загружает блок шифрования, который осуществляет кодирование паролей с использованием кодировки base64.

Можно подключать дополнительные хранилища, управляемые администратором, путем написания собственного адаптера хранилища (Vault Adapter) для определенного хранилища. Это осуществляется путем редактирования комментариев в следующем конфигурационном файле для указания реализаций адаптера хранилища (Vault Adapter Implementation):

was_root/lib/app/config/services/VaultServices.properties

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

WebSphere Portal Server также поддерживает хранение и извлечение учетных данных из других служб хранения, таких, как Tivoli Access Manager. Portal Server содержит подключаемый модуль адаптера хранилища для Tivoli Access Manager, который работает в AIX, Solaris и Windows. Сведения об установке подключаемого модуля см. в документации к соответствующему продукту. Дополнительные сведения о работе с хранилищами см. в справке для Credential Vault.

12.5.2 Авторизация

Администраторы настраивают доступ к ресурсам портала по всему порталу, назначая разрешения пользователям и группам с применением портлета Access Control List.

Авторизация осуществляется независимо от Application Server или другого специального прокси-сервера аутентификации. Application Server защищает сервлеты и компоненты EJB (Enterprise Java Beans). Однако WebSphere Portal Server защищает все внутренние ресурсы портала, в частности страницы, области и портлеты. Web- Sphere Portal Server также может при необходимости передавать управление ресурсами внешним механизмам безопасности.

WebSphere Portal Server выполняет собственную авторизацию, но может также интегрироваться с Tivoli Access Manager или SiteMinder для перевода ресурсов портала под управление внешних диспетчеров безопасности.

WebSphere Portal Server поддерживает тонкую настройку управления доступом к ресурсам. При настройке пользователи могут выбирать и просматривать только те ресурсы, к которым они имеют права доступа. При предоставлении ресурса инфраструктура проверяет наличие у пользователя требуемых прав для применения запрошенного ресурса. В большинстве случаев права доступа администрируются через портлет Access Control List и сохраняются в базе данных администрирования портала. Однако можно также настроить использование внешней службы безопасности, в частности Tivoli Access Manager или Netegrity SiteMinder, для защиты ресурсов.

Как говорилось выше, авторизация также называется управлением доступом (access control). Портлет Access Control List (ACL) позволяет настроить доступ к ресурсам портала путем назначения разрешений для пользователей и групп. Сведения об управлении пользователями и группами см. в документации к продукту WebSphere Portal Server. Портлет Access Control List также при необходимости передает управление ресурсами внешним механизмам безопасности.

Прежде чем можно будет выполнить авторизацию пользователя для доступа к ресурсу, необходимо успешно пройти аутентификацию. Во всем, кроме требования успешной аутентификации, авторизация является независимой от WebSphere Application Server или любого собственного прокси-сервера аутентификации. WebSphere Application Server защищает сервлеты и компоненты EJB. Однако WebSphere Portal Server защищает все внутренние ресурсы портала, в частности страницы, области и портлеты. Участие в группе может дать требуемое разрешение для доступа к объекту или выполнения запроса, однако управление доступом также может осуществляться для отдельных пользователей. Хотя WebSphere Portal Server не поддерживает роли J2EE, подобные функции могут иногда обеспечивать группы пользователей.

Портлет Access Control List

Портлет Access Control List является интерфейсом, позволяющим осуществлять управление правами доступа к ресурсам портала. Можно осуществлять поиск пользователя или группы по типу, имени или дате изменения ресурса или же вывести все ресурсы, доступные для пользователя или группы. Портлет Access Control List также позволяет переводить ресурсы под внешнее управление. Подробные инструкции по использованию этого портлета см. в документации к продукту WebSphere Portal Server и в справочных файлах.

Примечание. При назначении пользователю разрешения на развертывание портлетов убедитесь, что пользователь также указан в административной роли WebSphere Application Server Administrative Role. Можно добавить пользователя в группу, входящую в административную роль, или же добавить пользователя в эту роль через центр безопасности (Security Center) в консоли администрирования Application Server.

Права доступа

Существует пять простых разрешений, которые можно назначить для ресурсов. Одно из них, DELEGATE, представляет собой разрешение, позволяющее авторизованному пользователю изменять параметры управления доступом. Другими разрешениями являются: VIEW, EDIT, MANAGE и CREATE. Более полную информацию об этих разрешениях, а также примеры ограничения управления ресурсом при использовании каждого разрешения см. в документации по WebSphere Application Server. Ниже рассматриваются некоторые особенно важные вопросы прав доступа.

Разрешения DELEGATE

Разрешение DELEGATE необходимо для администратора или субадминистратора. Пользователь или группа пользователей с разрешением DELEGATE, установленным для ресурса (например, портлета или области), могут назначать пользователям разрешения для этого ресурса. Пользователи могут назначать для ресурса только разрешения такого же уровня ( VIEW, EDIT, MANAGE, CREATE ), который имеют сами, или более низкого уровня. Разрешение DELEGATE не предполагает наличия других прав доступа. Пользователи с разрешением DELEGATE не могут назначить более высокое разрешение, чем имеют сами. Например, если пользователь Sandy имеет разрешения EDIT и DELEGATE для страницы Financial и разрешение DELEGATE для группы, в которую входит пользователь Fred, пользователь Sandy может назначить пользователю Fred или любому другому пользователю из той же группы разрешения VIEW или EDIT для страницы Financial. Однако пользователь Sandy не может назначить разрешение MANAGE для этой страницы, так как он сам не имеет разрешения MANAGE для этой страницы.

Уровни доступа

Новые созданные ресурсы имеют особое начальное состояние управления доступом. Только пользователь, создавший ресурс, имеет разрешения для этого ресурса. Подобным же образом создатель всегда имеет разрешения MANAGE и DELEGATE для нового ресурса. Если создатель также имеет доступ к портлету Access Control List, этот пользователь может назначить другим пользователям доступ к этому портлету в пределах ограничений, описанных в предыдущем разделе. Администраторы портала также могут видеть новый ресурс и при необходимости назначить себе разрешения, которые позволят им совместно применять этот ресурс с другими пользователями. Пользователи должны иметь соответствующее активное или текущее минимальное разрешение для доступа к ресурсу. Активные разрешения могут быть унаследованы от групп, в которые входят пользователи или группа пользователей. Текущие минимальные разрешения назначаются пользователю по имени пользователя, а не по участию в группах.

Параметры управления начальным доступом

Портлет Access Control List определяет права доступа после запуска портала. Однако во время установки WebSphere Portal Server начальные права доступом назначаются для администратора портала и некоторых групп пользователей. Если при установке не было создано новое имя и пароль администратора портала, по умолчанию админстратором портала является wpsadmin в группе пользователей wpsadmins.

Если была выбрана стандартная установка, после чего была выполнена настройка параметров, то можно использовать другого пользователя вместо пользователя wpsadmin. Однако этот пользователь должен иметь пароль и существовать в LDAP до установки. Группу пользователей wpsadmins также можно заменить на другую группу, уже существующую в LDAP. Если принимается решение о замене администратора или группы администраторов, необходимо выбрать опцию стандартной установки, после чего выбрать настройку параметров LDAP и ввести требуемую информацию о пользователе и группе пользователей при запросе диспетчера установки. При первой инициализации базы данных администратору портала и группе администраторов назначается разрешение MANAGE PORTAL, которое дает этим пользователям полный контроль над порталом.

WebSphere Portal Server также настраивает разрешения, определенные в XML-файле конфигурации портала для начального применения портала. Администратор портала и группа администраторов должны иметь разрешения MANAGE и DELEGATE для всех сконфигурированных ресурсов портала. Разрешение VIEW устанавливается для всех аутентифицированных пользователей. Анонимные пользователи имеют разрешение VIEW для всех ресурсов, являющихся частью страницы приглашения. Можно изменять эти права доступа или назначать новые права доступа с использованием портлета Access Control List.

Примечание. По умолчанию администратор портала и группа администраторов не имеют разрешения MANAGE для пользователей или групп.

Субадминистраторы

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

Внешние диспетчеры безопасности

WebSphere Portal Server позволяет передавать управление доступом к экземплярам ресурсов, в частности к определенным портлетам, внешнему диспетчеру безопасности. В настоящее время WebSphere Portal Server поддерживает только два внешних диспетчера безопасности: Tivoli Access Manager и Netegrity SiteMinder.

По умолчанию после создания управление ресурсами портала осуществляется внутренними средствами WebSphere Portal Server. Например, при создании страницы изначально для создателя заданы разрешения MANAGE и DELEGATE во внутренней таблице базы данных ACL. Если сконфигурирован внешний диспетчер безопасности и создатель страницы имеет соответствующие разрешения, он может использовать портлет Access Control List для передачи управления этим ресурсом внешнему хранилищу безопасности. Разрешение обновления внешнего хранилища назначается внешним хранилищем путем постановки в соответствие определенному ресурсу, EXTERNAL_ACL, разрешениям MANAGE и DELEGATE. Объекты также можно перевести под внутреннее управление. Однако при этом все права доступа, назначенные внешним хранилищем, сбрасываются, после чего только пользователь, выполнивший перевод объектов, имеет разрешения MANAGE и DELEGATE.

После перевода объекта под управление внешнего диспетчера безопасности управление доступом для этого объекта администрируется только через интерфейс внешнего диспетчера безопасности. Портлет Access Control List больше нельзя использовать для администрирования безопасности объекта. Тем не менее портлет Access Control List может перевести объект обратно под внутреннее управление, если во внешнем диспетчере безопасности существуют корректные разрешения, в частности разрешения MANAGE и DELEGATE. Только портлет Access Control List может вернуть объект под внутреннее управление.

Кроме того, решение об использовании внешнего диспетчера безопасности необходимо принимать с пониманием того, что семантика ACL программного обеспечения внешнего диспетчера безопасности замещает обычную семантику портала. Например, при назначении анонимному пользователю разрешений через внешний портлет с использованием Tivoli Access Manager ACL для этого портлета должно включать неаутентифицированную группу пользователей Tivoli Access Manager.

Сведения о конфигурировании перевода ресурсов WebSphere Portal Server под внешнее управление см. в документации WebSphere Portal Server.

Сопоставление разрешений

При переводе объектов портала под внешнее управление они представляются в пространстве имен внешнего диспетчера безопасности. Осуществляется сопоставление разрешений в модели разрешений внешнего диспетчера безопасности. Дополнительные сведения о сопоставлении разрешений для TAM и SiteMinder см. в документации по WebSphere Portal Server.