Application deprovisioning requests sent to another workgroup

IdentityIQ (IIQ) IIQ Discussion and Questions
,
1

Which IIQ version are you inquiring about?

Version 8.1

Share all details related to your problem, including any error messages you may have received.

We have a default Revoker workgroup provided in the application. can we send the revocation requests to another certifier based on the entitlement the request is for. e.g. If the entitlement is read only, it should be sent to another workgroup than the one assigned as Revoker in the application, is it possible.
If possible, how to achieve this.

2

Hi Ankit,
This is actualy pretty tricky requirement as this kind of logic is not supported straightly out of the box. There is however quite simple workaround you can implement to fulfill your needs.

  1. Set revoker for the application as single Workgroup object - this will assign all remediations for this application to the selected Workgroup
  2. Create workItemForwardRule - which will forward workitems from the Workgroup you’ve selected in point 1 to the respective revokers based on it’s content.

I am affraid - this solution might have some limitations but unfortunatelly I am not aware of any other solution to achieve your requirement.

In theory you might be able to play around with integration config and try to handle this on a connector side but it will be tricky anyway.

1 Like
3

Hi Kamil, thanks a lot for your reply.
Let me be really specific about the requirement.
We are talking about Role based access provisioning for the application.
For different application roles we want different set of workgroups to be assigned with the work item.
Is there something on Role levels that could be done to achieve this.

4

I believe there is not straight forward implementation for this however you can use the approach which @ Kamil Jakubiak have mentioned along with extended attribute at role level where you can set the revoke workgroup and use the workItemForwardRule to forward it to the revoke workgroup configured in the role extended attribute.

5

If we are talking about roles then it’s actualy even more complex as Role Revocation is not really something that is creating workitem. In fact it’s removal of the entitlements related to this role - that means workitem is created to remove permissions you have revoked.

One thought that came into my mind - if you use Loopback connector to map roles as entitlements and then disable provisioning feature from this connector - this would actualy create manual workitems to remove role which you would be able to forward then. That’s just my idea - not sure if that would work 100% but I believe it would be worth of trying.

6

sounds good, yes ultimately its enlistment removal my thought (needs to be validated) … we can find the entitlement removal is caused by role removal or direct removal and once we find its caused role removal then we can find the revoke workgroup assigned to role and forward workitem.

7

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.