18 июл. 2013 г.

FAQ: OIM11gR2PS1 - работа с политиками доступа и ролями

Short intro: here you can find simple working scenarios, tested on OIM11gR2PS1 (11.1.2.1.0) how to work with roles and access policies due to large number of queries received...

Q: Как происходит назначение ролей и применение политик доступа в OIM 11gR2PS1 (11.1.2.1.0)? У меня не назначаются роли (не применяются политики доступа и т.д.).



Для иллюстрации работы политик доступа и ролей приведу шесть сценариев, которые были мной протестированы на OIM 11gR2PS1 (11.1.2.1.0) с рекомендованными патчами (см. предыдущий пост).

Сценарий 1. Назначение роли и применение политики для нового пользователя.

1. Создаем пользователя, устанавливаем ему атрибут Postal Address = Moscow.
2. Создаем роль Moscow Users, создаем ей правило назначения Postal Address = Moscow.
3. Создаем политику доступа Moscow Users OUD, ресурс – OUD, там группа. Назначаем политику доступа на роль Moscow Users.
4. Изменяем какой-либо атрибут пользователя, убеждаемся, что роль назначена после этого автоматически. Для выполнения политики доступа запускаем задачу Evaluate User Policies. Ресурс предоставляется.

Сценарий 2. Изменение политики доступа – добавление дочерней записи.

1. Изменяем политику доступа Moscow Users OUD и добавляем новую группу OUD. Запускаем задачу Evaluate User Policies, идем в профиль пользователя и видим, что назначена новая группа.

Сценарий 3. Изменение политики доступа – удаление дочерней записи.

1.  Изменяем политику доступа Moscow Users OUD и удаляем ранее добавленную группу OUD. Запускаем задачу Evaluate User Policies, идем в профиль пользователя и видим, что группа у пользователя удалена.

Сценарий 4. Назначение новой политики доступа на уже существующую (и назначенную пользователю) роль.

1. Создаем политику доступа Moscow Users OUD2, которая предоставляет доступ к OUD (в другую группу), назначаем ее на роль Moscow Users.
2. Запускаем задачу Evaluate User Policies, идем в профиль пользователя и убеждаемся, что добавлена новая привилегия в соответствии со второй политикой.

Сценарий 5. Удаление политики доступа с уже существующей (и назначенной пользователю) роли.

1. Отвязываем политику доступа Moscow Users OUD2, которая предоставляет доступ к OUD (в другую группу) от роли Moscow Users (привязав ее к какой-либо другой роли).
2. Запускаем задачу Evaluate User Policies, идем в профиль пользователя и убеждаемся, что ранее добавленная привилегия в соответствии со второй политикой доступа была изъята.

Сценарий 6. Автоматическое назначение роли по правилу для существующего пользователя.

1. Изменяем пользователю поле Postal Address=Spb и убеждаемся,  что пользователь был исключен из роли Moscow Users и аккаунт в OUD был отобран после запуска задачи Evaluate User Policies.
2. Добавляем новое свойство в System Properties и перезагружаем сервер OIM: OIM.RULE_RETROFIT_EVAL_IMMEDIATE = TRUE (внимание, данный флаг заставляет применяться роли немедленно, он является недокументированным и может без предупреждения "пропасть" в следующей версии).
3. Создаем новую роль Spb Users, назначаем ей политику доступа Moscow Users OUD2 и устанавливаем правило назначения Postal Address=Spb. Смотрим в профиль пользователя и убеждаемся, что роль автоматически назначена.
4. Выполняем задачу Evaluate User Policies и смотрим, что соответствующий ресурс был выделен, а группа добавлена.

При выполнении тестов я мониторил значение флага USR_POLICY_UPDATE, но он не менялся (null).

Комментариев нет:

Отправить комментарий