[midPoint] Require Assistance

[Radovan Semancik]

Hi Anand,

On 01/05/2015 02:54 PM, Anand Kothekar wrote:
> A Very Happy New Year To You All.

Thanks. And a happy new year to you and all on this list.

> *Please provide me assistance for following queries :-*
>
>   * I have a requirement where I need to *raise Approval Request*at
>     the time of *Account/Resource Assignment to Role*in midpoint.
>

In midPoint there is no difference between "operation" and "request". 
E.g. a "request" to add assignment to a user is just a simple operation 
to add assignment to user object. MidPoint configuration will then 
decide whether this operation needs to be routed through an approval 
process - which makes it a "request" in the workflow sense. But on the 
Model API level all the requests are just normal operations. Therefore 
in your case the "request" is just an operation that adds assignment to 
role.

However there may be one issue. Currently the workflow code is built to 
intercept only operations on users. Or that is the only thing that we 
have tested so far. MidPoint architecture allows to intercept operations 
on all objects. But I'm not sure how much generic is the current "hook" 
code (as we call it) that actually does the intercept. Maybe Pavol can 
provide more information here.

>   * Is it possible to *Assign A Manager To User*(Manager will handle
>     Approval Requests Of multiple users).
>

There are two ways how to do this:

1: Use the organizational structure. Assign user to the org unit and 
assign a manager for the org unit. This is perhaps the most systematic 
way. Then when you need a manager of a specific user you need to write 
an expression that retrieves user's org unit, finds the manager and 
returns it. The expression can also check for the case that unit does 
not have a manager and it needs to go one unit up, etc. The trick is how 
to assign a manager to the org unit. And there are also two options:

a: The architecturally clean way is to use "relation" parameter in 
midPoint object references. This is designed especially for this case. 
Every object reference in midPoint can have a "relation" which is an 
optional qname/uri that can specify how the references objects relate. 
This can be particularly useful with parentOrgRef reference that forms 
the organizational structure. The default (empty) relation is 
interpreted in a way that the user is a member of the org unit. But you 
can use different relation values to represent a manager, business owner 
or any similar concept. This can theoretically be used to specify many 
managers for a particular org unit, pass manager changes through proper 
approvals, etc. The good news is that the relation is designed to be 
easily indexed and our search queries are also designed to handle it so 
it is likely to scale. The bad news is that I'm not sure how much of 
this is actually implemented. There may also be issues how to express 
the relation in an assignment.

b: The less clean but perhaps more practical solution is to use extended 
attributes in OrgType to store the reference to the manager of the org 
unit. This is simpler and it will work well in some cases. But there may 
be scalability/flexibility limitations.

2: Do not use organizational structure at all. Use extended attribute of 
UserType to specify the manager of each user directly. This is what 
commercial IDM systems typically do. It is simple, but there is a huge 
amount of inherent drawbacks in this approach.

Whatever way you choose please keep this in mind: We are using 
organizational structure quite a lot in existing midPoint deployments. 
Therefore this part is fairly well tested. But we use it for delegated 
administration/authorizations and for synchronization. We currently do 
not have any midPoint deployment where the organizational structure is 
used to specify managers and used for approvals. We have found that our 
current customers are quite happy with approvals based only on roles. 
However midPoint was designed for this (case 1a) and it should 
theoretically work. However this was never tested and as the wise saying 
goes: "In theory there is no difference between theory and practice. But 
in practice there is a whole lot of difference." ... so proceed with 
care. There is also very little of this pre-configured and there are 
almost no samples.

As always you have the usual options: 
https://wiki.evolveum.com/display/midPoint/I+Need+New+Feature

We have one current customer that is considering investment in the 
midPoint organizational structure management. If the customer decides 
for this then we will test (and fix) the use of "relation" for 
specifying org managers (case 1a). But currently we have do have any 
indication when (or if) this is going to happen.

>   * If yes then how we can force Managers to Approve Resource requests
>     on Role Assignments .
>

Each role has an approverExpression property. A user who is the result 
of this expression will be an approver for this particular role. This is 
the place where you can put an expression that determines the manager. 
Or alternatively you can modify the approval workflow (BPMN) and 
explicitly determine the approvers there.

>   * Handling Multi-Level Approvals (from User's Manager and Manager's
>     Manager).
>

We support multi-level approvals in roles. See the approvalSchema 
property in the role. But I'm not sure if this can be coupled with the 
approverExpression result or you will need to modify the workflow to get 
this. Maybe Pavol can provide more details here.

-- 

                                            Radovan Semancik
                                           Software Architect
                                              evolveum.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20150106/de16622c/attachment.htm>