[midPoint] Application-role priority enforcement (per service)— prune removing org assignments unexpectedly

[Bao Tran]

Hi Yakov,
Thanks for the suggestion
Firstly , to clarify , our main goal is :  A service has multi
application-role (eg: 0365) , a user John can have multiple org assignments
with different relations → only the highest application-role (E5) wins,
application-role F3 is suppressed



> About additional abstraction. You could assign roles with some custom
> relations (like "custom:license") and process them in the user archetype
> making a decision whether to assign the same one with default relation. In
> this way we replace the default declarative approach with a custom one
> based on scripting.

We considered a similar approach using an extension attribute (e.g.
*extension/m365License*) — compute the winning license in the
person-object-template mapping and provision accordingly. It seems simpler
than the custom relation approach, but we're wondering if there's a more
native fit.

>From a business perspective, the suppression logic feels like it should
live at the service/application layer (or application-roles related to its
app) — each service (e.g. O365) owns its entitlements (application-roles),
and it should be the one enforcing "only one license wins." Pushing that
decision up to the user archetype or extension attributes means every new
service requires a new mapping/custom-attributes/relations, which doesn't
scale well.

Is there a native MidPoint mechanism to define priority/exclusion within a
service or application role set, so the suppression is encapsulated there
rather than in the user archetype (which does not represent the service/app
layer)?

On Fri, Jun 19, 2026 at 4:47 PM Yakov Revyakin <yrevyakin at gmail.com> wrote:

> Actually, I haven't realized that the main question is why Midpoint
> removes orgs. If we move role inducement on org archetype level Midpoint
> doesn't remove orgs. But, from a business perspective, this doesn't
> make any sense. Each org can have a unique set of roles and we'd like to
> define exclusions on a role level. Unfortunately,  even if we move
> inducements to org archetype we can't get the right behaviour. It looks
> like Midpoint processes relations in an unspecified way.
>
> About additional abstraction. You could assign roles with some custom
> relations (like "custom:license") and process them in the user archetype
> making a decision whether to assign the same one with default relation. In
> this way we replace the default declarative approach with a custom one
> based on scripting.
>
> On Thu, 18 Jun 2026 at 09:10, Bao Tran via midPoint <
> midpoint at lists.evolveum.com> wrote:
>
>> Hi Yakiv,
>>
>> Thanks for the response,
>> Would you be able to point us to any documentation or examples on how to
>> implement that abstraction layer in the user archetype? Even a hint or a
>> starting point would be very helpful.
>>
>> On Wed, Jun 17, 2026 at 9:18 PM Yakiv Revyakin <yrevyakin at issp.com>
>> wrote:
>>
>>> Hello Bau,
>>>
>>> My assumption is that the policy doesn’t affect indirect assignments
>>> induced by an org. Till you have certain org assigned it will induce.
>>>
>>> To implement the behavior, you need more complicated approach adding
>>> additional layer of abstraction in user archetype.
>>>
>>>
>>>
>>> *From:* midPoint <midpoint-bounces at lists.evolveum.com> *On Behalf Of *Bao
>>> Tran via midPoint
>>> *Sent:* Wednesday, June 17, 2026 11:33 AM
>>> *To:* midpoint at lists.evolveum.com
>>> *Cc:* Bao Tran <bao.tran at csit.fi>
>>> *Subject:* [midPoint] Application-role priority enforcement (per
>>> service)— prune removing org assignments unexpectedly
>>>
>>>
>>>
>>> Hi all,
>>> We're running into an issue with  priority enforcement for
>>> application-roles for single service in MidPoint and would appreciate any
>>> insight.
>>>
>>> *Our goal: *A service has multi application-role , a user John can have
>>> multiple org assignments with different relations → only the highest
>>> application-role (E5) wins, application-role F3 is suppressed.
>>>
>>> *What we tried (and failed):*
>>>
>>>    - Orgs have 2 inducements:
>>>
>>>
>>>    - → E5 (condition: relation=manager)
>>>       - → F3 (no condition, everyone gets this as base)
>>>
>>>
>>>    - Service O365 has 2 application-roles:
>>>          - E5
>>>          - F3
>>>    - F3 role has an exclusion policy rule → prune when E5 is present:
>>>
>>> <role>
>>>
>>>   <name>F3</name>
>>>
>>>   <assignment>
>>>
>>>     <policyRule>
>>>
>>>       <name>m365-f3-excluded-by-e5</name>
>>>
>>>       <policyConstraints>
>>>
>>>         <exclusion>
>>>
>>>           <targetRef oid="E5" type="c:RoleType"/>
>>>
>>>         </exclusion>
>>>
>>>       </policyConstraints>
>>>
>>>       <policyActions>
>>>
>>>         <prune/>
>>>
>>>       </policyActions>
>>>
>>>     </policyRule>
>>>
>>>   </assignment>
>>>
>>>
>>>
>>> *Steps to reproduce the failure:*
>>>       Create new user John
>>>
>>>    1. Assign John → org101 as manager → gets E5
>>>
>>>    2. Assign John → org102 as default → *org101 assignment gets removed*
>>>    ❌
>>>    3. Re-assign John → org101 as manager → *org102 assignment gets
>>>    removed* ❌
>>>
>>> *Symptom:*
>>> The F3 and E5 prune fires and removes the upstream direct org assignment
>>> instead of just suppressing the application-role .
>>>
>>> *Question:*
>>> How do we configure MidPoint so O365 service (or in
>>> application-role) that E5 > F3 priority is enforced at the O365 service
>>> level, without affecting org assignments?
>>>
>>>
>>>
>>> --
>>>
>>> Bao Tran
>>>
>>> Software developer
>>>
>>> Attention! This email came from outside the ISSP company. If you do not
>>> trust this sender, do not click on the link or open the attachments, as
>>> this could be a phishing message.
>>>
>>>
>>>
>>
>>
>> --
>> Bao Tran
>> Software developer
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com
>> https://lists.evolveum.com/mailman/listinfo/midpoint
>>
>

-- 
Bao Tran
Software developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20260619/5da7bb3d/attachment.htm>