[midPoint] HA: Starting approval processes for secondary deltas

[Radovan Semancik]

Hi Ilya,

I see a potential caveat. The secondary deltas are computed from primary 
deltas. Therefore they represent "consequential" changes. If you delete 
secondary delta and leave the primary delta, then any following 
recompute will most likely create the secondary deltas again. So you 
will have to remove it every time. Depending on your specific case there 
may be many sources of the primary deltas (change in user, 
synchronization, recon). The primary deltas (or sync deltas) may look a 
bit differently in each case and that means also secondary deltas may 
have some variations. They might not be entirely easy to identify and 
remove. But maybe your case is quite simple and this is not really a 
problem.

My solution for this "interlacing" of responsibilities would be to keep 
the old assignment still assigned to the user but set up a validTo 
constraint on it. This validTo can extend beyond the point when he 
officialy leaves the old job role. The validTo will cause automatic 
deprovisioning once it is reached. You will probably need some extension 
attribute to mark such assignments and some task to clean up assignments 
that are after validTo, but I would guess than this approach is easier 
than the one with removing secondary deltas.

(when I'm thinking about it then maybe a time-based mapping can be used 
to remove the "expired" assignments - assuming that they were assigned 
automatically, e.g. from object template)

-- 
Radovan Semancik
Software Architect
evolveum.com



On 05/30/2015 01:07 AM, Pavol Mederly wrote:
> 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
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint