Let me shed some light on that topic by providing some technical insights.
Basically, an entitlement can be assigned to an identity in three different ways (assuming the OOTB role model is used):
- Direct assignment
- Assignment through a detected IT role
- Assignment through a business role
Now, recertifying entitlements that are assigned through a business role doesn’t make sense at all since the identity refresh task would re-provision the entitlements as the underyling IT role profile is not fully fulfilled). In theory, it would be possible to recertify single entitlements that are assigned through a detected IT role. The outcome of revocation would be that the entitlement is removed from the identity and the IT role would not be detected anymore (if that makes sense is answered later).
Now, for certain processes, IdentityIQ has to be aware whether or not an entitlement is directly assigned to an identity or indirectly through an IT role / busines role. Two examples are:
- Recertification: As roles represent a bundle of entitlements, OOTB behavior is to only include directly assigned entitlemens in a recertification. Indirectly assigned entitlements are recertified through the role
- Removal of accesses in the access request process. As you can’t remove entitlements indirectly assigned through a business role, only those entilements not originating from a role shall be selectable for removal.
Now, how does IdentityIQ figure out that an entitlement is directly assigned or assigned through a role? There are two ways to do that
- The corresponding identity entitlement has a flag grantedByRole, which is true if the entitlement is assigned through a role. In that case, there are two keys in the attributes map, which indicate the IT role / business role granting the entitlement (sourceAssignableRoles, sourceDetectedRoles)
- On the identity object, directly assigned entitlements are stored in the “Exceptions” as EntitlementGroup objects. On the other hand, entitlements assigned through a role do not appear in the Exceptions.
When it comes to recertifications, IdentityIQ includes only those entitlements, which are listed in the exceptions, in the recertification. The same applies for access request - only exception entitlements are shown for removal.
This is basically the reason why the type of an entitlement based CertificationItem is Exception. Exceptions are written during identity refresh.
Is it possible to recertify entitlements that are part of an IT role?
Out of the box, it is not possible since, as mentioned above, IdentityIQ only considers Exception entitlements to be included as certification items. However, in theory it should be possible (I’ve never tried it as it doesn’t really make sense to do that from business point of view) to use the CertificationEntityCustomization rule to
- iterate over the CertificationItem objects
- check if the CertificationItem is an IT role
- extract the single entitlements from that IT role
- manually create CertificationItem objects for each entitlement
- add the generated CertificationItem objects to the certification entity
Does that make sense? Recertifying the IT role as well as the single entitlements does not really make sense from business point of view as one will have inconsistencies. Imagine the recertifier approves the whole IT role, but revokes 2 out of 3 single entitlements of that IT-Role. Or the other way around, all single entitlements are approved while the IT role is removed.
One could argue that you could remove the IT role as a certification item and add all singel entitlements as certification items. This way, you would effectively recertify single entitlements instead of the IT role as a whole.