Navigation Tree

Object Marks

Last modified 26 Sep 2025 08:59 +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
How it works
Basic concepts
- Effective marks
- Policy statements
Object operation policy
- Built-in object marks
- Shadow policy marks

This describes Object Marks, a midPoint feature that enables you to classify objects into groups to which you can then apply policies.

Introduction

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

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

Object marks are MarkType with the Object Mark archetype.

Grouping objects with marks, and applying policies to those groups enables you to cover many business scenarios, such as:

Lifecycle management - Mark users as "inactive" after a certain period of inactivity and define a policy that automatically initiates a deprovisioning process, such as revoking access rights, or archiving data, thus ensuring compliance with organizational policies.
Audit and compliance - Mark objects as "under review" and set up a policy that restricts changes to those objects until a review process is complete.
Data protection - Protect your imported data from being altered by marking them as "unmanaged".
Workflow automation - Set up a policy that triggers specific workflows related to account setup, access provisioning, or training assignments, if a user is marked as "onboarding".

Object Marks are only supported with Postgres Native Repository.
Object Marks are currently only fully supported for shadows.

How it works

A typical scenario in which marks are used to control the behavior of groups of objects has the following steps:

Create object marks that support your use case.
Classify objects into marked groups by assigning marks to filtered objects.
Define the default operation policy for objects that do not have an explicitly specified mark.
Create policies that apply to individual object marks.

See how you can classify objects and define the default operation policy in the midPoint GUI.

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.

The supported object operation policies for shadows are:

Table 1. Supported object operation policies for shadows
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.
`synchronize`	`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 defaultOperationPolicy 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

These object marks are intended to mark objects violating various policies.

Table 2. Built-in object marks
Object Mark	Description
Assignment modified	Assignment was modified in an illegal, suspicious or interesting way.
Assignment state	Assignment is in illegal, suspicious or interesting state.
Assignment time validity	Assignment time validity has started, ended or otherwise reached interesting point in time.
Exclusion violation	Violation of exclusion policy, such as segregation duty violation
Has assignment	Object has illegal, suspicious or interesting assignment.
Has no assignment	Object does not have required, recommended or interesting assignment.
Neglected	Mark for object that is not properly cared for, such as role that was not reviewed for a long time.
Object modified	Object was modified in an illegal, suspicious or interesting way.
Object state	Object is in illegal, suspicious or interesting state.
Object time validity	Object time validity has started, ended or otherwise reached interesting point in time.
Orphaned	Mark for object which does not have an owner.
Overassigned	Excessive number of assignees. Usually indicates object assigned too many time, such as role assigned to too many users.
Requirement violation	Violation of requirement policy, such as insufficient clearance
Suspicious	Mark for Suspicious object. It should be (manually) investigated.
Underassigned	Unsifficient number of assignees. Usually indicates shortage of staff, vacancies or other understaffing situations.
Understaffed security	Mark for security role or responsibility which is not properly staffed, it is not assigned to the users according to policy.

Shadow policy marks

Automatic marking of shadows with shadow policy marks can be configured in resource schema handling.

Table 3. Built-in shadow marks
Mark	Operations allowed					Description
	Sync		Add	Mod	Del
	In	Out	Add	Mod	Del
Protected	No	No	No	No	No	Protected accounts. MidPoint ignores them in both synchronization and provisioning. Usually used for administrative or technical accounts.
Managed	Yes	Yes	Yes	Yes	Yes	Protected accounts. MidPoint ignores them in both synchronization and provisioning. Usually used for administrative or technical accounts. Refer to Managed and Unmanaged Shadows for details.
Unmanaged	Yes	No	No	No	No	Shadow object marked as `Unmanaged` is tolerated by midPoint, but not managed by it. Refer to Managed and Unmanaged Shadows for details.
Decommission later	No	No	Yes	Yes	Yes	Shadow object which should not be updated automatically by synchronization, but may be edited / deleted manually later.
Correlate later	No	No	Yes	Yes	Yes	Shadow object which can not be correlated automaticly and should be skipped during synchronization.
Do not touch	No	No	No	No	No	Shadow object 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	No	Shadow object which has bad data and should be ignored by synchronization. Same behavior as `Protected`, but different semantic meaning.

Compliance

This feature is related to the following compliance frameworks:

Was this page helpful?

YES NO

Thanks for your feedback