Short intro: here you can find solution (answer to FAQ) about possible target system entitlement parameterization – you’re requesting function and a subset of data, on this works this function…
Q: Мои системы построены таким образом, что права имеют два измерения – операции (роли, функции и т.д.), характеризующие тип обработки данных, и данные (отделение, группа счетов и т.д.), над которыми эти действия должны выполняться. В текущем варианте работы IDM системы мне необходимо создавать избыточное количество ролей, перемножая множество операций на множество групп данных, на которые распространяются операции. Есть ли какое-то решение этого вопроса?
A: Мне все чаще приходится сталкиваться с подобными вопросами и ниже я приведу возможное решение данного вопроса в рамках стандартной и поддерживаемой OOTB кастомизации Oracle Identity Manager. Обращаю ваше внимание, что данная параметризация в итоге будет опираться на возможности параметризации самих привилегий в целевых системах, что выходит за рамки рассмотрения этой статьи.
Итак, мы имеем установленный и настроенный коннектор LDAP и ресурс LDAP User (и настроенная Application Instance, т.е. вы можете выполнять предоставление доступа в LDAP при помощи коннектора), а также LDAP группы, которые по умолчанию содержат в себе лишь наименование. Задача – добавить новый атрибут, текстовое поле “Restrictions”. Впоследствии значение этого атрибута может быть передано в задачу адаптера, а затем и в целевую систему.
1. Для начала зайдем в административную веб консоль OIM и создадим новую песочницу, которая необходима для работы дизайнера форм. Создадим там новый Sandbox и убедимся, что его имя отобразится в верхнем меню справа.
2. В дереве слева найдем линк Form Designer, как показано на экран ниже. Откроется страница поиска форм.
3. Выберем в качестве Resource Type ресурс LDAP User, ищем доступные формы и убедимся, что мы видим форму (название у вас может отличаться).
4. Откроем найденную форму. Отобразятся поля аккаунта.
5. Перейдем на вкладку Child Objects и выберем объект, соответствующий группе LDAP.
6. Откроется список полей для группы. Для того, чтобы добавить новое поле, нажмем New, как показано на экране ниже.
7. Укажем тип поля – Text.
8. Укажем наименование поля его описание (Restrictions). Нажмите Save and Close. При этом произойдет расширение соответствующей таблицы в БД (добавится дополнительное поле), а также создастся необходимая метаинформация.
9. Информация о новом поле группы LDAP будет отображена в списке. Нажмите Back to Parent Object.
10. Нажмем Regenerate View и перегенерируйте представление формы в соответствии с показанным на экране ниже.
11. Убедимся, что форма булла успешно перегенерирована и опубликуем песочницу.
12. Зайдем в приложение самообслуживания конечным пользователем, перейдем в раздел Request Access. Выберем пользователя, для которого осуществляется запрос и нажмем Next.
13. Найдем группы, соответствующие LDAP (обратите внимание, что в моем случае автоматически в корзину доступа добавился аккаунт в LDAP), добавим их в корзину и нажмем Next.
14. Просмотрим информацию об элементах корзины. Найдем ранее запрошенную группу LDAP и перейдем на вкладку ее редактирования.
15. Убедимся, что мы видим и имеем возможность заполнить поле Restrictions для группы LDAP. Мы не будем создавать запрос на этом этапе, нам достаточно убедиться, что мы можем задать значение.
16. Теперь проверим возможность задания значения Restrictions для уже назначенных групп LDAP. Найдем пользователя с аккаунтом и группой в LDAP. Убедимся, что видим поле в Detail Information.
17. Нажмем Modify Entitlement и убедимся, что мы можем поменять значение поля. Поменяем на какое-нибудь значение, нажмем Update и Submit.
18. Обновим список привилегий пользователя и убедимся, что значение атрибута было сохранено.
Вот и все. Обратите внимание, что значение атрибута уникально для каждого назначения группы. Также, указав в Design Console ключевые признаки, возможно сделать несколько назначений одной и той же группы (роли, операции и т.д.) с разными значениями атрибута.
Q: Мои системы построены таким образом, что права имеют два измерения – операции (роли, функции и т.д.), характеризующие тип обработки данных, и данные (отделение, группа счетов и т.д.), над которыми эти действия должны выполняться. В текущем варианте работы IDM системы мне необходимо создавать избыточное количество ролей, перемножая множество операций на множество групп данных, на которые распространяются операции. Есть ли какое-то решение этого вопроса?
A: Мне все чаще приходится сталкиваться с подобными вопросами и ниже я приведу возможное решение данного вопроса в рамках стандартной и поддерживаемой OOTB кастомизации Oracle Identity Manager. Обращаю ваше внимание, что данная параметризация в итоге будет опираться на возможности параметризации самих привилегий в целевых системах, что выходит за рамки рассмотрения этой статьи.
Итак, мы имеем установленный и настроенный коннектор LDAP и ресурс LDAP User (и настроенная Application Instance, т.е. вы можете выполнять предоставление доступа в LDAP при помощи коннектора), а также LDAP группы, которые по умолчанию содержат в себе лишь наименование. Задача – добавить новый атрибут, текстовое поле “Restrictions”. Впоследствии значение этого атрибута может быть передано в задачу адаптера, а затем и в целевую систему.
1. Для начала зайдем в административную веб консоль OIM и создадим новую песочницу, которая необходима для работы дизайнера форм. Создадим там новый Sandbox и убедимся, что его имя отобразится в верхнем меню справа.
2. В дереве слева найдем линк Form Designer, как показано на экран ниже. Откроется страница поиска форм.
3. Выберем в качестве Resource Type ресурс LDAP User, ищем доступные формы и убедимся, что мы видим форму (название у вас может отличаться).
4. Откроем найденную форму. Отобразятся поля аккаунта.
5. Перейдем на вкладку Child Objects и выберем объект, соответствующий группе LDAP.
6. Откроется список полей для группы. Для того, чтобы добавить новое поле, нажмем New, как показано на экране ниже.
7. Укажем тип поля – Text.
8. Укажем наименование поля его описание (Restrictions). Нажмите Save and Close. При этом произойдет расширение соответствующей таблицы в БД (добавится дополнительное поле), а также создастся необходимая метаинформация.
9. Информация о новом поле группы LDAP будет отображена в списке. Нажмите Back to Parent Object.
10. Нажмем Regenerate View и перегенерируйте представление формы в соответствии с показанным на экране ниже.
11. Убедимся, что форма булла успешно перегенерирована и опубликуем песочницу.
12. Зайдем в приложение самообслуживания конечным пользователем, перейдем в раздел Request Access. Выберем пользователя, для которого осуществляется запрос и нажмем Next.
13. Найдем группы, соответствующие LDAP (обратите внимание, что в моем случае автоматически в корзину доступа добавился аккаунт в LDAP), добавим их в корзину и нажмем Next.
14. Просмотрим информацию об элементах корзины. Найдем ранее запрошенную группу LDAP и перейдем на вкладку ее редактирования.
15. Убедимся, что мы видим и имеем возможность заполнить поле Restrictions для группы LDAP. Мы не будем создавать запрос на этом этапе, нам достаточно убедиться, что мы можем задать значение.
16. Теперь проверим возможность задания значения Restrictions для уже назначенных групп LDAP. Найдем пользователя с аккаунтом и группой в LDAP. Убедимся, что видим поле в Detail Information.
17. Нажмем Modify Entitlement и убедимся, что мы можем поменять значение поля. Поменяем на какое-нибудь значение, нажмем Update и Submit.
18. Обновим список привилегий пользователя и убедимся, что значение атрибута было сохранено.
Вот и все. Обратите внимание, что значение атрибута уникально для каждого назначения группы. Также, указав в Design Console ключевые признаки, возможно сделать несколько назначений одной и той же группы (роли, операции и т.д.) с разными значениями атрибута.
Какие именно ключевые признаки нужно выставить в дизайн консоли, чтобы группа с различными значениями атрибута Restrictions считалась как разные энтайтлменты?
ReplyDeleteВ моем понимании, нужно в процессе указать все поля как ключевые, чтобы не перезатерлось при реконсиляции, а назначить одну и ту же роль с разными параметрами должно быть возможно и так
Deleteвпрочем, я тут не проверял, но задача такая стоит, найду свободное время и поиграю, там в связи с этим может появляться много вопросов
DeleteНемного поразбирался дальше. Пусть у нас есть объект RoleName (он же с признаком Entitlement=true) и RoleArea (что-то типа Scope). Запросить вторую роль с другим RoleArea через каталог нельзя, там встроена проверка на наличие такого же Entitlement для указанного аккаунта. Можно это сделать через модификацию ресурса (и я не проверял, но мне кажется, можно получить это через реконсиляцию), в этом случае можно добавлять одинаковые RoleName с разным RoleArea, все работает. С одинаковым RoleArea нельзя, идет проверка в коде и роль не добавляется. Однако, на закладку Entitlements попадет только одна роль (случайная) с заданным RoleName, т.е. на отображении стоит фильтрация.
DeleteИтог: функциональность присутствует, backend готов к назначению одинаковых ролей с разными атрибутами (что подтверждает возможност назначения ролей через Modify Accounts), но код, ответственный за работу с каталогом, имеет ограничения.
Встают вопросы:
- как запросить имеющуюся роль, но с другим Scope?
- как отображать в Entitlements назначенные одинаковые роли с разным Scope?
Я сейчас переписываюсь с PM по этому вопросу, буду держать в курсе.
После переписки с PM пришли к выводу, что только один Entitlement может быть назначен для одного аккаунта вне зависимости от того, какие там параметры. Подход с Modify Accounts не рекомендуется. Я сейчас создам SR на эту тему и буду добиваться ER и последующего включения в стандартный функционал поддержку "составного entitlement" (Role + Scope)
ReplyDelete>> Combined entilements in a final lookup and using that as the entitlement column of the child table
To avoid manual development of the predefined list or future maintenance issue,you need to write OIM Scheduled Job code to take both list (Roles,Scopes) and relationship logic and generate a master list of combined values automatically at some interval, then use this master list as the lookup of the entitlement column
Pros:
1. You can maintain the list and processing in OIM side by scheduled job
2. You may use roles and access policies to define a pre-defined sets of multiple entilements to help users (blackbox mode) or
define 'profile' to combine multiple entitlemnts by API (I am not sure if it is there or not)
Cons:
1. You must store the relationship logic somewhere and maintain it
>> In your use case, the user is being granted {Role + Scope}, so as far as OIM is concerned, the entitlement is a combination of the two.
That's why the approach of access policy won't work either.
Your customer can file an ER asking for better support in OIM
for your use case.
Спасибо, что написал это в отдельном посте, т.к. я не очень оперативно следил за обновлениями комментариев тут )
Deleteт.е. рекомендуемый подход на данном этапе при необходимости одновременного назначения привилегии с разными областями действия - на основе Lookup'ов для Roles и Scopes создавать Lookup с привилегиями RoleN_ScopeN и его рассматривать в качестве Lookup'а с признаком Entitlement
ReplyDelete