My experience is typically that the configuration permitted in the Identity Profile > Provisioning > [Lifecycle State] may meet some, but almost never all, of a client’s requirements for a lifecycle event (e.g., Joiner or Leaver). For example, I could use this config to disable a user’s accounts when they become inactive, but not to remove entitlements or schedule a delayed action; hence I used a workflow instead, to meet the client’s Leaver requirements.
Now, I am facing a similar situation with Joiner. I can meet some, but not all, Joiner requirements with this config, and therefore I am planning to use it in conjunction with birthright roles. To best design this, my question is: Is there any functional difference between assigning an access profile via [Lifecycle State] Provisioning, and assigning an access profile via a birthright role with assignment criteria cloudLifecycleState==[Lifecycle State]?
When user LCS changes, all the Access Profiles assigned due to that previous LCS will be removed automatically.
Not sure about the requirement, you can make use of LCS transform. Create additional LCS state to manage the delayed removal, for example moving user to a Grace Period LCS before moving to Inactive state.
I won’t say that you can implement 100%, but we can give a try. There might be workarounds.
There is no much difference, it is all about flexibility. LCS, you can manage Access Profiles only. If you have requirements to manage the access using some criteria then you can use Roles.
Yes but standard / best-practice Leaver requirement is to remove all entitlements, not only those which were assigned by birthright. For Leaver, we simply used a workflow to meet all the requirements, rather than split them between multiple product components.
Thanks, this answers my question. Our requirements include assigning some access profiles to all users who are “active”, and other access profiles with slightly more complex assignment criteria, e.g. “active” and department = “IT”. It just seems to me in this case that the best solution would be to model all of these requirements as birthright roles, rather than use some birthright roles in conjunction with the lifecycle state provisioning config. It just seems more simple, consistent, and – to your point – flexible/extensible.
If anyone can think of some advantage to mixing the use of birthright roles and lifecycle state provisioning of access profiles, please let me know.
Yes, to remove all the user access, we need to use Workflow only, I don’t see any best way other than some custom coding.
We also use Roles only with criteria for all birthright provisioning, we are not using Access Profiles in LCS. Incase if you need any conditions other than just LCS, then we cannot use LCS Provisioning.