IDM Role-based Provisioning (RBP): кто-нибудь пользуется?

[Константин Ошмян]

Хотелось бы услышать, пользуется ли вообще кто-нибудь указанным продуктом. Раньше (в IDM 3.6) это был отдельный продукт, который ставился как дополнение. Сейчас (IDM 4) это часть, входящая в состав Advanced Edition.

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

[Константин Ошмян]

Так что - "совсем-совсем никого?" Или я просто слишком неконкретный вопрос задал, чтобы на него отвечать? Могу более конкретных вопросов накидать.

[Андрей Троценко]

...Могу более конкретных вопросов накидать.

Не обещаю, что отвечу, но, накидать бы надо...

[Константин Ошмян]

Спасибо. Тогда попробую начать Сразу оговорюсь, что пробовал я ставить на стенде версию IDM 4.0 Advanced Edition (после этого вышла версия 4.0.1, может, в ней что-то поменялось), а в качестве внешней системы использовалось своё приложение с SQL-базой и доступом к нему через JDBC-драйвер.

Насколько я понял из документации, очень важным является понятие Entitlement (как бы это по-русски-то грамотно сказать? У них самих переведено как "наделение правами" - мне не нравится: длинно и не отражает суть. Ладно, будем пока что пользоваться английским словом, как термином). Документация настоятельно рекомендует пользоваться этими Entitlement-ами при обработке всяческих заявок. Фактически, Entitlement - это объект в Vault-е, представляющий некий ресурс во внешней системе. Этот объект имеет свои имя/описание (Name, DisplayName, Description), а, кроме того, может иметь набор возможных значений (как частный случай - информацию о том, как этот набор значений вытянуть из внешней системы). Результатом успешной обработки заявки является назначение пользователю некоего Entitlement-а с конкретным значением (атрибут DirXML-EntitlementRef). Причём Entitlement-ы можно привязывать либо непосредственно к объекту "роль" (прежний подход, сейчас не рекомендуется), либо к объекту "ресурс", который уже затем соединять с ролью (текущий подход). А дальше уже драйвер (коннектор) к конкретной внешней системе видит изменения этих Entitlement-ов (назначение/отмену/модификацию) и преобразует их в соответствующие изменения прав во внешней системе.

С учётом гибкости настроек workflow и многоязычного интерфейса портала (UI) получается очень привлекательно.

Теперь, собственно, о граблях, на которые успел наступить.

1. Привязать Entitlement к ресурсу можно только через портал (ни iManager, ни Designer этого не позволяют). Однако, после создания Entitlement-а (создаётся он внутри драйвера к внешней системе) портал его не видит и выдаёт лишь невразумительное сообщение о том, что, дескать, у вас нет драйверов, на которых скофигурированы Entitlement-ы для маппинга ресурсов, и идите вы... читать документацию. Причём конкретной ссылки на документацию не указано, а я в доке нашёл на эту тему лишь следующий абзац:

NOTE: If you have not configured the DirXML-Resource correctly, when you access the Browse Entitlements page to select an Entitlement, you will see a message indicating that you have not configured your entitlements for resource mapping.

В общем, что хочешь, то и думай. Погуглив, нашёл через форум вот эту ссылку, которая, действительно, помогла. Но, блин, где об этом написано в документации??

2. Создали ресурс, привязали к нему Entitlement, пробуем сделать заявку на ресурс. Проверяем: действительно, при назначении пользователю ресурса ему выставляется и правильный Entitlement (т.е. атрибут DirXML-EntitlementRef). При отзыве ресурса - атрибут DirXML-EntitlementRef убирается. Красиво. Делаем следующий шаг: добавляем ресурс к роли, и делаем заявку на назначение роли (а не ресурса). На первый взгляд, всё красиво: роль назначаем - атрибут DirXML-EntitlementRef появляется (вместе с атрибутами о том, что назначена роль и соответствующий ей ресурс). Однако, при отзыве роли процедура отрабатывает лишь частично: ссылки на роль и на ресурс у пользователя отбираются, а вот Entitlement (атрибут DirXML-EntitlementRef) остаётся! То же самое происходит и в случае, если пытаться использовать "старый" подход (привязывать Entitlement сразу к роли). Почему? Это что, явный баг, или я чего-то не учёл?

3. При редактировании объекта "ресурс" (что через портал, что через дизайнер) можно указать два workflow: которые будут отрабатывать при назначении ресурса и при его отзыве. При редактировании же роли доступен лишь один workflow - на назначение роли. А как сделать workflow, который будет работать при отзыве роли? Или это невозможно?

4. Система поддерживает локализацию на разные языки. Однако, мне так и не удалось корректно локализовать на русский язык Entitlement-ы (там можно перевести как DisplayName, так и сами значения). Отображается всегда одинаково: квадратиками. В других местах (свойства пользователей, ролей, ресурсов) локализация работает корректно. Тоже похоже на явный баг.

5. Так и не понял, каким образом из внешней системы вытягивается список возможных значений Entitlement-а. В настройках задаются параметры в формате LDAP-запроса. Но неясно, что указывать в случае, когда внешняя система - простая SQL-база. Или надо ресурсы внешней системы, представляемые Entitlement-ами, обязательно затягивать внутрь IDM-а (например, реплицируя их на какие-то custom-классы в Vault-е)?

[Андрей Троценко]

...
2. Создали ресурс, привязали к нему Entitlement, пробуем сделать заявку на ресурс. Проверяем: действительно, при назначении пользователю ресурса ему выставляется и правильный Entitlement (т.е. атрибут DirXML-EntitlementRef). При отзыве ресурса - атрибут DirXML-EntitlementRef убирается. Красиво. Делаем следующий шаг: добавляем ресурс к роли, и делаем заявку на назначение роли (а не ресурса). На первый взгляд, всё красиво: роль назначаем - атрибут DirXML-EntitlementRef появляется (вместе с атрибутами о том, что назначена роль и соответствующий ей ресурс). Однако, при отзыве роли процедура отрабатывает лишь частично: ссылки на роль и на ресурс у пользователя отбираются, а вот Entitlement (атрибут DirXML-EntitlementRef) остаётся! То же самое происходит и в случае, если пытаться использовать "старый" подход (привязывать Entitlement сразу к роли). Почему? Это что, явный баг, или я чего-то не учёл?...

Это не баг. Синтаксис атрибута DirXML-EntitlementRef = Path, компонент namespace определяет назначен (=1) или отозван (=0) entitlement. Для меня новость, что при непосредственном отзыве entitlement, его значение удаляется из этого атрибута.

[Константин Ошмян]

Андрей, спасибо!
Действительно, при разглядывании атрибута DirXML-EntitlementRef через LDAP видно, что там между символами "решётка" (#) есть ещё и единичка либо нолик (я до того пользовался iManager-ом, а в нём этого не видно). И для тех Entitlement-ов, которые были отозваны, там и в самом деле указан нолик. Не совсем понятно, правда, зачем вообще оставлять этот атрибут, если он всё равно не действует

Андрей, а где ещё можно почитать подробнее про эти Entitlement-ы? В частности, про синтаксис данного атрибута я пока что в документации не видел. Это какой-то раздел для разработчиков? Ткните, пожалуйста, более прицельно

[Андрей Троценко]

...где ещё можно почитать подробнее про эти Entitlement-ы? В частности, про синтаксис данного атрибута я пока что в документации не видел. Это какой-то раздел для разработчиков? Ткните, пожалуйста, более прицельно

Нет, это - часть собственных изысканий. На developer.novell.com, увы, это не расписывается.

Хороший материал по IDM-у есть здесь:
http://ldapwiki.willeke.com/wiki/IDMCodeSnippets
http://ldapwiki.willeke.com/wiki/NovellsIDMProduct
Чтобы начать писать интересные политики - самое оно.

Там же, кстати, есть и про DirXML-EntitlementRef:
http://ldapwiki.willeke.com/wiki/DirXML%20Entitlements

...
5. Так и не понял, каким образом из внешней системы вытягивается список возможных значений Entitlement-а. В настройках задаются параметры в формате LDAP-запроса. Но неясно, что указывать в случае, когда внешняя система - простая SQL-база. Или надо ресурсы внешней системы, представляемые Entitlement-ами, обязательно затягивать внутрь IDM-а (например, реплицируя их на какие-то custom-классы в Vault-е)?

Не совсем так. Для запроса списка возможных значений entitlement-а, указывается критерий поиска объектов в связанной системе, которые представляют эти значения - базовый DN, диапазон поиска, класс (любые, которые применимы для этой системы) и названия трех атрибутов, которые вытягиваются из результатов запроса, и будут представлены как display name/description/value. Техника исполнения этой выборки ничего общего с LDAP не имеет: для запроса возможных значений entitlement-а, по указанным критериям формируется запрос (документ <query>), который пускается на subscriber драйвера, чей это entitlement, а значения из <instance>-ов ответа представляют из себя данные для display name/description/value. Кроме значений атрибутов, здесь можно сослаться на DN объекта в подключенной системе или значение ключа ассоциации.
Понятно, что для выборки в качестве значений entitlement-а каких-либо отвлеченных вещей (классов, не входящих в список синхронизируемых драйвером) нужно сделать Map для фиктивного NDS-класса (он будет использован в запросе) с требуемым в целевой системе. Сами объекты этого класса затягивать в Каталог не обязательно, но, иметь Map для них и пропускать их в фильтре - нужно.
В случае JDBC-драйвера эта техника тоже применима: <query> дойдя до DriverShim-а будет преобразован им в необходимый SQL SELECT, а результат - в <instance>. В пикантных случаях, это можно сделать самостоятельно (в otp/itp) - по приведенным ссылочкам и в доке на JDBC-драйвер есть примеры как выполнять прямые SQL-запросы прямо из политик обоих каналов.

[Константин Ошмян]

Андрей, большое спасибо за ответы и за ссылки. Буду смотреть.

[Константин Ошмян]

Пробую вытянуть список значений Entitlement-а из связанной системы (доступ к ней - через JDBC).
Для этого завёл в схеме дерева фиктивный класс (Auxilary) IDM-FakeEntitlement с двумя обязательными текстовыми атрибутами: idmFakeEntitlementID (он же - naming attribute) и idmFakeEntitlementName. Подразумевается, что первый из них содержит значение Entitlement-а (без пробелов, латинницей), а второй - чуть более подробное описание. В свойствах IDM-овского драйвера прописал маппинг на соответствующую таблицу (на самом деле - view по имени hottabich.uGROUPbasic) базы данных из двух полей. В фильтр добавил синхронизацию этого класса, для обоих атрибутов указав тип синхронизации "Notify" для обоих каналов (не уверен, нужно ли это в обе стороны).

В результате драйвер запускается, но работает по-прежнему (т.е. юзеров из таблицы EBA.UADRBUSERS синхронизирует как положено, а Entitlement-ы не показывает). В трейс-логе видно, вот что:
- на Subscriber-channel приходит такой документ:

Код: Выделить всё

<nds dtdversion="2.0">
                                        <input>
                                                <query class-name="IDM-FakeEntitlement" scope="">
                                                        <search-class class-name="IDM-FakeEntitlement"/>
                                                        <read-attr attr-name="idmFakeEntitlementName"/>
                                                        <read-attr attr-name="idmFakeEntitlementID"/>
                                                </query>
                                        </input>
                                </nds>


- отрабатывает Schema mapping policy, после чего этот документ становится таким:

Код: Выделить всё

<nds dtdversion="2.0">
                                        <input>
                                                <query class-name="hottabich.uGROUPbasic" event-id="0" scope="">
                                                        <search-class class-name="hottabich.uGROUPbasic"/>
                                                        <read-attr attr-name="GROUPNAME"/>
                                                        <read-attr attr-name="GROUPID"/>
                                                </query>
                                        </input>
                                </nds>


- этот документ отдаётся Subscriber Shim-у, который обращается к СУБД. Самого сформированного SELECT-а не видно (несмотря на уровень трейса 6).
- назад возвращается такой документ:

Код: Выделить всё

<nds dtdversion="2.0" ndsversion="8.x" xmlns:jdbc="urn:dirxml:jdbc">
  <source>
    <product build="20110402_1136" instance="JDBC-RBNET2" version="3.5.7">DirXML Driver for JDBC</product>
    <contact>Novell, Inc.</contact>
  </source>
  <output>
    <status level="warning">Primary key values taken from an event are useful only before insertion.  Overriding key generation timing from 'after' to 'before' for table/view 'EBA.UADRBUSERS'.</status>
    <status event-id="0" level="warning">Table 'UGROUPBASIC' is undefined or not a parent table.</status>
    <status event-id="0" level="success"></status>
  </output>
</nds>

Я так понимаю, что результирующий SELECT ищет таблицу hottabich.uGROUPbasic не там, где надо (и не находит), несмотря на явно прописанное имя схемы. В свойствах драйвера (Properties -> Driver Configuration -> Driver Parameters -> Synchronization Filter) и в самом деле прописано синхронизировать "include by table/view name", причём указано только одно имя (EBA.UADRBUSERS). Однако, при попытке дописать там второе имя (hottabich.uGROUPbasic) драйвер стартует, инициализируется, а дойдя до вьюшки hottabich.uGROUPbasic, говорит, что не нашёл в ней полей, которые были бы помечены как Primary Key, после чего говорит, что синхронизация такого класса невозможна, и останавливается. Там и в самом деле ни одно из полей не является ключевым, но ведь мне их и синхронизировать-то на самом деле не надо!

Похоже, что надо модифицировать эту вьюшку, чтобы хотя бы одно из полей было ключевым.
Либо - как альтернатива - пользоваться политиками для встраивания Embedded SQL в subscriber-канал (если я правильно понял, то при таком подходе в фильтры данный класс добавлять не надо: драйвер про эту таблицу может вообще не знать, т.к. вся обработка ведётся политиками).
К сожалению, я пока что, несмотря на довольно простой SELECT ("SELECT * from hottabich.uGROUPbasic") и наличие примеров в доке, не очень понимаю, как эти политики пишутся. Т.е. в какой именно набор политик надо добавлять, и как писать условие и действие для политики, чтобы она срабатывала лишь когда надо. И надо ли делать "симметричную" ей политику для распарсивания результатов этого SELECT-а.

[Павел Гарбар]

появилась статья про Entitlements:
http://www.novell.com/communities/node/12760
А вот тут про атрибуты DirXML:
http://www.novell.com/communities/node/12529
Может будут полезными?

[Андрей Троценко]

...В свойствах IDM-овского драйвера прописал маппинг на соответствующую таблицу (на самом деле - view по имени hottabich.uGROUPbasic) базы данных из двух полей. В фильтр добавил синхронизацию этого класса, для обоих атрибутов указав тип синхронизации "Notify" для обоих каналов (не уверен, нужно ли это в обе стороны)...
В свойствах драйвера (Properties -> Driver Configuration -> Driver Parameters -> Synchronization Filter) и в самом деле прописано синхронизировать "include by table/view name", причём указано только одно имя (EBA.UADRBUSERS). Однако, при попытке дописать там второе имя (hottabich.uGROUPbasic) драйвер стартует, инициализируется, а дойдя до вьюшки hottabich.uGROUPbasic, говорит, что не нашёл в ней полей, которые были бы помечены как Primary Key, после чего говорит, что синхронизация такого класса невозможна, и останавливается. Там и в самом деле ни одно из полей не является ключевым, но ведь мне их и синхронизировать-то на самом деле не надо!...

Увы, для правильного построения ключа ассоциации драйвером, нужно:
а) либо чтобы было определено primary key - поле
б) либо чтобы для определения ключевого поля можно было использовать мета-информацию из имен полей.
Например, ключевое поле может наз. pk_ID. Подробнее об этом здесь: http://www.novell.com/documentation/idm ... 7s0b4.html Для вьюшек, это - единственный метод.
Для того, чтобы драйвер сам мог вытянуть информацию о ключевых полях из таблиц (но не из вьюшек), используется упомянутый параметр Synchronization Filter. Именно для этой публики, будет сделан SQL ~ SHOW CREATE TABLE ..., из которой драйвер вытянет набор полей и ключей. Если же есть поле таблицы, которое не определено как primary key, но, по сути им является, то его нужно именовать по методу б).
Понимаю, что для выборки значений Entitlement-ов, это - лишнее, но, похоже иначе ОНО не работает.
в) если предидущие два метода не выполнимы, и БД нельзя трогать для изменения, то - только прямые SQL.

Эти тараканы - не последние в JDBC-драйвере

...В фильтр добавил синхронизацию этого класса, для обоих атрибутов указав тип синхронизации "Notify" для обоих каналов (не уверен, нужно ли это в обе стороны)...

По-моему, для задачи выбора значений entitlement-ов, можно вообще выставить в "не синхронизировать" действия для этих атрибутов. В обе стороны. Уточню...

...К сожалению, я пока что, несмотря на довольно простой SELECT ("SELECT * from hottabich.uGROUPbasic") и наличие примеров в доке, не очень понимаю, как эти политики пишутся. Т.е. в какой именно набор политик надо добавлять, и как писать условие и действие для политики, чтобы она срабатывала лишь когда надо. И надо ли делать "симметричную" ей политику для распарсивания результатов этого SELECT-а.

В Вашем случае, если решитесь на такое - потребуется политика, лучшее место для нее - в otp, которая будет документ <query> преобразовывать в <jdbc:statement> (<query> при этом будет veto-ится), и "симметричная" - в itp, которая <jdbc:result> будет преобразовывать в <instance>.

[Константин Ошмян]

Павел, Андрей, спасибо большое!

Андрей, вариант "б" почти прошёл Как говорится, ум - хорошо, а два - лучше! Ведь знал же про кодирование метаинформации в именах полей, но напрочь вылетело из головы В нашем случае вьюшка в базе делалась специально под нужны IDM-а, поэтому подкорректировать её можно было без проблем.

Добавили префикс "pk_" к имени поля, а в свойствах драйвера - имя вьюшки для синхронизации, и стало существенно лучше. Теперь драйвер благополучно стартует, корректно опознаёт и основную таблицу (из которой синхронизирует юзеров), и вспомогательную вьюшку (где хранятся значения Entitlement-ов). Более того, когда в портале (верхнее меню "Roles and Resources", затем левое меню "Configure Roles and Resources Settings") в разделе "Entitlement Query Settings" нажать на "Refresh", то в трейс-логе драйвера видно, как в ответ на прежний Query драйвер формирует SELECT-ы к базе (сначала "SELECT PK_GROUPID FROM HOTTABICH.UGROUPBASIC ORDER BY PK_GROUPID", получает список, затем в цикле делает "SELECT PK_GROUPID, GROUPNAME FROM HOTTABICH.UGROUPBASIC WHERE PK_GROUPID = ?"), и, наконец, возвращает обратно результирующий XML-документ <output> с кучей <instance>-ов.

Осталось разобраться с последним шагом этой цепочки: почему же, блин, этот список так и не отображается в портале? Т.е. делаешь, например, назначение пользователю ресурса, к которому привязан этот многострадальный Entitlement, а при выборе значения Entitlement-а вытянутый снаружи список не высвечивается. В лучшем случае он пуст, в худшем - содержит значения, которые когда-то были там прописаны как Administrator-defined values (но с тех пор эта настройка давно уже заменена на "Values from application", и изменения неоднократно за-deploy-ены). Похоже, что надо теперь копать уже другой драйвер (не JDBC, а User Application Driver)
Update: Да, оказалось, что достаточно перезапустить User Application Driver - и заработало!