[midPoint] direct outbound group association on resource level

Yakov Revyakin yrevyakin at gmail.com
Mon Sep 8 15:03:08 CEST 2025


Hi again,
After some debugging, what became clear for me:

When we create an outbound provisioning rule for an association in UI,
Midpoint creates an XML construct with expression based on
AssociationConstructionExpressionEvaluatorType. Visually this results
in associationConstruction as expression type.
AssociationConstructionExpressionEvaluator always uses roles as a source
for association. It checks eligibility of roles, so only application roles
with appropriate projection in place are allowed as a source. This means
that it is impossible to create an outbound provision rule in UI to link an
arbitrary group of appropriate entitlement object type with the account
projection. At least for 4.9.4.

We still can define another type of evaluation using assignmentTargetSearch
instead of associationConstruction but only directly in XML code. This way
breaks the resource UI view - we can't enter the resource page in the UI.
This completely blocks further resource development with resource UI. Also,
in this case AssociationTargetSearchExpressionEvaluator is used instead of
ReferenceAttributeTargetSearchExpressionEvaluator which is considered in
context of reference attribute (new associationType).

Probably Radovan Semancik could provide some comments and plans on this
part as he is a developer of these evaluators.




On Tue, 2 Sept 2025 at 14:20, Yakov Revyakin <yrevyakin at gmail.com> wrote:

> Thank you Wim,
> My case is a bit different. As I understand,  <associationFromLink/>
> supposes a role-like object with a group projection. This works fine where
> I need it.
> My task is how to add an AD account of a specific object type to a
> specific AD group not involving any roles. All appropriate accounts must
> have this specific group if they are listed under user projections
> (accounts imported and linked to user). I have an appropriate group object
> type as well as association type I mentioned in the 2nd post. Earlier I was
> able to implement this in the old style <association> as presented in the
> beginning of my 1st post.
> Actually I can implement required behavior but my implementation breaks
> the UI - I can't enter the resource page after uploading the resource xml.
> Reconciliation task works fine for me.
>
> <associationType>
>     <name>computer-app</name>
>     <subject>
>         <objectType>
>             <kind>account</kind>
>             <intent>computer</intent>
>         </objectType>
>         <association>
>             <ref>ri:computer-app</ref>
>             <sourceAttributeRef>ri:group</sourceAttributeRef>
>             <outbound>
>                 <name>computer-app</name>
>                 <expression>
>                     <associationTargetSearch>
>                         <filter>
>                             <q:equal>
>                                 <q:path>attributes/ri:cn</q:path>
>                                 <q:value>all_computers</q:value>
>                             </q:equal>
>                         </filter>
>                         <searchStrategy>onResourceIfNeeded</searchStrategy>
>                     </associationTargetSearch>
>                 </expression>
>             </outbound>
>             <tolerant>false</tolerant>
>         </association>
>     </subject>
>     <object>
>         <objectType>
>             <kind>entitlement</kind>
>             <intent>computer-app</intent>
>         </objectType>
>     </object>
> </associationType>
>
> Each evaluation of this association results in required membership. Even
> documentation for Entitlements and Associations proposes to use
> associationTargetSearch as an alternative of associationFromLink, see
> https://docs.evolveum.com/midpoint/reference/support-4.9/resources/entitlements/#outbound-mappings.
> Also, I can find this approach in samples and tests.
> With the implementation above I get 500 "com.evolveum.midpoint.gui.impl.factory.wrapper.resourceAssociation.AssociationMappingExpressionWrapperFactory.getEvaluator(com.evolveum.midpoint.xml.ns._public.common.common_3.ExpressionType)"
> is null". It probably makes sense because associationTargetSearch is not
> among options provided by provisioning outbound mapping in UI for
> association definition.
>
> So, there are actual questions for now:
> - Is my implementation with associationTargetSearch correct?
> - If yes, what about UI? How to fix it? Is it a bug?
> - If not, what is the right way to implement my requirement without
> breaking the UI?
>
> Thanks,
> Yakov
>
> On Tue, 2 Sept 2025 at 12:10, Wim Beck <Wim.Beck at is4u.be> wrote:
>
>> Hi Yakov,
>>
>>
>>
>> Following configuration works for me (validated on AdLdapConnector v3.8
>> and upwards):
>>
>>
>>
>> In the AD config options define correct object classes and use the
>> managed association pairs:
>>
>>
>>
>> <connectorConfiguration>
>>
>>     <icfc:configurationProperties>
>>
>>           [...]
>>
>> <cfc:managedAssociationPairs>"user"+memberOf -#
>> "group"+member</cfc:managedAssociationPairs>
>>
>>             <cfc:managedAssociationPairs>"group"+memberOf -#
>> "group"+member</cfc:managedAssociationPairs>
>>
>>
>> <cfc:attributesNotReturnedByDefault>member</cfc:attributesNotReturnedByDefault>
>>
>>             <cfc:userObjectClass>user</cfc:userObjectClass>
>>
>>             <cfc:groupObjectClass>group</cfc:groupObjectClass>
>>
>>
>> <cfc:groupObjectMemberAttribute>member</cfc:groupObjectMemberAttribute>
>>
>>     </icfc:configurationProperties>
>>
>> </connectorConfiguration>
>>
>>
>>
>> Define object type(s) you need. The association type handles the rest.
>> Sample below handles user/group relation. You can define similar
>> association between other kind/intent objects in a similar way.
>>
>>
>>
>> <associationType id="273">
>>
>>             <name>Account-Group</name>
>>
>>             <subject>
>>
>>                 <objectType id="274">
>>
>>                     <kind>account</kind>
>>
>>                     <intent>Account</intent>
>>
>>                 </objectType>
>>
>>                 <association>
>>
>>                     <ref>ri:group</ref>
>>
>>                     <sourceAttributeRef>ri:group</sourceAttributeRef>
>>
>>                     <outbound id="289">
>>
>>                         <name>account-mapping</name>
>>
>>                         <strength>strong</strength>
>>
>>                         <expression>
>>
>>                             <associationConstruction
>> xsi:type="c:AssociationConstructionExpressionEvaluatorType">
>>
>>                                 <objectRef id="291">
>>
>>                                     <ref>ri:group</ref>
>>
>>                                     <mapping id="292">
>>
>>                                         <name>membership</name>
>>
>>                                         <strength>strong</strength>
>>
>>                                         <expression>
>>
>>                                             <associationFromLink/>
>>
>>                                         </expression>
>>
>>                                     </mapping>
>>
>>                                 </objectRef>
>>
>>                             </associationConstruction>
>>
>>                         </expression>
>>
>>                     </outbound>
>>
>>                 </association>
>>
>>             </subject>
>>
>>             <object id="284">
>>
>>                 <objectType id="285">
>>
>>                     <kind>entitlement</kind>
>>
>>                     <intent>Group</intent>
>>
>>                 </objectType>
>>
>>             </object>
>>
>> </associationType>
>>
>>
>>
>> Hope this helps!
>>
>>
>>
>> Kind regards,
>>
>> *Wim Beck | *Identity Expert @ *IS4U*
>>
>>
>>
>> *From:* midPoint <midpoint-bounces at lists.evolveum.com> *On Behalf Of *Yakov
>> Revyakin via midPoint
>> *Sent:* Friday, 29 August 2025 10:24
>> *To:* midPoint General Discussion <midpoint at lists.evolveum.com>
>> *Cc:* Yakov Revyakin <yrevyakin at gmail.com>
>> *Subject:* Re: [midPoint] direct outbound group association on resource
>> level
>>
>>
>>
>> My associationType
>> <associationType>
>>     <name>computer-app</name>
>>     <subject>
>>         <objectType>
>>             <kind>account</kind>
>>             <intent>computer</intent>
>>         </objectType>
>>         <association>
>>             <ref>ri:computer-app</ref>
>>             <sourceAttributeRef>ri:group</sourceAttributeRef>
>>             <tolerant>false</tolerant>
>>         </association>
>>     </subject>
>>     <object>
>>         <objectType>
>>             <kind>entitlement</kind>
>>             <intent>computer-app</intent>
>>         </objectType>
>>     </object>
>> </associationType>
>>
>>
>>
>> On Fri, 29 Aug 2025 at 11:20, Yakov Revyakin <yrevyakin at gmail.com> wrote:
>>
>> Hi everyone,
>> I'm trying to migrate my AD resource using 4.9 associationType concept.
>>
>> For now I can't understand how to migrate the following part:
>> An account objectType includes static group association which looks like:
>>
>> <association>
>>     <ref>ri:group</ref>
>>     <tolerant>false</tolerant>
>>     <kind>entitlement</kind>
>>     <intent>computer-app</intent>
>>     <outbound>
>>         <expression>
>>             <associationTargetSearch>
>>                 <filter>
>>                     <q:equal>
>>                         <q:path>attributes/ri:cn</q:path>
>>                         <q:value>all_computers</q:value>
>>                     </q:equal>
>>                 </filter>
>>                 <searchStrategy>onResourceIfNeeded</searchStrategy>
>>             </associationTargetSearch>
>>         </expression>
>>     </outbound>
>>     ....
>> </association>
>>
>>
>>
>> This association results in association of this specific group with an AD
>> account if it's appearing under user's projections. There are no roles,
>> assignments, inducements to get this kind of association. This account can
>> be imported and linked only. Create capability for it is denied.
>>
>> It is not clear how to make this kind of association with the new 4.9
>> association types. I defined appropriate associationType but I can't see
>> how to create this association not involving assignment/inducement
>> approach.
>>
>>
>>
>> If someone has an idea or experience please help.
>>
>> Yakov
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20250908/5be98777/attachment-0001.htm>


More information about the midPoint mailing list