[midPoint] HA: Starting approval processes for secondary deltas

[Pavol Mederly]

Hello Илья,

first of all, sorry for the late answer.

Now I think I understand your requirements and why you need the 
secondary-phase approval.

Originally I thought that any reconciliation/recomputation of the user 
would yield removal of the role assignments. But a small experiment made 
tonight convinced me that it's not the case. It seems that any further 
manipulation with the user (changing other attributes, recomputation, 
reconciliation) preserves the assignments.

So, you seem to be going through a path that nobody went before :) But I 
think your approach might really work.

Perhaps Radovan could shed some light to this case as well.

Best regards and nice weekend,
Pavol

On 26. 5. 2015 11:40, Илья Дорофеев wrote:
> Hi Pavol,
>
> OK, I'll elaborate on my case a bit. I have a policy (user template mappings) which assigns different sets of roles to people on different positions (dependant on the 'title' attribute). Then imagine a situation when a person gets a promotion / different position. According to the rules he is unassigned of one set of rules and at the same time assigned to another one (those roles which are implied by either position remain untouched). This works perfect in an ideal world but not in a real one. Because in a real world quite often the person may still need his former accesses/permissions while handing over his duties to his successor. So I want an automatic unassignment of roles to pass through an approval process (some sort of a recertification).
>
> The following is my solution. In a self implemented ChangeProcessor I inspect the primary delta for the change of the particular attribute ('title' in the current case). Then, in the second phase I inspect the secondary delta for the removal of the role assignments and respectively launch approval processes. Then, in case of rejecting these changes (i.e. confirming the person still needs these roles), I just delete these deltas from the context. The simple test (without actual launching of approval process, just clearing the secondary delta) showed this works as expected. But I wonder whether there are any caveats in this solution. Will these assignments be removed later during the next synchronization cycle?
>
>
> Ilya Dorofeev
> Software Architect
> Solar Security
>
> ________________________________________
> От: midPoint [midpoint-bounces at lists.evolveum.com] от имени Pavol Mederly [mederly at evolveum.com]
> Отправлено: 25 мая 2015 г. 18:44
> Кому: midpoint at lists.evolveum.com
> Тема: Re: [midPoint] Starting approval processes for secondary deltas
>
> Hello Ilya,
>
> the problem of approving things in secondary phase is what to do in case
> of rejection.
>
> Because if you detect that an assignment of specific role is to be
> added, what do you do with the original request?
> The original request can be a compound one, consisting e.g. of modifying
> givenName, description, and a certain attribute (the one that causes the
> discussed assignment to be created).
> You have to analyze the situation and cancel the whole operation, or
> perhaps remove only the attribute change.
>
> My suggestion is to deal with the primary cause only - and that is the
> change of the attribute. You can easily write a custom
> PrimaryChangeProcessorAspect that would be focused on that attribute and
> would handle changes that lead to assignment of critical roles/resource
> to the user object.
>
> If that's not possible, we could analyze other options.
>
> Back to your question. The problem that I've just described (i.e. what
> to do in case of rejection) is the reason why we do not like to work
> with secondary-phase approvals. Even the general change processor is
> quite "half-baked" and unfinished; not quite ready to be used in its
> current form.
>
> But, again, I'm quite sure the solution can be implemented by
> PrimaryChangeProcessor.
>
> Regards,
> Pavol
>
> On 25. 5. 2015 17:24, Илья Дорофеев wrote:
>> Hi,
>>
>> I have user template mappings which assign / unassign certain roles depending on the values of certain attributes. In some cases I want these assignments / unassignments to be passed through an approval process. As these changes appear to be secondary deltas, as far as I understand, I have two options: either to utilize the general change processor or implement my own change processor. But it is not clear which one to choose. What advantages and disadvantages do both provide? In addition to this, I see the PrimaryChangeProcessor which seems suitable for my needs (by implementing specific aspect), but its functionality restricted solely to primary deltas. Could you elaborate on what stands behind this design? Why couldn't it be expanded to processing secondary deltas?
>>
>>
>> Ilya Dorofeev
>> Software Architect
>> Solar Security
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com
>> http://lists.evolveum.com/mailman/listinfo/midpoint
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint