Short intro: here you can find continuation of entitlements
parametrizing discussion with some new inputs, opinions & results…
Тема с
параметризацией запроса привилегии в целевой системе (которая обсуждалась в
этой статье) оказалась насущной, я получил ряд вопросов и отзывов, сделал ряд
экспериментов, а также инициировал переписку с PM (Product Management) Oracle.
Оказалось, что все не так хорошо и просто, как того хотелось бы. Подробности –
под катом.
Итак, мы успешно
параметризовали привилегию так, как было показано в предыдущей статье. Таким
образом, мы имеем роль в целевой системе (Entitlement с точки зрения OIM),
определяющую выполняемую функцию, а также область действия этой функции («Scope»).
Мы можем создать / расширить форму для роли как дочернюю форму процесса. Также
мы можем передать расширенные атрибуты формы процесса в адаптер, чтобы в итоге назначить
роль с соответствующей областью действия в целевой системе. Все это работает,
но есть одно «но».
Таким образом
можно назначить только одну роль для одного аккаунта в целевой системе. Попытка
назначить несколько однотипных ролей одновременно с разными областями действия
(например, роль «Бухгалтер» в регионе Москва и Санкт Петербург) окончится
неудачей. Почему?
Только одно поле
дочерней формы процесса может быть помечено как Entitlement. Документация
говорит следующее:
34.4
Marking Entitlement Attributes on Child Process Forms
You must mark the entitlement
attribute in the child process form UD_ table for resources for which you want
to capture entitlement data. Suppose there are 15 target systems in your
operating environment. If you want to capture entitlement data from 12 of 15
resources, then you must mark the entitlement attribute in those 12 resources.
Apply the following guidelines while
performing the procedure described in this section:
- On a child process form, only one attribute holding
entitlement data can be marked.
- The attribute that you mark must be of the LookupField
type and its property must be one of the following:
- Lookup code
- Lookup query
The
Lookup query must satisfy the following conditions:
- The query uses the LKU and
LKV tables
- The Lookup code in the query
is from the LKU table
- The LKV_ENCODED column value
is used for saving
- The LKV_DECODED column value
is used for display purposes
В нашем случае
признак Entitlement=true установлен у роли, соответственно приложение OIM версии
11gR2PS3 не позволит назначить привилегию несколько раз через каталог (считается,
что привилегия уже назначена). Вы можете назначить одну роль несколько раз с
разными областями видимости через Modify Accounts (это можно без проблем
сделать, я проверил), но это не является рекомендуемым способом работы с OIM и
на закладке Entitlements вы
потом увидите только одну роль. Также не рекомендуется включать несколько
одинаковых ролей с разными областями действия в состав Access Policy и назначать
их через роли (я проверял, это возможно). Другими словами, для одного аккаунта
в целевой системе пользователю может быть назначена только одна роль (группа и
т.д., другими словами, «Entitlement») вне зависимости от значений ее атрибутов.
Как быть?
Рекомендованный путь с точки зрения PM – создание составной роли (RoleI_ScopeJ) как отдельного поля в дочерней форме процесса с
указанием Entitlement = true. Задачи по расписанию заполняют Lookup'ы для Roles
и Scopes, а дополнительная задача поддерживает список RoleI_ScopeJ на основании
заполненных ранее справочных Lookup'ов. То есть мы опять приходим к
необходимости хранения в каталоге доступа декартова произведения Roles X Scopes
(Role1_Scope1, Role1_Scope2, …, RoleI_Scope1, RoleI_Scope2,… RoleN_ScopeM), параметризация запроса роли в целевой системе через атрибуты дочерней
формы процесса сработает только для единичного назначения.
Я создам SR на
эту тему в поддержке Oracle (чтобы перейти к ER – Enhancement Request) и последующей поддержке этой
функциональности в продукте. Если у вас стоит похожая задача, напишите мне на
oleg.faynitskiy@gmail.com с описанием бизнес кейза, это может помочь в убеждении PM в реализации
данного функционала.
No comments:
Post a Comment