Object Marks

Last modified 10 Nov 2025 09:37 +01: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

This describes Object Marks, a midPoint feature that enables flexible object classification, which you can use not only to apply policies to specific groups but also to organize and report on your data.

Introduction

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

They are designed to:

  • Enable fine-grained policy control - You can define object restrictions based on object classification.
    For example, protect your imported data from being altered by marking them as "unmanaged".

  • Support flexible lifecycle management - You can temporarily or permanently categorize objects for specific lifecycle actions, such as review, archiving, or other special handling.
    For example, you can 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.

  • Provide metadata for reporting and automation - Marks can serve as metadata tags that facilitate reporting, auditing, and automated workflows.
    For example, mark objects as "under review" and set up a policy that restricts changes to those objects until a review process is complete.

  • 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".

You can use marks to track object states or categories without altering their core attributes.

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.

  • Object Marks are only supported with Postgres Native Repository.

  • Object Marks are currently only fully supported for shadows.

How it works

This shows you how object marks integrate with midPoint policies.

Object marks sit between the actual objects and policies that are applied to them. They provide a layer of classification that allows you to define and enforce policies based on the assigned marks.

The following diagram shows how you can use marks as classifiers based on which policies treat objects differently:

flowchart TD subgraph A["Objects"] direction LR U1["User A (Mark: 'active')"] U2["User B (Mark: 'inactive')"] U3["User C (Mark: 'review')"] end A --> B["Policy evaluates marks"] B -->|Policy for 'active'| C1["Provisioned to target systems"] B -->|Policy for 'inactive'| C2["Provisioning blocked"] B -->|Policy for 'review'| C3["Sent to manager for approval"] subgraph D["System Outcomes"] C1 C2 C3 end classDef obj fill:#e0f2fe,stroke:#0369a1,stroke-width:1px,color:#111; classDef proc fill:#ede9fe,stroke:#7c3aed,stroke-width:1px,color:#111; classDef out fill:#dcfce7,stroke:#15803d,stroke-width:1px,color:#111; class U1,U2,U3 obj; class B proc; class C1,C2,C3 out;

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

  1. Create object marks that support your use case.

  2. Classify objects into marked groups by assigning marks to filtered objects.

  3. Define the default operation policy for objects that do not have an explicitly specified mark.

  4. Create policies that apply to individual object marks.

See how:

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 can be manually added / induced / excluded from an object by modifying policy statements of a particular object.

A policy statement has two main properties:

  • markRef - An object reference which specifies the mark.

  • type - An enumeration which specifies the type of the policy statement. The values are:

    • apply - The referenced mark is manually added as an effective mark.

    • exclude - The referenced mark will not be effective, even if another policy may specify it so.

Marking a 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 only supported for shadow objects.

You can use object marks to specify operation policies that can enable or disable specific operations for marked objects.

The supported object operation policies are:

Table 1. Supported object operation policies
Operation Kind Behavior if disabled

add

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

modify

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

delete

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

synchronize

inbound

Shadows with 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 with this operation disabled is excluded from inbound synchronization.

outbound

The membership information regarding entitlement shadows with 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 is not provided by any mappings. Refer to Tolerating Existing Association Values.

The default object operation policy for objects without marks specifying policies is to have all operations enabled. This default can be changed by setting defaultOperationPolicy for specific resource object type definitions.

If an object has multiple effective marks that specify object operation policies, 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. If those values are mixed, the value true takes precedence, and a warning is entered into the log. However, this behavior may be subject to a change in the future.

Object operation policy of protected mark (i.e., locked from automatic operations)
<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 an illegal, suspicious, or interesting state.

Assignment time validity

Assignment time validity has started, ended, or otherwise reached an interesting point in time.

Exclusion violation

Violation of an exclusion policy, such as a segregation of duty violation.

Has assignment

Object has an illegal, suspicious, or interesting assignment.

Has no assignment

Object does not have a required, recommended, or interesting assignment.

Neglected

Mark for an object that is not properly cared for, such as a role that has not been reviewed in a long time.

Object modified

Object was modified in an illegal, suspicious, or interesting way.

Object state

Object is in an illegal, suspicious, or interesting state.

Object time validity

Object time validity has started, ended, or otherwise reached an interesting point in time.

Orphaned

Mark for an object that does not have an owner.

Overassigned

An excessive number of assignees. Usually indicates an object has been assigned too many times, such as a role assigned to too many users.

Requirement violation

Violation of a requirement policy, such as an insufficient clearance.

Suspicious

Mark for a suspicious object. It should be (manually) investigated.

Underassigned

An insufficient number of assignees. Usually indicates a shortage of staff, vacancies, or other understaffing situations.

Understaffed security

Mark for a security role or responsibility that is not properly staffed, i.e., it is not assigned to users according to a 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

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 objects marked as Unmanaged are 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 that should not be updated automatically by synchronization, but may be edited / deleted manually later.

Correlate later

No

No

Yes

Yes

Yes

Shadow object that can not be correlated automatically and should be skipped during synchronization.

Do not touch

No

No

No

No

No

Shadow object that we do not want to be synchronized / modified by midPoint. Used in the same way as "Protected" when you have different reasons than for the "Protected" mark.

Invalid data

No

No

No

No

No

Shadow object that has bad data and should be ignored by synchronization. Used in the same way as "Protected" but with a different semantic meaning.

Best practices

  • Use clear and descriptive names for marks, such as "inactive", "requires-approval", or "archived".

  • Consider the granularity of your marks. Too many marks can complicate management, while too few may not provide sufficient differentiation.

  • Regularly audit marks to ensure they are still relevant and accurately reflect the state of the objects.

See also

Compliance

This feature is related to the following compliance frameworks:

Was this page helpful?
YES NO
Thanks for your feedback