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).
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).
No comments:
Post a Comment