<objectType>
<kind>entitlement</kind>
<intent>group</intent>
<!-- delineation, attributes, etc -->
<marking>
<markRef oid="00000000-0000-0000-0000-000000000805"/>
<applicationTime>classification</applicationTime> (1)
</marking>
<!-- ... -->
</objectType>
Managed and Unmanaged Shadows
Since 4.9
This functionality is available since version 4.9.
|
Introduction
When connecting a new resource, typically it is already populated with data you want to manage from midPoint. While midPoint synchronization concepts can be used easily in most of the cases, there are situations when you cannot switch the direction of data propagation (authoritativeness) for all objects at the same time. There might be, for example, set of groups still managed by a legacy IDM system which is still in operation, therefore you cannot migrate such groups immediately, while other groups need to be migrated now. Another case is a need of group-by-group migration.
MidPoint cannot be configured to make resource exclusively authoritative for some objects while midPoint is exclusively authoritative for other objects of the same object type using only mappings and synchronization configuration.
Unmanaged
and Managed
marks are designed to help with the migration of objects from resource to midPoint during deployment.
The migration usually contains several phases:
-
during the migration, we trust the resource and wish to import (once or, more typically regularly, while the migration is in progress) all objects and their changes without allowing any operations from midPoint to the resource.
Unmanaged
mark can be used for the resource objects in this phase. -
after the migration, we want to "switch" the direction and start to manage the objects in the resource, not using it as a source of data anymore.
Managed
mark can be used for the resource objects in this phase.
Usage of marks is not mandatory. They are designed to help in environments where you need mixed inbound/outbound approach, which is typically during the migration of resource objects to midPoint with a goal of managing them from midPoint, eventually. With outbound-only or inbound-only resources, |
Unmanaged Mark
Shadow object marked as Unmanaged
is tolerated by midPoint, but not managed by it.
Unmanaged
mark is suitable for situations, where the resource is used the authoritative source of objects and all outbound mechanisms should be ignored until the migration of resource objects to midPoint is completed and resource stops being the authoritative source.
Add | Modify | Delete | Inbound | Outbound | Membership inbound | Membership outbound | Tolerant membership |
---|---|---|---|---|---|---|---|
Disabled |
Disabled |
Disabled |
Enabled |
Disabled |
Enabled |
Disabled |
True |
Managed Mark
Shadow object marked as Managed
is managed by midPoint.
MidPoint ignores changes on the resource for the objects or its membership.
Managed
mark is suitable for situations, where the resource is being switched from being the authoritative source of objects to ordinary target system.
From now on, all outbound mechanisms should work normally.
The inbound mechanisms are partially enabled to allow reacting on synchronization situations, but the inbound mappings are ignored.
Add | Modify | Delete | Inbound | Outbound | Membership inbound | Membership outbound | Tolerant membership |
---|---|---|---|---|---|---|---|
Enabled |
Enabled |
Enabled |
Enabled - except for mappings |
Enabled |
Disabled |
Enabled |
False |
Marking Mechanism
A mechanism to set mark on selected entitlement shadows is needed. One option is to do that manually via GUI for individual shadows. A better one is to use automatic marking facility in midPoint, potentially with overriding these marks manually via GUI. It is also possible to define a default operation policy for object type.
Manual Marking of Individual Shadows
Individual shadows can be marked using GUI when browsing resource shadows of specific resources or in simulation results.
Marking Rules
Marking rules can be used in various ways.
One possible way is to mark all new shadows (applied in classification phase).
Unmanaged
mark for all new shadows1 | This causes marking each newly classified or reclassified shadow as Unmanaged . |
You can also configure midPoint to mark specific shadows using a filter with midPoint query language.
This approach can be used to make/keep specific shadows Unmanaged
even if all other shadows are already migrated to midPoint.
Unmanaged
mark for selected shadows (matching criteria defined by a filter)<objectType>
<kind>entitlement</kind>
<intent>group</intent>
<!-- delineation, attributes, etc -->
<marking>
<markRef oid="00000000-0000-0000-0000-000000000805"/>
<pattern>
<filter>
<q:text>attributes/info = "temporary"</q:text> (1)
</filter>
</pattern>
</marking>
<!-- ... -->
</objectType>
1 | This causes marking each group that has the value of temporary in its info attribute as Unmanaged . |
Default Operation Policy
You can define implicit behavior for all objects belonging to specific objectType using default operation policy.
It defines behavior as if the specific mark was used for shadows.
You can use default operation policy with marking rules or individual shadows marks which can override it.
Therefore, you can configure the whole objectType as Managed
, but specific groups can be still marked as Unmanaged
.
This approach is very useful during the migration of resource objects to midPoint.
Unmanaged
with an existing marking configuration<objectType>
<kind>entitlement</kind>
<intent>group</intent>
<!-- delineation, attributes, etc -->
<marking>
<markRef oid="00000000-0000-0000-0000-000000000805"/>
<pattern>
<filter>
<q:text>attributes/info = "temporary"</q:text> (1)
</filter>
</pattern>
</marking>
<!-- ... -->
<defaultOperationPolicy>
<policyRef oid="00000000-0000-0000-0000-000000000806"/> (2)
<!-- Managed -->
</defaultOperationPolicy>
</objectType>
1 | This causes marking each group that has the value of temporary in its info attribute as Unmanaged . |
2 | This causes all shadows except the explicitly marked ones to be considered as Managed |
The default operation policy is empty. |
Marks and Lifecycle State
During the migration, it is typically required to make sure that nothing wrong is happening with the help of simulations. For that reason, marks can be set with lifecycle state.
For example, the default operation policy is about to be switched from Unmanaged
to Managed
, but there are background tasks running in your system, and simulated reconciliation should be executed before that switch is made.
<objectType>
<kind>entitlement</kind>
<intent>group</intent>
<!-- delineation, attributes, etc -->
<!-- ... -->
<defaultOperationPolicy>
<policyRef oid="00000000-0000-0000-0000-000000000805"/> (1)
<!-- Unmanaged -->
<lifecycleState>deprecated</lifecycleState>
</defaultOperationPolicy>
<defaultOperationPolicy>
<policyRef oid="00000000-0000-0000-0000-000000000806"/> (2)
<!-- Managed -->
<lifecycleState>proposed</lifecycleState>
</defaultOperationPolicy>
</objectType>
1 | Default operation policy Unmanaged is in deprecated lifecycle state. It is used by all running tasks. |
2 | Default operation policy Managed is in proposed lifecycle state. It is used only during simulations. |
After the simulation is finished, lifecycle states can be switched.
<objectType>
<kind>entitlement</kind>
<intent>group</intent>
<!-- delineation, attributes, etc -->
<!-- ... -->
<defaultOperationPolicy>
<policyRef oid="00000000-0000-0000-0000-000000000805"/> (1)
<!-- Unmanaged -->
<lifecycleState>archived</lifecycleState>
</defaultOperationPolicy>
<defaultOperationPolicy>
<policyRef oid="00000000-0000-0000-0000-000000000806"/> (2)
<!-- Managed -->
<lifecycleState>active</lifecycleState>
</defaultOperationPolicy>
</objectType>
1 | Default operation policy Unmanaged is in archived lifecycle state. It is not used anymore. |
2 | Default operation policy Managed is active. |