IBM Workplace Managed Client (прежде IBM Workplace Client Technology, rich edition) предоставляет альтернативу выполнению Web-приложений IBM Workplace на сервере. Workplace Managed Client поддерживает выполнение приложений на стороне клиента, чтобы улучшить производительность и функциональность работы пользователя, а также его способность работать автономно.
Как следует из названия, одной из ключевых функциональных возможностей Workplace Managed Client является централизованное управление. Администратор может на очень детальном уровне управлять доступом ко всем приложениям с сервера. Пользователи клиентских приложений могут обращаться только к приложениям, которые им разрешено использовать. В этой статье мы рассмотрим теорию и практику управления доступом в Workplace Managed Client.
Предполагается, что читатели имеют опыт администрирования IBM WebSphere Portal, знакомы с XMLAccess и понимают основные концепции Workplace Managed Client.
IBM Workplace Managed Client Developer Toolkit
Перед началом работы потратим немного времени на рассмотрение IBM Workplace Managed Client Developer Toolkit. Это набор инструментальных программ, основанный на Eclipse, который поддерживает разработку приложений Workplace Managed Client. Он работает как с Eclipse, так и с IBM Rational Application Developer. Он значительно упрощает процесс создания приложений Workplace Managed Client. Вы можете протестировать и отладить ваше клиентское приложение локально, без сервера. Вы можете также сгенерировать "deploy set" ("набор для развертывания") так, чтобы избежать утомительной работы.
IBM Workplace Managed Client Developer Toolkit был разработан в IBM Dublin Software Lab. Мы используем данный набор инструментальных средств как стандартную среду разработки в этой статье.
Пример приложения Workplace Managed Client
Workplace Managed Client имеет очень детализированную систему управления доступом. Он может управлять доступом отдельного пользователя или группы пользователей к конкретной функции определенного приложения. Для продолжения работы вы должны быть знакомы с управлением доступом в IBM WebSphere Portal.
Теперь давайте рассмотрим пример из реального мира. Предположим, что у нас есть океанская система IBM Workplace Collaboration Services, используемая моряками повсеместно. Двумя обычными пользователями этой системы являются Silver Blade (член пользовательской группы Pirate) и Marco Polo (член пользовательской группы Adventurer). Оба сильно полагаются на Workplace Collaboration Services для достижения успеха в своей карьере. К сожалению, мобильные сети на их кораблях не очень хороши, и в результате они иногда видят ошибку Page Not Found (страница не найдена), пугающую каждого мореплавателя. Чтобы ее избежать, Marco и Silver решили установить Workplace Managed Client для использования их возможностей автономной работы. На рисунке 1 показан снимок экрана Workplace Managed Client пользователя Marco.
Рисунок 1. Workplace Managed Client пользователя Marco Polo
А на рисунке 2 показан Workplace Managed Client пользователя Silver Blade.
Рисунок 2. Workplace Managed Client пользователя Silver Blade
Вертикальная область в левой части интерфейса Managed Client представляет собой область переключения. Каждая пиктограмма в ней представляет приложение, работающее на Workplace Managed Client. Как вы можете видеть, Marco и Silver имеют доступ к Navigate, Logbook, Weather Forecast и Sea Battle. Мы также можем видеть на рисунке 1, что Marco имеет исключительный доступ к Adventure Club, тогда как на рисунке 2 показано, что Silver может использовать Pirate Club для контакта со своими друзьями-пиратами.
Их привилегии для использования приложений Workplace Managed Client определяются администратором, использующим управление доступом. Как ожидается, эти привилегии согласуются с привилегиями, используемыми ими при работе с браузерами для доступа к приложениям Workplace Collaboration Services на сервере Workplace Server. Это позволяет пользователям использовать точно такие же функции, которые они могут использовать через Web-браузер.
Обратите внимание на то, что на рисунках 1 и 2 и Marco, и Silver выбрали приложение Sea Battle. Однако интерфейс Marco для Sea Battle отличен от интерфейса Silver. Marco и Silver имеют функцию Battle Field Commands, но только Marco может использовать функцию Flee, и только Silver имеет функцию Rob (которая, по-видимому, является его любимой). Что интересно, эти отличия в коде не реализуются. Вместо этого они регулируются функцией управления доступом в Workplace Managed Client. Это означает, что разработчики должны заниматься только функциями приложений Workplace Managed Client и оставить контроль доступа администраторам. Администраторы могут затем решить, как предоставить доступ пользователя к приложению Workplace Managed Client. Они могут даже управлять доступом пользователя к субфункциям внутри приложения. И все это - не меняя ни единой строки кода! Данная функциональная возможность освобождает программиста от контроля защиты, улучшает возможность повторного использования и управляемость приложений Workplace Managed Client, делая их более подходящими для использования на крупных предприятиях.
В следующем разделе объясняется работа контроля доступа в Workplace Managed Client.
Контроль доступа в Workplace Managed Client
Workplace Managed Client реализует детализированный контроль доступа, используя механизм контроля доступа сервера IBM Workplace. Если говорить более конкретно, то Workplace Managed Client для управления своими приложениями использует настройки контроля доступа для страницы и портлетов на сервере Workplace.
Каждое приложение Workplace Managed Client представляет собой страницу на сервере Workplace, и схема приложения представляется как схема портлетов на странице. Каждый вид в приложениях Workplace Managed Client может отображаться в портлет на странице. Этот портлет должен обеспечивать такую же функциональность, что и вид. То есть, мы имеем приложение, которое работает и на сервере, и на клиенте.
В нашем примере Sea Battle мы использовали портлет "placeholder". Этот портлет устанавливается на сервере Workplace по умолчанию. Он только генерирует RCPML для Workplace Managed Client, поэтому наш клиент будет работать только в Managed Client. Однако этого должно быть достаточно, для того чтобы продемонстрировать, как работает управление доступом в Workplace Managed Client.
RCPML (Rich Client Platform Markup Language) - это XML-язык разметки, который описывает схему каждого приложения Workplace Managed Client. Workplace Managed Client использует RCPML-файл для создания своих приложений. RCPML, при необходимости, передается из сервера Workplace Collaboration Services.
На рисунке 3 показано, как страницы, составляющие наши приложения Workplace, отображаются в пользовательский интерфейс Workplace Managed Client пользователя Marco. Мы можем увидеть, что каждая страница представляет приложение в Workplace Managed Client, за исключением Pirate Club. Это приложение должно быть доступно только пользователю из группы Pirate Club. Marco не является членом такой группы, поэтому он не может видеть его в своем клиенте.
Рисунок 3. Отображение страницы пользовательского интерфейса (страница-UI) 
На рисунке 4 показано, как схема страницы приложения Sea Battle отображается в пользовательский интерфейс приложения Sea Battle (Silver).
Рисунок 4. Страница-UI отображение приложения Sea Battle 
Как вы можете заметить, каждый портлет на странице Sea Battle отображается в вид приложения, но второй портлет пропущен. Причиной этого является то, что пользователь должен быть членом Adventurer Club для использования функции Flee. Silver таким членом не является, поэтому не может использовать этот вид. Pirate Club и Adventurer Club - это две группы пользователей, которые мы должны создать для этого примера. Как вы можете увидеть, у нас есть также два пользователя: Silver_Blade, член Pirate Club, и Marco_Polo, член Adventurer Club.
Для объяснения того, как эти отображения связаны с контролем доступа в Workplace Managed Client, мы должны начать с процесса генерирования RCPML. Когда клиент соединяется с сервером, сервер формирует страницу и генерирует RCPML-файл из полученной страницы. Затем сервер передает RCPML клиенту, и клиент формирует приложение, следуя RCPML.
Ключ находится на первом шаге: когда сервер Workplace формирует страницу, он проверяет привилегии инициатора запроса. На получаемой странице могут находиться только те страницы и портлеты, к которым у инициатора запроса есть доступ. Получаемая страница является источником RCPML, поэтому привилегии клиента определяют, что будет в RCPML. Следовательно, они определяют, какое приложение или функция доступны. Управляя доступом клиента к предоставляемой странице и портлетам на странице, администраторы могут получить полный контроль над приложениями Workplace Managed Client и их функциями.
Теперь, когда мы знаем теорию, перейдем к практике. Мы настроим приложение Sea Battle в пошаговом режиме. Прежде всего, мы должны установить пример приложения.
Установка примера приложения
Мы будем устанавливать пример приложения Sea Battle. Он содержит древовидные виды и несколько кнопок на каждом из них. Вы можете использовать IBM Workplace Managed Client Developer Toolkit для их создания, не написав ни единой строки кода. Вы можете также использовать этот набор инструментальных средств, чтобы сгенерировать набор для развертывания, содержащий все необходимые файлы для развертывания приложения на сервере. Вы удивитесь, насколько легко можно создать и развернуть приложение Workplace Managed Client при помощи этого фантастического набора инструментальных средств. Конечно, всегда существует лучший способ. В нашем случае намного более простым способом является загрузка набора для развертывания. Для загрузки набора для развертывания обратитесь к разделу Загрузка, расположенному в конце данной статьи.
Следуя приведенным в файле инструкциям, развернуть пример приложения не трудно.
После успешного развертывания вы готовы идти дальше. Используя для запуска клиента учетную запись администратора, вы должны увидеть выполнение приложения Sea Battle с тремя видами. Однако если вы используете учетную запись, отличную от администраторской, вы увидите только пиктограмму Sea Battle в области переключения. Но если вы нажмете на эту пиктограмму, приложение не запустится правильно. Не беспокойтесь, это не ваша вина!
Проблема с учетной записью, отличной от администраторской, состоит в контроле доступа. Новая сгенерированная страница доступна по умолчанию для всех аутентифицированных пользователей портала. Но портлеты-заполнители на этой странице по умолчанию доступны только для группы пользователей wpsadmins. Это означает, что они могут использовать приложение без каких-либо проблем, поскольку администратор может получить все RCPML-файлы. Т.к. портлеты, генерирующие RCPML для схемы страницы, отсутствуют, пользователи не администраторы могут видеть только пиктограмму в области переключения, а приложение работать не будет. Для решения проблемы вы должны предоставить пользователю доступ к портлетам-заполнителям на сгенерированной странице.
В следующем разделе мы исправим эту проблему и настроим пример приложения в пошаговом режиме.
Установка контроля доступа для приложения Workplace Managed Client
В предыдущем разделе мы развернули Sea Battle на сервере. Теперь мы установим контроль доступа для этого примера, для того чтобы он работал так, как описано в предыдущем разделе "Контроль доступа в Workplace Managed Client".
Зарегистрируйтесь на сервере Workplace в вашем Web-браузере, используя учетную запись администратора, и найдите портлеты, чьи названия начинаются с "sea_battle". Вы должны найти три портлета: sea_battle.AdventurerView, sea_battle.CommonView и sea_battle.PirateView (см. рисунок 5).
Рисунок 5. Портлеты Sea Battle 
Первый портлет отображается в вид Flee. Путешественники (adventurer) должны спасаться бегством (flee) в определенных обстоятельствах, поэтому добавьте Adventurer Club в роль User. Это означает, что Marco может увидеть вид Flee в своем приложении Sea Battle, в то время как Silver не может. Мы можем также достичь этого, добавив пользователя Marco_Polo в роль user. Но в этом случае, если у вас есть другие путешественники, которые тоже должны использовать эту функцию, вам нужно добавлять их в роль user по одному. Рекомендуется использовать группу пользователей для управления доступом к приложениям Workplace Managed Client.
Второй портлет представляет вид Battle Fields Commands. И пираты, и путешественники могут его использовать, поэтому мы должны добавить группы пользователей Pirate Club и Adventurer Club в роль User. Это позволит всем пользователям этой группы использовать функции этого вида. Обратите внимание на то, что члены различных ролей имеют различные уровни доступа к ресурсам. В нашем примере, это не имеет никакого значения, поэтому мы используем роль user.
Последний портлет отображается в вид Rob. Мы должны добавить Pirates Club в его роль user на той же основе.
Теперь приложение Sea Battle должно работать нормально с пользователями Macro_Polo и Silver_Blade. Но есть еще одна вещь, которую мы должны сделать. Предоставляемая для приложения страница доступна для всех аутентифицированных пользователей портала. Вы можете найти страницу в WorkplaceRCPPages; она имеет заголовок, аналогичный "sea_batttle", и уникальное имя, начинающееся с "com.ibm.page…". Она по умолчанию наследует настройки доступа от ее родительской страницы. Это означает, что все аутентифицированные пользователи будут видеть пиктограмму для Sea Battle в их области переключения, но только пользователи из групп Adventurer Club и Pirate Club могут использовать их корректно. Мы хотим показывать пиктограмму только тем пользователям, которые могут использовать приложение. Поэтому нам нужно запретить наследование установок доступа родительской страницы данной страницей. Либо мы можем запретить распространения настроек доступа родительской страницы. Таким образом, последующие страницы-наследники больше не будут наследовать настройки доступа. Наконец, мы добавляем Adventurer Club и Pirates Club в роль user страницы. Это позволит только пиратам и путешественникам видеть пиктограммы и использовать это приложение.
Вы можете выполнить все эти настройки и через ваш Web-браузер. Но мы рассматриваем управление приложениями Workplace Managed Client, поэтому не будем углубляться в детали, как это сделать. Интерфейс Web-браузера довольно дружественен и интуитивен. Однако если вы столкнулись с какими-либо проблемами, проверьте, правильно ли развернуто приложение на сервере при помощи Workplace Managed Client.
Мы можем также использовать XMLAccess-возможности в IBM WebSphere Portal с целью настройки контроля доступа для приложений Workplace Managed Client. Мы предоставим некоторые XMLAccess-сценарии, вместе с небольшими объяснениями, в следующем разделе.
Использование XMLAccess для настройки контроля доступа
Возможно, вы заметили, насколько удобно использовать XMLAccess для работы с сервером Workplace, когда мы устанавливали пример приложения. Хорошей новостью является то, что мы тоже можем использовать XMLAccess при настройке параметров доступа для приложений Workplace Managed Client.
Перед началом работы загрузите два сценария (addUser.xml и delUser.xml), ссылки на которые приведены в разделе Download в конце статьи, для создания и удаления двух групп пользователей и двух пользователей, с которыми мы будем работать. Обратите внимание на то, что пароль записан в обычном текстовом виде; всегда хорошей практикой является изменение пароля после создания пользователя с использованием XMLAccess.
Далее приведен сценарий, который правильно настроит наш пример приложения Workplace Managed Client после развертывания. В нем предполагается, что мы используем портлет-заполнитель по умолчанию, и что уникальные имена для страницы и имена для портлетов не были изменены:
xml version = "1.0" encoding = "UTF-8" ?> < request xmlns:xsi = " http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation= "PortalConfig_1.2.xsd" type = "update" > < portal action = "locate" > < web-app action = "locate" uid = "com.ibm.rcp.PlaceHolderPortlet.f04cbd43761200181a76918a71b1e264" > < portlet-app action = "locate" name = " sea_battle.pane1.views.Pane1View " > < portlet action = "update" active = "true" name = " sea_battle.pane1.views.Pane1View.1 " > < access-control > < role actionset = "User" update = "set" > < mapping subjectid = " Adventurer Club " subjecttype = "USER_GROUP" update = "set" /> < mapping subjectid = " Pirate Club " subjecttype = "USER_GROUP" update = "set" /> role > access-control > portlet > portlet-app > < portlet-app action = "locate" name = " sea_battle.pane2.views.Pane2View " > < portlet action = "update" active = "true" name = " sea_battle.pane2.views.Pane2View.1 " > < access-control > < role actionset = "User" update = "set" > < mapping subjectid = " Adventurer Club " subjecttype = "USER_GROUP" update = "set" /> role > access-control > portlet > portlet-app > < portlet-app action = "locate" name = " sea_battle.pane3.views.Pane3View " > < portlet action = "update" active = "true" name = " sea_battle.pane3.views.Pane3View.1 " > < access-control > < role actionset = "User" update = "set" > < mapping subjectid = " Pirate Club " subjecttype = "USER_GROUP" update = "set" /> role > access-control > portlet > portlet-app > web-app > < content-node action = "update" uniquename = " com.ibm.page.6c6359e0c3c53dd830b930b9105395878888000 " > < access-control > < role-block type = "inheritance" actionset = "Editor" /> < role actionset = "User" update = "set" > < mapping subjectid = " Pirate Club " subjecttype = "USER_GROUP" update = "set" /> < mapping subjectid = " Adventurer Club " subjecttype = "USER_GROUP" update = "set" /> role > access-control > content-node > portal > request > |
Если вы использовали XMLAccess ранее, то найдете этот сценарий довольно понятным. В нем присутствуют три элемента; они отображаются на три портлета-заполнителя. Портлеты идентифицируются по их именам. Вы можете найти их имена в сценарии развертывания, который использовали для развертывания приложения; они начинаются с имени вашего приложения. Каждый элемент определяет список членов роли. Каждый элемент удаляет или добавляет пользователя в список. Атрибут subjectid является именем пользователя или именем группы пользователей. subjecttype - может быть USER или USER_GROUP; атрибут update установлен в "set", если вы хотите добавить или удалить пользователя из списка. Вы можете иметь столько элементов, сколько пожелаете.
Мы настраиваем страницу в элементе. Страница идентифицируется по уникальному имени. Также можно найти уникальное имя в сценарии развертывания. Как уже упоминалось, по умолчанию страница наследует контроль доступа, поэтому нам нужно сначала запретить наследование. Затем мы добавляем Pirate Club и Adventurer Club в роль user, как прежде.
Одним предложением: сценарий просто находит портлеты и страницы, а затем обновляет контроль доступа. Вы можете использовать этот сценарий как шаблон для создания вашего собственного. Вам просто нужно изменить атрибуты, выделенные жирным шрифтом, настроив их под ваши требования.
Заключение
В данной статье мы рассмотрели преимущества системы контроля доступа Workplace Managed Client. Мы объяснили, как она работает, используя механизм контроля доступа сервера Workplace Collaboration Services, и рассказали, как настроить контроль доступа для приложений Workplace Managed Client. Теперь вы можете оценить значение набора инструментальных средств Workplace Managed Client!