[midPoint] midPoint Digest, Vol 154, Issue 17
Ashwill, Steven L
sashwill at uillinois.edu
Thu Feb 27 20:31:34 CET 2025
In response to a request for a more specific use case, the full details follow.
In the simplest form, we manage the password for users on an AD resource. The owner of the AD creates users, delete users and of course updates other attributes on that user.
We had a livesync task set up, unfortunately, there are times that they will update tens of thousands of user attributes when making global changes. What it seemed like to me was that midpoint had to process all of those updates and the creates and deletes were now buried. It also slowed midpoint down in all other activities while trying to process all of these events.
What I was hoping to find was a way for the task to only read create (usnCreated) and ignore everything else instead of processing everything.
-----Original Message-----
From: midPoint <midpoint-bounces at lists.evolveum.com> On Behalf Of midpoint-request at lists.evolveum.com
Sent: Thursday, February 27, 2025 3:18 AM
To: midpoint at lists.evolveum.com
Subject: midPoint Digest, Vol 154, Issue 17
Send midPoint mailing list submissions to
midpoint at lists.evolveum.com
To subscribe or unsubscribe via the World Wide Web, visit
https://urldefense.com/v3/__https://lists.evolveum.com/mailman/listinfo/midpoint__;!!DZ3fjg!_b5gUkTVnALNGm3hVeU05qsrb_On5N6JsyyNx9xWhcn2efHttN6crh-kLrVVGlZhu6wwHRjLL7FgJ7xzePI8h2mY_KA1ZxByCGPpvw$
or, via email, send a message with subject or body 'help' to
midpoint-request at lists.evolveum.com
You can reach the person managing the list at
midpoint-owner at lists.evolveum.com
When replying, please edit your Subject line so it is more specific than "Re: Contents of midPoint digest..."
Today's Topics:
1. Re: limiting livesync AD work (Matus Macik)
2. Override default approval policy (Jussi Jokela)
3. creating my first connector - unable to comprehend group
management (Odd Arne Beck)
4. Table Layout Adjustment for Better Clarity, MidPoint 4.8
(Puchta Jaroslav Ing.)
----------------------------------------------------------------------
Message: 1
Date: Wed, 26 Feb 2025 16:04:01 +0100 (CET)
From: Matus Macik <matus.macik at evolveum.com>
To: midPoint General Discussion <midpoint at lists.evolveum.com>
Subject: Re: [midPoint] limiting livesync AD work
Message-ID:
<1801336681.320368.1740582241827.JavaMail.zimbra at evolveum.com>
Content-Type: text/plain; charset=utf-8
Hello,
This behavior can be achieved as mentioned, via the Synchronization > Reaction configuration of the object class you wish to limit.
In the reaction to a synchronization situation, you can specify the channel to which this reaction is limited. In your case, we can use the "objectImport" channel in reaction to the "linked" situation.
The configuration snipped could look somewhat like this:
<synchronization>
<reaction>
<situation>unmatched</situation>
<actions>
<addFocus/>
</actions>
</reaction>
<reaction>
<situation>unlinked</situation>
<actions>
<link/>
</actions>
</reaction>
<reaction>
<situation>linked</situation>
<channel>https://urldefense.com/v3/__http://midpoint.evolveum.com/xml/ns/public/model/channels-3*objectImport__;Iw!!DZ3fjg!_b5gUkTVnALNGm3hVeU05qsrb_On5N6JsyyNx9xWhcn2efHttN6crh-kLrVVGlZhu6wwHRjLL7FgJ7xzePI8h2mY_KA1ZxBMgCUKZA$ </channel>
<actions>
<synchronize/>
</actions>
</reaction>
</synchronization>
With this configuration present, the execution of a reconciliation or LiveSync task should end up with the requested result.
Please have a look in our documentation regarding channels: https://urldefense.com/v3/__https://docs.evolveum.com/midpoint/reference/support-4.9/resources/resource-configuration/schema-handling/synchronization/__;!!DZ3fjg!_b5gUkTVnALNGm3hVeU05qsrb_On5N6JsyyNx9xWhcn2efHttN6crh-kLrVVGlZhu6wwHRjLL7FgJ7xzePI8h2mY_KA1ZxCpS1vwQA$
Additionally, could you provide a more specific example of the use case you have in mind? Maybe there is an alternative solution or approach.
Best Regards,
Mat?? Mac?k | Identity and Access Management Engineer
[ https://urldefense.com/v3/__https://evolveum.com/__;!!DZ3fjg!_b5gUkTVnALNGm3hVeU05qsrb_On5N6JsyyNx9xWhcn2efHttN6crh-kLrVVGlZhu6wwHRjLL7FgJ7xzePI8h2mY_KA1ZxA7p8vgsA$ ] [ mailto:matus.macik at evolveum.com | matus.macik at evolveum.com ] | [ https://urldefense.com/v3/__http://www.evolveum.com/__;!!DZ3fjg!_b5gUkTVnALNGm3hVeU05qsrb_On5N6JsyyNx9xWhcn2efHttN6crh-kLrVVGlZhu6wwHRjLL7FgJ7xzePI8h2mY_KA1ZxCHpXeekg$ | https://urldefense.com/v3/__http://www.evolveum.com__;!!DZ3fjg!_b5gUkTVnALNGm3hVeU05qsrb_On5N6JsyyNx9xWhcn2efHttN6crh-kLrVVGlZhu6wwHRjLL7FgJ7xzePI8h2mY_KA1ZxAIIvbyrw$ ]
[ https://urldefense.com/v3/__https://evolveum.com/upcoming-events/__;!!DZ3fjg!_b5gUkTVnALNGm3hVeU05qsrb_On5N6JsyyNx9xWhcn2efHttN6crh-kLrVVGlZhu6wwHRjLL7FgJ7xzePI8h2mY_KA1ZxCvwOAkJA$ | ]
[ https://urldefense.com/v3/__https://www.linkedin.com/company/evolveum__;!!DZ3fjg!_b5gUkTVnALNGm3hVeU05qsrb_On5N6JsyyNx9xWhcn2efHttN6crh-kLrVVGlZhu6wwHRjLL7FgJ7xzePI8h2mY_KA1ZxAjfCZdCg$ ] [ https://urldefense.com/v3/__https://twitter.com/evolveum__;!!DZ3fjg!_b5gUkTVnALNGm3hVeU05qsrb_On5N6JsyyNx9xWhcn2efHttN6crh-kLrVVGlZhu6wwHRjLL7FgJ7xzePI8h2mY_KA1ZxAzPZmwiQ$ ] [ https://urldefense.com/v3/__https://www.facebook.com/evolveum__;!!DZ3fjg!_b5gUkTVnALNGm3hVeU05qsrb_On5N6JsyyNx9xWhcn2efHttN6crh-kLrVVGlZhu6wwHRjLL7FgJ7xzePI8h2mY_KA1ZxBPdU1KYQ$ ]
Disclaimer: The contents of this e-mail and attachment(s) thereto are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or Evolveum s.r.o. or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of Evolveum s.r.o. or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately.
----- Original Message -----
From: "midPoint General Discussion" <midpoint at lists.evolveum.com>
To: "midPoint General Discussion" <midpoint at lists.evolveum.com>
Cc: "mikhail.nikolaenko" <mikhail.nikolaenko at proton.me>
Sent: Tuesday, February 25, 2025 10:29:32 AM
Subject: Re: [midPoint] limiting livesync AD work
Hello,
I am very new to the midPoint and only reading the book and playing with local test instance, but I guess it should be possible using just synchronization configuration in the object type (Resource -> Schema handling -> your object type -> synchronization).
You need situations:
Unmatched - means there is a new account so you define action: link Deleted - unlink
Hope I am right and it helps :-)
With best regards,
Mike
Sent with Proton Mail secure email.
On Friday, 21 February 2025 at 4:48 PM, Ashwill, Steven L via midPoint <midpoint at lists.evolveum.com> wrote:
> Hello,
> Is there a way that we can limit the livesync task in 4.8.x to simply
> pick up create events? Once a user is created and we have them linked,
> we no longer want to react to changes in the AD. Midpoint has
> authority on the mappings we control and we ignore everything else in
> the AD and therefore we don't want to process the 1000s of updates
> that occur daily. We just want to react to a create or delete of a
> user in the AD and link or unlink the user we have in midpoint
>
>
> STEVEN L ASHWILL
> Software Engineer Coordinator
>
>
>
> Under the Illinois Freedom of Information Act any written communication to or from university employees regarding university business is a public record and may be subject to public disclosure.
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> https://urldefense.com/v3/__https://lists.evolveum.com/mailman/listinf
> o/midpoint__;!!DZ3fjg!_b5gUkTVnALNGm3hVeU05qsrb_On5N6JsyyNx9xWhcn2efHt
> tN6crh-kLrVVGlZhu6wwHRjLL7FgJ7xzePI8h2mY_KA1ZxByCGPpvw$
_______________________________________________
midPoint mailing list
midPoint at lists.evolveum.com
https://urldefense.com/v3/__https://lists.evolveum.com/mailman/listinfo/midpoint__;!!DZ3fjg!_b5gUkTVnALNGm3hVeU05qsrb_On5N6JsyyNx9xWhcn2efHttN6crh-kLrVVGlZhu6wwHRjLL7FgJ7xzePI8h2mY_KA1ZxByCGPpvw$
------------------------------
Message: 2
Date: Wed, 26 Feb 2025 15:27:33 +0200
From: Jussi Jokela <jussi.jokela92 at gmail.com>
To: midpoint at lists.evolveum.com
Subject: [midPoint] Override default approval policy
Message-ID:
<CABQ2MC_s5rwJ=DhqFp97CFpoY4_pUL=F4GNzmV3eR3NT+uv3sw at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I'm having difficulties overriding my "default approver" policy. I have two metaroles, one for default approver and one for "high risk systems" (for
example) and
and the default approver is inherited from another metarole which is used when creating new roles and the high risk metarole is assigned when the created role requires it.
The high risk metarole has the <mergeOverwriting>true</mergeOverwriting>
but it does not seem to have effect. When the default approver and high risk system metaroles are induced to created role, both policy stages require manual approval when the desired outcome is just to approve the high risk system (all must approve) as it has lower order (higher priority).
Here are the code snippets for both policy metaroles and the metarole that includes the default approver policy:
* <displayName>Metarole: High risk systems</displayName> <inducement
id="1"> <policyRule> <policyConstraints>
<assignment> <operation>add</operation>
</assignment> </policyConstraints> <policyActions>
<approval id="3"> <compositionStrategy>
<order>5</order>
<mergeOverwriting>true</mergeOverwriting>
</compositionStrategy> <approvalSchema>
<stage id="4"> <name>Security</name>
<approverRef relation="org:default"
type="c:OrgType"> <filter>
<q:text>name="High_risk_systems"</q:text>
</filter>
<resolutionTime>run</resolutionTime>
</approverRef>
<evaluationStrategy>allMustApprove</evaluationStrategy>
<outcomeIfNoApprovers>reject</outcomeIfNoApprovers>
<groupExpansion>onWorkItemCreation</groupExpansion>
</stage> </approvalSchema>
</approval> </policyActions> </policyRule>
</inducement> <displayName>Default approver</displayName> <inducement
id="1"> <policyRule> <policyConstraints>
<assignment> <operation>add</operation>
</assignment> </policyConstraints> <policyActions>
<approval id="16"> <compositionStrategy>
<order>50</order>
</compositionStrategy> <approvalSchema>
<stage id="17"> <name>Default
approver</name> <approverRef
relation="org:default" type="c:OrgType">
<filter> <q:text>name="Default
approver"</q:text> </filter>
<resolutionTime>run</resolutionTime>
</approverRef>
<evaluationStrategy>firstDecides</evaluationStrategy>
<outcomeIfNoApprovers>reject</outcomeIfNoApprovers>
<groupExpansion>onWorkItemCreation</groupExpansion>
</stage> </approvalSchema>
</approval> </policyActions> </policyRule>
</inducement>*
* <inducement id="59"> <targetRef
oid="7c1a3009-b456-40e6-a160-be32f70c1c7c" (default approver)
relation="org:default" type="c:RoleType"/> </inducement>*
Hope my goal is clear. :)
Best regards,
Jussi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://urldefense.com/v3/__https://lists.evolveum.com/pipermail/midpoint/attachments/20250226/81ad7911/attachment-0001.htm__;!!DZ3fjg!_b5gUkTVnALNGm3hVeU05qsrb_On5N6JsyyNx9xWhcn2efHttN6crh-kLrVVGlZhu6wwHRjLL7FgJ7xzePI8h2mY_KA1ZxBHNL6VVA$ >
------------------------------
Message: 3
Date: Wed, 26 Feb 2025 20:21:40 +0100
From: Odd Arne Beck <oddbeck at gmail.com>
To: midpoint at lists.evolveum.com
Subject: [midPoint] creating my first connector - unable to comprehend
group management
Message-ID:
<CAKjv1x4c1c2ozyO0ct6dEtdQ=2yZeYdaY1rc2tYVzyO904x7Ww at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi!
I am on Midpoint 4.9.1 and I am trying to figure out developing a connector and getting to know the framework for connectors. I've studied several other connectors and their source code in the process.
I'm creating a basic connector for sqlite creating tables Users, Groups and UsersGroups (mapping table for group membership). I use the hibernate ORM for the database part.
As of now my connector is able to create the Users, and any roles (groups) are also created through entitlements in the 'Groups' table.
However, when I assign a user to a group the create() / executeQuery() /
Update() and similar methods are triggered but I am not able to see anywhere a ref to a user ID or something similar that I can use in order to inject the UserId + GroupId into my "UsersGroups" table.
I am pretty sure I've set up the associations accordingly to the docs for 4.9.1.
What am I missing or not understanding?
Thanks for any advice and help.
Best regards,
Odd Beck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://urldefense.com/v3/__https://lists.evolveum.com/pipermail/midpoint/attachments/20250226/69a216a7/attachment-0001.htm__;!!DZ3fjg!_b5gUkTVnALNGm3hVeU05qsrb_On5N6JsyyNx9xWhcn2efHttN6crh-kLrVVGlZhu6wwHRjLL7FgJ7xzePI8h2mY_KA1ZxCqHBeVdg$ >
------------------------------
Message: 4
Date: Thu, 27 Feb 2025 09:17:25 +0000
From: Puchta Jaroslav Ing. <puchta.jaroslav at cpost.cz>
To: "midpoint at lists.evolveum.com" <midpoint at lists.evolveum.com>
Subject: [midPoint] Table Layout Adjustment for Better Clarity,
MidPoint 4.8
Message-ID:
<DB9P189MB2097249279AB53442433A3B79DCD2 at DB9P189MB2097.EURP189.PROD.OUTLOOK.COM>
Content-Type: text/plain; charset="utf-8"
Hi everyone,
I would like to request your help with adjusting the layout of tables with roles. Currently, the description column takes up about 8/12 of the table's width, which causes line breaks for roles or service names. This line breaking makes it difficult to visually locate roles in the table.
I propose increasing the column width where the display names are shown to make it easier to find roles in the table. On the other hand, line breaks in the description column are not as problematic.
Best regards,
J.Puchta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://urldefense.com/v3/__https://lists.evolveum.com/pipermail/midpoint/attachments/20250227/5300b5b7/attachment.htm__;!!DZ3fjg!_b5gUkTVnALNGm3hVeU05qsrb_On5N6JsyyNx9xWhcn2efHttN6crh-kLrVVGlZhu6wwHRjLL7FgJ7xzePI8h2mY_KA1ZxBGksul0w$ >
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2812 bytes
Desc: not available
URL: <https://urldefense.com/v3/__https://lists.evolveum.com/pipermail/midpoint/attachments/20250227/5300b5b7/attachment.bin__;!!DZ3fjg!_b5gUkTVnALNGm3hVeU05qsrb_On5N6JsyyNx9xWhcn2efHttN6crh-kLrVVGlZhu6wwHRjLL7FgJ7xzePI8h2mY_KA1ZxApKjXWTw$ >
------------------------------
Subject: Digest Footer
_______________________________________________
midPoint mailing list
midPoint at lists.evolveum.com
https://urldefense.com/v3/__https://lists.evolveum.com/mailman/listinfo/midpoint__;!!DZ3fjg!_b5gUkTVnALNGm3hVeU05qsrb_On5N6JsyyNx9xWhcn2efHttN6crh-kLrVVGlZhu6wwHRjLL7FgJ7xzePI8h2mY_KA1ZxByCGPpvw$
------------------------------
End of midPoint Digest, Vol 154, Issue 17
*****************************************
More information about the midPoint
mailing list