Managed and Unmanaged Shadows

Last modified 18 Oct 2024 08:41 +02:00
Since 4.9
This functionality is available since version 4.9.
Table of Contents

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:

  1. 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.

  2. 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 and Managed marks are not needed; midPoint behavior can be configured using strictly outbound or inbound mappings and appropriate synchronization reactions.

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.

Table 1. Unmanaged mark behavior
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.

Table 2. Managed mark behavior
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).

Setting the Unmanaged mark for all new shadows
<objectType>
    <kind>entitlement</kind>
    <intent>group</intent>
    <!-- delineation, attributes, etc -->
    <marking>
        <markRef oid="00000000-0000-0000-0000-000000000805"/>
        <applicationTime>classification</applicationTime> (1)
    </marking>
    <!-- ... -->
</objectType>
1 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.

Setting the 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.

Setting default operation policy to 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.

Migrating the default operation policy during production, not influencing background tasks
<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.

Migrating the default operation policy during production, not influencing background tasks
<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.
Was this page helpful?
YES NO
Thanks for your feedback