Object Marks

Last modified 19 Aug 2024 18:06 +02:00

Object mark feature

This page is an introduction to Object mark midPoint feature. Please see the feature page for more details.

Since 4.7

This functionality is available since version 4.7.

Table of Contents

Introduction
Basic Concepts
- Effective Marks
- Policy Statements
Object Operation Policy
- Built-in Object Marks
GUI: Object Marks and Shadows

Introduction

Object Marks are light-weight marking mechanism for objects in order to ease administration of midPoint and/or induce specific behavior policies to marked objects.

Marked objects could be filtered by mark in Admin GUI and may receive additional policies based on effective marks.

Technically object marks are MarkType with archetype Object Mark.

Object Marks are only supported with Postgres Native Repository.

Object Marks are currently only fully supported for shadows.

Basic Concepts

Effective Marks

Effective marks are marks, which are applied to object based on policies, or explicitly specified by policy statements of the object.

Effective marks are stored in object effectiveMarkRef of type ObjectReferenceType and are indexed by repository, so it is possible to use them for search.

Policy Statements

Effective marks could be manually added / induced / excluded from object by modifying policy statement of particular object.

A policy statement has two main properties:

markRef - object reference, which specifies mark
type - enumeration, which specifies type of policy statement
- apply - referenced mark is manually added as effective mark
- exclude - referenced mark will not be effective, even if other policy may specify it so.

Marking Shadow as Protected

<policyStatement>
    <markRef oid="00000000-0000-0000-0000-000000000800" relation="org:default" type="c:MarkType">
        <!-- Protected -->
    </markRef>
    <type>apply</type>
</policyStatement>

Object Operation Policy

Currently, the object operation policy is supported for shadow objects only.

Object Marks allows to specify operation policy, which may enabled or disable specific operations for marked objects.

Currently supported object operation policies for shadows are:

Operation Kind Behavior if disabled

Operation	Kind	Behavior if disabled
`add`	New shadows having this operation disabled cannot be added on the resource, neither manually nor automatically. Any such attempt results in an error.
`modify`	Shadows having this operation disabled cannot be modified on the resource, neither manually nor automatically. Any such attempt results in an error.
`delete`	Shadows having this operation disabled cannot be deleted from the resource, neither manually nor automatically. Any such attempt results in an error. (Except for manual deletion from GUI, where the severity of `info` is respected.)
`synchronize`	`inbound`	Shadows having this operation disabled are excluded from inbound synchronization.
`outbound`	Changes in focus objects do not trigger mappings and are not propagated to the resource.
`synchronize/membership` (applies to entitlements only)	`inbound`	The membership information regarding entitlement shadows having this operation disabled is excluded from inbound synchronization.
`outbound`	The membership information regarding entitlement shadows having this operation disabled is not propagated from focus objects to the resource.
`tolerant`	This is actually not an operation, but a boolean (`true`/`false`) flag that overrides whether the membership information regarding this entitlement is tolerated on the resource, if it’s not provided by any mappings. Please see Tolerating Existing Association Values.

add

New shadows having this operation disabled cannot be added on the resource, neither manually nor automatically. Any such attempt results in an error.

modify

Shadows having this operation disabled cannot be modified on the resource, neither manually nor automatically. Any such attempt results in an error.

delete

Shadows having this operation disabled cannot be deleted from the resource, neither manually nor automatically. Any such attempt results in an error. (Except for manual deletion from GUI, where the severity of info is respected.)

synchronize

inbound

Shadows having this operation disabled are excluded from inbound synchronization.

outbound

Changes in focus objects do not trigger mappings and are not propagated to the resource.

synchronize/membership (applies to entitlements only)

inbound

The membership information regarding entitlement shadows having this operation disabled is excluded from inbound synchronization.

outbound

The membership information regarding entitlement shadows having this operation disabled is not propagated from focus objects to the resource.

tolerant

This is actually not an operation, but a boolean (true/false) flag that overrides whether the membership information regarding this entitlement is tolerated on the resource, if it’s not provided by any mappings. Please see Tolerating Existing Association Values.

Default object operation policy for objects without marks specifying policy is to have all operations enabled. This default can be changed by setting defaultOperationPolicyRef for specific resource object type definition.

If object has multiple effective marks specifying object operation policy, these policies are merged. Operations disabled by any of the marks are always disabled.

The tolerant flag should not have values of true and false mixed together. The current implementation is that the value of true is the result, should such a combination occur (with a warning into the log), but this behavior may change in the future.

Object Operation Policy of Protected mark

<objectOperationPolicy>
    <synchronize>
        <inbound>
            <enabled>false</enabled>
            <severity>info</severity>
        </inbound>
        <outbound>
            <enabled>false</enabled>
            <severity>info</severity>
        </outbound>
    </synchronize>
    <add>
        <enabled>false</enabled>
        <severity>error</severity>
    </add>
    <modify>
        <enabled>false</enabled>
        <severity>error</severity>
    </modify>
    <delete>
        <enabled>false</enabled>
        <severity>error</severity>
    </delete>
</objectOperationPolicy>

Limitations

For add,modify,delete operations, only the error severity is supported.
For all other operations, only the info severity is supported.
The synchronize/membership/inbound is supported only for associationSynchronization expression evaluator.
The synchronize/membership/outbound is supported only for associationConstruction expression evaluator.

Built-in Object Marks

Protected

Object Mark which denotes object (shadow) as Protected. Behavior of shadow marked with this mark is equivalent to setting it as protected in resource schema handling.

In 4.7 if shadow is to be protected according to resource definition, shadow is automatically marked Protected (effectiveMarkRef) and objectOperationPolicy defined in Protected mark enables protected behavior.

Table 1. Built-in Object Marks
Mark	Operations allowed				Description
Mark	Sync	Add	Mod	Del	Description
Protected	No	No	No	No	Protected accounts. MidPoint ignores them in both synchronization and provisioning. Usually used for administrative or technical accounts.
Decommission later	No	Yes	Yes	Yes	Accounts which should not be updated automatically by synchronization, but may be edited / deleted manually later.
Correlate later	No	Yes	Yes	Yes	Accounts which can not be correlated automaticly and should be skipped during synchronization.
Do not touch	No	No	No	No	Accounts which we do not want to be synchronized / modified by midPoint. (same as protected), but reason may be different.
Invalid data	No	No	No	No	Account which has bad data and should be ignored by synchronization. Same behavior as `Protected`, but different semantic meaning.

GUI: Object Marks and Shadows

In midPoint 4.7 object marks are only supported for shadows.

Marking Shadows in Resource Details

MidPoint GUI allows manually marking shadows in resource details view using Add Marks, Mark as Protected actions in Accounts and Entitlements.

Workflow screenshots

Figure 1. Go to Resource → Accounts

Figure 2. Click on Menu for Shadow

Figure 3. Select Add Marks

Figure 4. Select Marks to be added to shadow

Removing Shadow Marks in Resource Details

MidPoint GUI allows removing manually mark of shadows in resource details view using Remove Marks actions in Accounts and Entitlements.

Workflow screenshots

Figure 5. Go to Resource → Accounts, select accounts from which marks will be removed

Figure 6. Click on Menu for Selected Shadows, Select Remove Marks

Figure 7. Select Marks which should be removed from selected accounts

Figure 8. Click Remove Marks to remove them

Marking Shadows in Simulation Results

MidPoint GUI allows manually marking shadows in Simulations results → Processed Object views. This is done by clicking menu icon and selecting Add Marks. Note that mark is applied to real shadow (not simulated result). This allows for use-cases such as running simulations and excluding particular shadows from real run.

In Simulations GUI mark is applied to actual underlying object

Workflow screenshots

Figure 9. Click on Menu icon for shadow

Figure 10. Select Add Marks

Figure 11. Select Marks and click Add

Listing marked shadows across resources

In order to view all shadows marked by specific mark, you can navigate in midPoint GUI, to Marks, open specific object mark details and click on Marked Shadows.

Compliance

This feature is related to the following compliance frameworks:

Was this page helpful?

YES NO

Thanks for your feedback