From Pilar-von-Pilchau.Wenzel at akdb.de  Mon Jun  1 11:19:40 2026
From: Pilar-von-Pilchau.Wenzel at akdb.de (Pilar von Pilchau Wenzel - AKDB)
Date: Mon, 1 Jun 2026 09:19:40 +0000
Subject: [midPoint] Role Inducements via OrgType Archtype
Message-ID: <DB8P193MB0533779FD0B46A6BD4CEE3D683152@DB8P193MB0533.EURP193.PROD.OUTLOOK.COM>

Hi,

I have two questions.

First, I have an organizational structure, and I created an archtype for that. I assigned the archtype to each org unit. So, my basic structure looks like this:


  *
TOP -> archtype
     *
Level 1 -> archtype
        *
Level 2 -> archtype


What I want to achieve is to assign a role "people lead" to a manager of an org unit. To achieve this, I created an inducement like this:


<inducement id="6">
    <description>
        Grant int:role:people_lead to any user who holds the org:manager relation to an org with this archetype.
    </description>
    <targetRef oid="b19672ea-66e0-45c2-8565-1715a4e6488f" relation="org:default" type="c:RoleType"/>
    <orderConstraint id="9">
        <relation>manager</relation>
   </orderConstraint>
</inducement>

A manager of org unit: level2 gets an indirect assignment of the people lead role but in the UI I can see three source chains (one from every org unit).
I used this condition to have only one source chain (from level 2):

<condition>
   <expression>
       <script>
           <code>
               assignmentPath?.segments?.size() == 3 &amp;&amp;
                       assignment?.targetRef?.relation?.localPart == 'manager'
           </code>
       </script>
   </expression>
</condition>

I wonder if this is the intended way or if I have some fundamental misunderstandings here?

My second question refers to parametric assignments.
In another org structure I want to assign roles with a parameter that is a reference to the org unit that assigns a role "Application User". I created an archtype again but as far as I noticed I can only use static values in the assignment parameters when using an inducement. I suppose I have to use focusMappings here (with assignmentTargetSearch and populateItem).
Is this the intended way?

Happy for any help here.

Best regards

Dr. Wenzel Pilar von Pilchau
Prozessanalyst
Process Management & Digitalisation
[Mobile]  +49 162 2530060
[Email]  Pilar-von-Pilchau.Wenzel at akdb.de<mailto:Pilar-von-Pilchau.Wenzel at akdb.de>
AKDB ? Anstalt des ?ffentlichen Rechts
Hansastra?e 12-16 ? 80686 M?nchen
www.akdb.de<https://www.akdb.de/>
[AKDB Logo]
[Great Place to Work Certified]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20260601/828f2348/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-Mobile.png
Type: image/png
Size: 404 bytes
Desc: Outlook-Mobile.png
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20260601/828f2348/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-Email.png
Type: image/png
Size: 924 bytes
Desc: Outlook-Email.png
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20260601/828f2348/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-AKDB Logo.png
Type: image/png
Size: 3456 bytes
Desc: Outlook-AKDB Logo.png
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20260601/828f2348/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-Great Plac.png
Type: image/png
Size: 72182 bytes
Desc: Outlook-Great Plac.png
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20260601/828f2348/attachment-0007.png>

From mederly at evolveum.com  Mon Jun  1 18:29:36 2026
From: mederly at evolveum.com (Pavol Mederly)
Date: Mon, 1 Jun 2026 18:29:36 +0200
Subject: [midPoint] Task UI Breakdown (NullPointerException / Quartz
 Desync) After Logical Dump/Restore in midPoint HA Cluster (CloudNativePG)
In-Reply-To: <CANfuxmoeBe5VZyw_ZojB+Cxn-9UDLkB1-fGW=1Gg-X92208BrA@mail.gmail.com>
References: <CANfuxmoeBe5VZyw_ZojB+Cxn-9UDLkB1-fGW=1Gg-X92208BrA@mail.gmail.com>
Message-ID: <18ddee8c-bb13-4e42-94b1-44848e1fa911@evolveum.com>

Hello K,

after

> 2026-05-26 16:12:39,854 [TASK_MANAGER] [http-nio-8080-exec-1] ERROR 
> (com.evolveum.midpoint.task.quartzimpl.quartz.TaskSynchronizer): 
> Cannot synchronize repository/Quartz Job Store information for task 
> Task(id:1769760974026-44018-1, name:Export task for IGA: Who has 
> access to what and why No3 (2026-01-30 17:16:13), 
> oid:f764fb6c-c433-4cad-ac1e-ec2dd5958bbd).
>
you should get a full stack trace, indicating the source of the problem.

You may consider providing it here, maybe someone would be able to help you.

Because, in general, I think that backup+restore should not break the tasks.

Best regards,

-- 
Pavol Mederly
Interim Chief Product Officer
evolveum.com

On 26/05/2026 10:49, Frost K via midPoint wrote:
> Dear midPoint community
>
> Hi, I'm K from Japan.
>
> We are facing a critical issue where the Task management UI completely 
> crashes after restoring a logical database dump (pg_dump -U postgres 
> -Fc) into a new database instance via GitHub Actions.
>
>
> After restoring, other pages (Users, Roles, Resources) work 100% 
> perfectly with full read/write capabilities. Only Tasks are broken.
>
>
> Could you please review our configuration and logs below?
>
>
> Infrastructure: midPoint HA Cluster on AWS EKS (Main / Replica)
>
> Database: Managed by CloudNativePG (CNPG)
>
> Data Size: 1400MB
>
>
> *?commands for backup/restore?*
>
>
> ?: dump command
>
> ==========================
>
> kubectl exec -n $NAMESPACE $POD_NAME -c $TARGET_CONTAINER -- \
> ? pg_dump -U postgres -Fc "$DB" -f 
> /var/lib/postgresql/data/backup.dump; then
>
> kubectl cp 
> ${NAMESPACE}/${POD_NAME}:var/lib/postgresql/data/backup.dump 
> "$BACKUP_FILE" -c $TARGET_CONTAINER
>
> kubectl exec -n $NAMESPACE $POD_NAME -c $TARGET_CONTAINER -- rm 
> /var/lib/postgresql/data/backup.dump
>
> ==========================
>
>
>
> ?: restore command
>
> ==========================
>
> kubectl exec -n $NAMESPACE $PRIMARY_POD -c $CONTAINER_NAME -- \
> ? env PGOPTIONS="-c default_transaction_read_only=off" \
> ? psql -U postgres -c "CREATE DATABASE $NEW_DB OWNER postgres;" 2>&1 
> >> $GITHUB_STEP_SUMMARY;
>
> kubectl exec -n $NAMESPACE $PRIMARY_POD -c $CONTAINER_NAME -i -- \
> ? env PGOPTIONS="-c default_transaction_read_only=off" \
> ? pg_restore -U postgres -d "$NEW_DB" \
> ? --clean --if-exists --no-owner --no-privileges --verbose < 
> ./restore.dump 2>&1
>
> ==========================
>
>
> Our backup methods are show below.
>
> ?: create a new database.(database name: AAAAA_YYYYMMDD_HHMMSS)
> ?: grant permissions such as ones related to scheme)
> ?: delete a current used DB whom name is AAAA
>
> ?: rename ?'s database(AAAAA_YYYYMMDD_HHMMSS ? AAAAA)
> ?: the name defined in the configuration file of a cluster would 
> matches ?'s database name.
> ? ? That means it could be restored properly.
>
>
>
> *?The UI error message?*
>
> After the restore completes, User, Role, and Resource management UI 
> pages work 100% perfectly.
>
>
> We can create and modify users manually without any database write 
> errors. However, the Task management UI completely crashes.
>
>
> 1. Accessing the task list or trying to create a new task results in 
> an immediate Wicket error:
>
>
> ==========================
>
> ? org.apache.wicket.WicketRuntimeException: Error attaching this 
> container for rendering: [WebMarkupContainer [Component id = body]]
>
> ==========================
>
>
> 2: During pod startup and task page initialization, midPoint's 
> TaskSynchronizer attempts to reconcile the midPoint repo (m_task) with 
> the Quartz job store (qrtz_ tables).
> It logs that it successfully purges 54 ghost/orphaned tasks that do 
> not exist in the repo:
>
>
> ==========================
>
> *?An error on UI?*
>
> Cannot list jobs from Quartz scheduler, skipping second part of 
> synchronization procedure.
>
>
> *?An error on log?*
>
> 2026-05-26 16:12:39,859 [] [http-nio-8080-exec-1] INFO 
> (com.evolveum.midpoint.task.quartzimpl.quartz.TaskSynchronizer): 
> Synchronization of midpoint and Quartz tasks store finished. 
> Processing of 0 task(s) existing in midPoint repository has been 
> successful, while processing of 0 task(s) has failed. 0 task(s) has 
> been updated and 54 task(s) has been removed from Quartz job store, 
> because they are not present in midPoint repository."
>
> ==========================
>
> *?Logs & Analysis?
> *
> During pod startup and task page initialization, midPoint's 
> TaskSynchronizer attempts to reconcile the midPoint repo (m_task) with 
> the Quartz job store (qrtz_ tables). It logs that it successfully 
> purges 54 ghost/orphaned tasks that do not exist in the repo:
>
>
> =========================
>
> 2026-05-26 16:12:39,859 [] [http-nio-8080-exec-1] INFO 
> (com.evolveum.midpoint.task.quartzimpl.quartz.TaskSynchronizer): 
> Synchronization of midpoint and Quartz tasks store finished. 
> Processing of 0 task(s) existing in midPoint repository has been 
> successful, while processing of 0 task(s) has failed. 0 task(s) has 
> been updated and 54 task(s) has been removed from Quartz job store, 
> because they are not present in midPoint repository."
>
> =========================
>
>
> But right after, it throws a fatal NullPointerException during UI 
> rendering because it cannot resolve the execution state/times:
>
>
> =========================
> java.lang.NullPointerException: Cannot invoke 
> "com.evolveum.midpoint.task.quartzimpl.quartz.NextStartTimes.getNextScheduledRun()" 
> because "times" is null
>
> 2026-05-26 16:20:59,031 [] [http-nio-8080-exec-2] ERROR 
> (com.evolveum.midpoint.gui.impl.component.data.provider.SelectableBeanContainerDataProvider): 
> Couldn't list objects.
>
> 2026-05-26 16:20:59,031 [MODEL] [http-nio-8080-exec-2] WARN 
> (com.evolveum.midpoint.model.impl.controller.ModelController): 
> Couldn't search objects in task manager, reason: Cannot invoke 
> "com.evolveum.midpoint.task.quartzimpl.quartz.NextStartTimes.getNextScheduledRun()" 
> because "times" is null (class java.lang.NullPointerException)
>
> ==========================
>
>
> Please refer to some log data too
>
> ==========================
>
> 2026-05-26 16:12:39,854 [TASK_MANAGER] [http-nio-8080-exec-1] ERROR 
> (com.evolveum.midpoint.task.quartzimpl.quartz.TaskSynchronizer): 
> Cannot synchronize repository/Quartz Job Store information for task 
> Task(id:1769760974026-44018-1, name:Export task for IGA: Who has 
> access to what and why No3 (2026-01-30 17:16:13), 
> oid:f764fb6c-c433-4cad-ac1e-ec2dd5958bbd).
>
>
> org.apache.wicket.WicketRuntimeException: Error attaching this 
> container for rendering: [WebMarkupContainer [Component id = body]]
> 2026-05-26 16:20:59,033 [] [http-nio-8080-exec-2] WARN 
> (com.evolveum.midpoint.web.page.error.PageError): Creating error page 
> for code org.apache.wicket.WicketRuntimeException, exception Error 
> attaching this container for rendering: [WebMarkupContainer [Component 
> id = body]]: {}
>
>
> Caused by: java.lang.NullPointerException: Cannot invoke 
> "com.evolveum.midpoint.xml.ns._public.common.common_3.TaskType.getObjectRef()" 
> because the return value of 
> "com.evolveum.midpoint.web.component.util.SelectableBean.getValue()" 
> is null
>
>
> org.apache.wicket.WicketRuntimeException: Error attaching this 
> container for rendering: [WebMarkupContainer [Component id = body]]
>
> 2026-05-26 16:20:59,032 [] [http-nio-8080-exec-2] ERROR 
> (com.evolveum.midpoint.web.security.LoggingRequestCycleListener): 
> Error occurred during page rendering.
>
> ==========================
>
> *?The log data on the main DB?*
>
> The main DB's log data is shown below.
>
> ==========================
>
> {"level":"info","ts":"2026-05-26T07:09:31.926059022Z","logger":"postgres","msg":"record","logging_pod":"postgresql-XXXX-4","record":{"log_time":"2026-05-26 
> 07:09:31.918 
> UTC","user_name":"XXXXXX_user","database_name":"XXXXX5","process_id":"11666","connection_from":"10.0.XX.XX:XXXXX","session_id":"6a15472b.2d92","session_line_num":"1","command_tag":"idle","session_start_time":"2026-05-26 
> 07:09:31 
> UTC","virtual_transaction_id":"13/0","transaction_id":"0","error_severity":"FATAL","sql_state_code":"57P01","message":"terminating 
> connection due to administrator 
> command","application_name":"XXXX-XXXX","backend_type":"client 
> backend","query_id":"0"}}
>
> {"level":"info","ts":"2026-05-26T07:09:31.926071471Z","logger":"postgres","msg":"record","logging_pod":"postgresql-XXXXX-4","record":{"log_time":"2026-05-26 
> 07:09:31.918 
> UTC","user_name":"XXXXX5_user","database_name":"XXXXX5","process_id":"11667","connection_from":"10.0.XX.XX:XXXXX","session_id":"6a15472b.2d93","session_line_num":"1","command_tag":"idle","session_start_time":"2026-05-26 
> 07:09:31 
> UTC","virtual_transaction_id":"15/0","transaction_id":"0","error_severity":"FATAL","sql_state_code":"57P01","message":"terminating 
> connection due to administrator 
> command","application_name":"XXXX-XXXX","backend_type":"client 
> backend","query_id":"0"}}
>
>
> ==========================
>
> *?Questions?*
>
> 1: Has anyone successfully implemented a pure PostgreSQL logical 
> pg_dump/pg_restore strategy for midPoint clusters without running into 
> this Quartz store mismatch?
>
>
> 2: What is the recommended best practice to safely sanitize, unlock, 
> or force-reinitialize the Quartz relational tables (qrtz_*) during an 
> active database migration or environment cloning?
>
>
> 3: Should we explicitly strip task/node types during dump or is there 
> a safe API method to tell midPoint to rebuild its scheduler states 
> from scratch upon target-pointing?
>
>
> Any insights, workarounds, or hidden configuration settings (e.g., 
> TaskManager cluster settings) would be highly appreciated!
>
> Thank you in advance!
> Best regards.
>
> Frost K
> A member of a company in Japan.
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> https://lists.evolveum.com/mailman/listinfo/midpoint
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20260601/12a23b6c/attachment.htm>

From mmares at evolveum.com  Tue Jun  2 12:55:49 2026
From: mmares at evolveum.com (Martin =?utf-8?Q?Mare=C5=A1?=)
Date: Tue, 2 Jun 2026 12:55:49 +0200 (CEST)
Subject: [midPoint] Maintenance releases of midPoint 4.8.12,
 midPoint 4.9.7 and midPoint 4.10.3
Message-ID: <456049669.1378990.1780397749512.JavaMail.zimbra@evolveum.com>



Dear midPoint community, 




the Evolveum team is proud to announce maintenance releases of midPoint 4.8.12, midPoint 4.9.7 and midPoint 4.10.3. 




These releases bring security, stability, and miscellaneous bug fixes. 

You can find the complete release notes describing the changes made in these releases here: 

midPoint 4.8.12 [ https://docs.evolveum.com/midpoint/release/4.8.12/ | https://docs.evolveum.com/midpoint/release/4.8.12/ ] 

midPoint 4.9.7 [ https://docs.evolveum.com/midpoint/release/4.9.7/ | https://docs.evolveum.com/midpoint/release/4.9.7/ ] 

midPoint 4.10.3 [ https://docs.evolveum.com/midpoint/release/4.10.3/ | https://docs.evolveum.com/midpoint/release/4.10.3/ ] 




We would like to express special thanks to all midPoint subscribers, partners, supporters, and contributors. 




Best regards, 

Martin Mare? | Senior Product Manager 
[ mailto:martin.mares at evolveum.com | martin.mares at evolveum.com ] | [ http://www.evolveum.com/ | www.evolveum.com ] 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20260602/61f3de0c/attachment.htm>

From anton.tkacik at evolveum.com  Tue Jun  2 14:57:46 2026
From: anton.tkacik at evolveum.com (Tony Tkacik)
Date: Tue, 2 Jun 2026 14:57:46 +0200 (CEST)
Subject: [midPoint] Security Advisory: Privilege Escalation via Audit Log
Message-ID: <1531641827.1584013.1780405066362.JavaMail.zimbra@evolveum.com>

Date: 2. 6. 2026 
Severity: 9.0 (Critical) 
Affected versions: All midPoint versions prior to 4.8.12, 4.9.7, 4.10.3 
Fixed in versions: 4.8.12, 4.9.7, 4.10.3 

Description 

An authorized user with audit log access can exploit a bug that discloses session identifiers to escalate privileges to system administrator level. 

Note: Audit log access is a high-privilege role in midPoint, as it grants visibility into all system events and sensitive operations. 

This vulnerability requires: 
- Attacker to have authorization for audit log access (high-privilege role) 
- Administrator to be currently logged in 
- Administrator to have performed an audited action 
- Attacker to capture and reuse the session identifier 

Severity and Impact 

This is Critical Severity Issue. 
The authorized user may be able to escalate privileges to administrator-level access, which grants them unrestricted access to the MidPoint. 

Mitigation 

Users of affected midPoint versions are advised to upgrade to the latest maintenance releases: 4.8.12, 4.9.7, or 4.10.3. 

If immediate upgrade is not possible: 

1. Restrict Audit Log Access - Audit log access is a high-privilege role that should only be assigned to administrators 
2. Review audit log viewer assignments - Ensure only trusted administrators have this authorization 

This advisory is also available at [ https://docs.evolveum.com/midpoint/security/advisories/027-privilage-escalation-via-audit-log/ | https://docs.evolveum.com/midpoint/security/advisories/027-privilage-escalation-via-audit-log/ ] 

--- 
Anton Tkacik 
Backend Technical Leader & Developer 
Evolveum s.r.o. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20260602/d8578d44/attachment.htm>

From martin.spanik at evolveum.com  Tue Jun  2 16:36:40 2026
From: martin.spanik at evolveum.com (Martin Spanik)
Date: Tue, 2 Jun 2026 16:36:40 +0200
Subject: [midPoint] Updates to midPoint container images.
Message-ID: <5f2514d2-e9ce-4d9e-98e7-226411060e43@evolveum.com>

Dear midPoint community,

One more update from us today - this time about midPoint container image 
maintenance.

Starting with the new maintenance releases coming these days, midPoint 
container images will receive updates to operating system packages and 
Java runtime components even after the original midPoint release. Until 
now, released container images remained unchanged, and OS or Java 
updates were delivered only with a new midPoint release.

This change will help us address vulnerabilities in the container base 
system and Java runtime faster, typically on daily basis.

Together with this, we are also updating the container image naming 
convention to make image tags clearer and better aligned with common 
Docker practices.

We plan also to switch running midPoint from root to its specific 
non-root user in version 4.11.0. We kept images for already existing 
supported branches (4.8, 4.9 and 4.10) with the root user to avoid 
additional issues during updates.

You can find more information at our docs:

  * https://docs.evolveum.com/midpoint/install/containers/container-image-naming/
    <https://docs.evolveum.com/midpoint/install/containers/container-image-naming/>
  * https://docs.evolveum.com/midpoint/install/containers/container-image-2026-change/
    <https://docs.evolveum.com/midpoint/install/containers/container-image-2026-change/>

Best regards,


Martin Spanik

CISO & Compliance
Evolveum, s.r.o.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20260602/b29377ba/attachment.htm>