I’m back again with a blockage I’ve been investigating during the migration process from IIQ to ISC. As part of migration all access profiles would be created on ISC using the source entitlements as usual. The Identities accounts will already have the entitlements that these access profiles grants and will get detected automatically by ISC.
We need for audit purposes the approval for the access profile provision request within ISC but when detected re-requesting is cancelled and there’s no approval definition left. I’ve been looking at the forum and documentation and it seems that the detection can’t be stopped. Is there a plan in the future to be able to make this feature as optional in certain moments?
Re-requesting all of the access profiles would be a great effort but needed, if we include that ISC cancels the requests when already detected we would also need to deprovision all access first which would make the impact bigger. Aside from creating a static report of all access granted through IIQ provisionally, in the long run it would be really helpful to be able to disable the detection. A not so good-looking method I thought was creating by script all access profiles using dummy ents, requesting them then updating them to the real ones. And creating a certification after to remove the remaining dummy ents. Have you ever encountered something similar and had a better solution?
So If I understand your setup correctly, you have done the following:
All ‘entitlements’ are mapped to access profiles 1-to-1
You want to have these access profiles to become assigned via ISC (previously assigned via IIQ)
Currently, access profiles are never assigned, they are always detected. That means that even if you request an access profile, it will provision the access but will not become assigned as part of that provisioning, just detected.
The only option to have access be assigned is via roles.
Hi Edwin, thank you for your answer! It made me rethink and test the scenarios where this data is used in ISC. I thought about this last week and ended up with the conclusion that ISC don’t use this information at all only on the newly added History Tab on Identity Management (not downable) but again it doesn’t show how the access got provisioned or deprovisioned. The account provision activity will stop coming from ISC at a certain time and will need to get either reported or moved to a logging tool. That’s why I think now that all I mentioned earlier is not necessary for ISC. We’ll see another alternative transferring the audit logs into a logging tool.
Thank you,
Carol
Loading the data is more like the Day-0 activity . Think of the scenario if you load 1000’s of entitlement and access profile and looking for re-approval process that doesn’t seems to be much helpful . users would have got all these access via IIQ approval process or though some other process before IIQ .
I Think you need to maintain the balance between the compliance and complexity . if you need to show the data how users got the access you can show that user had same access in IIQ . and for compliance you can perform immediate access review of the access to the application .
yes, exactly! We are looking into doing certifications, moving the IIQ provisioning audit reports in a static folder or logging tool and sign all access as approved on both tools (at a time, when available) for compliance. We’ll set the logging tool and start clean from scratch on ISC.
Thank You,
Carol