As many of you may know, we can run an Identity Refresh on a single identity as part of any workflow. This is used in several places in our out-of-the-box workflows to refresh certain items for an Identity.
One such example is in our "LCM Create and Update" workflow. In this workflow, we call the identityRefresh workflow method as such after we make changes to the cube being Created or Edited:
<Step action="call:refreshIdentity" condition="ref:doRefresh" icon="Task" name="Refresh Identity" posX="954" posY="114">
<Arg name="identityName" value="ref:identityName"/>
<Arg name="correlateEntitlements" value="true"/>
<Arg name="provision" value="true"/>
<Arg name="synchronizeAttributes" value="true"/>
In this case, the Identity Refresh step will do the following:
Any options available in the Identity Refresh task may be set and passed in as arguments for your identityRefresh Workflow Method call.
See the table here for what those options are:
Task Argument | Identity Refresh Task UI Option | Used for: |
---|---|---|
checkHistory | Maintain identity histories | |
checkPolicies | Check active policies | Check the identity for any policy violations |
correlateEntitlements | Refresh assigned, detected roles and promote additional entitlements | Handle Role Assignments/Deassignments (use in conjunction with "provision" below to provision the changes caused by these assignments. |
correlateScope | Refresh assigned scope | |
deleteDormantGroups | Clean up groups definitions that are no longer referenced | |
disableManagerLookup | Disable connector lookup of managers that do not correlate | |
doManualActions | Enable the generation of work items for unmanaged parts of the provisioning plan. | |
enablePartitioning | Enable partitioning | Not applicable when refreshing a single identity - This option is only used when refreshing many identities, not just a single one. |
excludeInactive | Exclude identities marked inactive | |
forceWorkflow | Always launch the workflow (even if the usual triggers don't apply) | |
includeWindowModified | Include modified identities in the refresh window | |
keepInactiveViolations | Keep previous violations | |
markDormantScopes | Mark dormant scopes after refresh | |
noAutoCreateScopes | Disable auto creation of scopes | |
noRoleDeprovisioning | Disable deprovisioning of deassigned roles | |
processTriggers | Process events | Run LCM Lifecycle Events if configured |
promoteAttributes | Refresh identity attributes | Update Identity Attributes based on Aggregated Data |
promoteManagedAttributes | Promote managed attributes | |
provision | Provision assignments | Handle provisioning related to Role Assignments/Deassignments |
refreshCertifications | Refresh continuous certifications | |
refreshCompositeApplications | Refresh logical application links | |
refreshGroups | Refresh the group scorecards | Refresh your Groups (based on Define --> Groups --> Groups configuration) based on Identity attribute changes |
refreshIdentityEntitlements | Refresh Identity Entitlements for all links | |
refreshLinks | Refresh all application account attributes | Refresh all of a user's account attributes. This forces an aggregation of all of a user's accounts. |
refreshManagerStatus | Refresh manager status | Refresh a user's manager status based on any changes to the Identity |
refreshRoleMetadata | Refresh role metadata for each identity | |
refreshScorecard | Refresh the identity risk scorecards | Refresh an identities Risk scores based on any changes in Role Assignments, Attributes, etc. |
synchronizeAttributes | Synchronize attributes | Provision any Identity Attribute changes to the targets defined in your Identity Mappings |
Thank you Chris
It is also possible to add more arguments, other than the options available in the Identity task.
For instance, preRefreshRule, with then name of a rule as the value, in case a Refresh rule needs to be executed.
Good catch. That is actually true. Fortunately, there are very few of those "hidden" options.
Hi Chris,
I our implementation(V7.0), we have roles implemented and a custom workflow to handle role propagation(this handles both entitlement addition and removals) in place. We are not using the role propagation task that was introduced in v6.4. The custom workflow is triggered when ever role is created/updated/deleted and it adds/removes the related entitlements on the native systems as per the profile of the role.
As part of the workflow, we perform target aggregation of the account being modified and then perform an Identity refresh(with <Arg name="correlateEntitlements" value="true"/> ) on all the identities having the impacted roles(either Business/IT). But we are seeing that IT roles(with new profile) are not being detected to few identities(even though the identity has the entitlements matching the new profile of IT role that is modified) after the identity refresh. This problem is observed only with few identities in the total list of identities that are expected to be impacted.
I wanted to try out the 'enablePartioning' option and check if this solves the problem. Is this option strictly restricted if the number of identities is one(We may run into a situation where only one identity is part of the role)?
Thanks,
Mahesh
Thanks Chris for your detailed explanation.
I have refresh entitlement correlation task configured along with refresh role meta data. this task is taking around 6 hours to complete. Due to this lot of duplicate roles are coming as detected roles which is creating data inconsistency. We would like to run this task only for active identities. We ran this task for active identities only and performance has increased significantly due to lesser identities to refresh. we would like to know what impact will be if we don't run this task for inactive identities.
As per my knowledge role changes will not happen for inactive identities and also if there is any extra entitlements that is part of any role, then that role will not be coming as detected.
Also if any admin team is making role assignment for inactive identities then, role assignment won't happen.
Could you please through your suggestion on this.
Regards,
Vijay Sharma
<Step action="call:refreshIdentity" icon="Task" name="Final Refresh Identity" posX="2630" posY="358">
<Arg name="identityName" value="ref:identityName"/>
<Arg name="provision" value="true"/>
<Arg name="correlateEntitlements" value="true"/>
<Arg name="refreshIdentityEntitlements" value="true"/>
<Transition to="end"/>
</Step>
This step in our workflow is giving us the "lazily initialize a collection of role: sailpoint.object.Identity.assignedRoles, no session or session was closed" exception. Could you please suggest on resolving it
On our AD account aggregation we are seeing:
"org.hibernate.LazyInitializationException: failed to lazily initialize a collection of role: sailpoint.object.Identity.links, could not initialize proxy - no Session"
Was your issue resolved ?