[midPoint] HA: Starting approval processes for secondary deltas

Илья Дорофеев i.dorofeev at solarsecurity.ru
Tue May 26 11:40:32 CEST 2015


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


More information about the midPoint mailing list