Internal employees are coming from HRMS. Currently, there are a set of access profiles assigned to the users, as birth right access, when lifecycle becomes “active”. Is it possible to assign two sets of birthright accesses for two user groups in IdentityNow when the Lifecycle becomes “active”. These two user groups can be identified using an attribute which is coming to IdentityNow from HRMS.
Hello @maneeshyatiwella , could you plese explain what you mean by 2 sets of birthright access?
If you mean having an identity be in one of two lifecycle states depending on their group, yes you can do that. You would set the identity attribute of cloudLifecycleState upon aggregation from the authoritative source (or manually via the admin console) to either value, depending on what group the identity was in. That would put them into one state or the other.
But you can’t have a single identity in more than one lifecycle state at a given time. Does that make sense?
Hi @maneeshyatiwella I have a couple of ideas about how to accomplish this:
1.) Is the organization/HR in a position to consider using 2 different Lifecycle states that represent active, one for each user group? This would be the simplest solution: active1 (for user group1), active2 (for user group 2) . Use the identity state of active in both cases. In other words, HR sets this in the HR data and these different values are aggregated into the Identity Security Cloud.
2.) Otherwise, a fairly simple transform on the Lifecycle State identity attribute can accomplish this a little differently. If there is only 1 lifecycle state of Active at the HR level that is aggregated in, you can use a transform to change the lifecycle state within Identity Security Cloud to active1 and active2, based on the other attribute:
use accountAttribute: grab the value stored in your secondary attribute from HRMS ((Note: I don’t know what the attribute values are, so I’m using x and y below…)
use the static operation with Apache Velocity Template Language:
if accountAttribute is x, then the identity attribute cloudLifecycleState is set to active1
if accountAttribute is y, then the identity attribute cloudLifecycleState is set to active2
There’s a decent example in the static documentation ( the final example):
With this second option, you are still leveraging 2 different lifecycle states (active1 and active2 respectively) within Identity Security cloud Provisioning tab, each with their own list of birthright access profiles. Also, this accomplished without having to update HR processes. Deploy the transform to the cloud tenant, then select it in the identity profile, on the Lifecycle state.
Yes, option #2 makes more sense because the customer’s HRMS system will not add an additional active parameter.
In addition, I was also thinking of going for a role approach. Maybe I could create 2 roles for the two sets of user, which they will get assigned from the attributes. Then inside that role, I could assign the relevant access profiles.
HI @maneeshyatiwella Yes, achieving this result via roles could also be possible.
Roles can be used for defining access for specialized (smaller groups - job roles for example) or larger populations of users. If the customer has the AI-Driven Access Modeling Component, you can designate those roles as “Common Access” (via a checkbox in the role Configuration page). In the role membership criteria, select the attributes in question and choose the access profiles that apply. Good idea!