Object Marks

Last modified 20 Nov 2024 11:13 +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

Introduction
Basic Concepts
- Effective Marks
- Policy Statements
Object Operation Policy
- Built-in Object Marks
- Shadow Policy Marks

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

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

Objects can be manually marked using midPoint GUI.

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.

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.

Shadow Policy Marks can be also assigned manually using midPoint GUI.

Table 1. 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.
Unmanaged	Yes	No	No	No	No	Shadow object marked as `Unmanaged` is tolerated by midPoint, but not managed by it.
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