Identity Portal - multiple target permission either 1 or 2 stage approval

[William Cheang]

Hi Team,
Identity Suite 14.3 vapp. 
I need some advice on how to configure Target permission, Execution Plan & Workflow approval that have different level of approval.

1. Custom have multiple AD groups (which we will configure as Target permission).
Eg.
AD Group1 - Required Manager approval only(1 stage approval).
AD Group2 - Required Manager + Owner approval(2 stage approval).
AD Group3 - Required Manager + ( Owner1 either Owner2) approval (2 stage approval)
and so..on..(customer have hundred of AD Groups that have approval mentioned above.)

Q.How should i configure the Execution Plan and Workflow approval ?

regards,
William

[Kavita Nethinti]

Hi William,

You can configure Target Permission and Execution Plan from Portal and Workflow approvals from IM.

Regards
Kavita

[William Cheang]

Hi Kavita,
I know how to target permission and execution plan in Portal. In my question am asking advice on how to configure based on my use case.

regards,
William

[Kavita Nethinti]

Hi William,

You may use policy based Workflow approvals where you can configure different level of approvals using conditional approval rules.

Regards
Kavita

[Lynn McMorrow]

Hi William

Are you using provisioning roles to assign the account templates?  If yes, I would try using policy-based workflow at the Assign Provisioning Role event within the access request task (and perhaps use a new access request task altogether for this specific use case).

Creating the prov. roles could be a pain in this case, but you can also use the prov role name to help identify level of approval required, making policy definition easier. 

This also assumes IM is aware of the owners of the AD groups and can dynamically resolve those.  

Not sure if this meets the scope of your requirements, but I do think you'll have to do this in IM; I'm not sure you'd want to get to this level of granularity within the execution plan/portal.  

 

[William Cheang]

Hi Lynn,
I aware of the method u mentioned using policy-based workflow at assign provisioning role event. 
The area am interested is "IM is aware of the owners of AD Groups and can dynamically resolve those", how do we handle this dynamic resolving ?

Right now my method, is based on "hardcoded the owner" example.
AdminTask_ForADGroup1 with Policy workflow(Reporting Manager)
AdminTask_ForADGroup2 with Policy workflow(Report Mgr + Owner) and etc..
In Execution Plan, i detect based on TargetPermission and route to the AdminTask accordingly.

If i have 1000 AD groups, i have to defined 1000 admin tasks...that why am looking at the dynamic resolve method...

[Lynn McMorrow]

Haha, I can't answer your question because you're asking my question back in different words :)  Without knowing how you are identifying who the appropriate approvers are on a particular AD group, I can't tell you how to dynamically resolve.  I can only give you an idea.  But, my plan does not have 1000 tasks for 1000 AD groups.  It's 1 task with a policy-based workflow associated.  A rough example below, makes some assumptions:

1. Somewhere between AD and IM, the appropriate approver/s exist in a field - either an OOTB field or a custom attribute.

2. That attribute is mapped to the IM Prov store. 

3. There are only a handful of possible workflows (i.e. single step, two-step, etc.) approval processes that could be chosen. 

4. each provisioning role that would assign the account template has a custom attribute indicating which workflow that should be followed (e.g. reporting manager only, owner only, reporting manager and owner only).   

Then, you create one task, that has a policy-based workflow; one policy for each potential workflow.

As for the workflows, I'm thinking something like the below, with the custom attributes indicated being placeholders for wherever on the account template or prov role you are storing the appropriate approvers.  

[Iyes Dendeni]

The policy based workflow seems to be the logical solution for this use case, but we seem to have an issue with it.

It seems that the same issue we had before in Identity Policies where due race conditions only one policy executes, is now showing up in policy-based workflows. The fix back then was to redesign and separate policies in o individual policy sets. That fix apparently apparently was never ported to policy-based workflows.

I tried to resolve this requirement, and when I submit a request for a single group, each request gets routed to the appropriate approver (dynamically resolved from the Notes attribute of the AD group which stores the approver name). 
However, when I submit a single request for multiple AD groups, only one request gets routed to the appropriate approver. The other groups will be automatically assigned (and there is no specific order to which group gets sent to workflow and which ones get automatically provisioned - it is random and this is exactly the same behavior we've seen in the past with Identity Policies).

I will escalate to development and make them aware of the issue, but if anyone has a fix for this please share with the rest of the community members.

Here is what I did:

1) Groups in AD:

2) Assign Policy Based Workflow 

3) Approval Policies:

4) Two-Stage Approval Policy details:

5) Single-stage approval policy details:

6) When each AD group request is submitted separately (everything works fine):

7) When 2 or more groups are part of a single request (only one gets routed for approval, the others are automatically assigned):

And it also seems to have an effect on the primary approver (of the in-progress assignment) since it immediately goes to the default approver.

[William Cheang]

Thanks for the Advice, Lynn and Lyes.