Access Provisioning

[PravinM]

We are using Workday as an authentication source. Our use case involves users having up to 8 personas from Workday, each defined by an attribute called JOB_CODE. We need to assign accounts/access to users based on each JOB_CODE value.

The persona in JOB_CODE_1 is the primary persona for the user. Other personas, defined in JOB_CODE_# (where # ranges from 2 to 8), are secondary personas.

In Saviynt, we can store this multi-persona (multi-affiliation in Saviynt's terminology) using User Attributes. The primary persona details are stored in the user profile, while the secondary persona attributes are stored in the User Attributes table. However, the User Attributes object is not exposed in User Update rules or Technical rules for configuring provisioning logic for secondary personas.

There might be updates such as the addition or removal of one or more personas, requiring provisioning or deprovisioning access.

Has anyone managed a similar use case or have any insights that could be helpful?

[NM]

Hi @PravinM , is there any reason why you used user_attribute table??

Mapping to user customproperty would also be helpful

[PravinM]

Thank you for your response.

We have not started with configs yet but the reason for not going with USER CP's is there will be addition or removal of Personas which will basically change the order of existing personas in the Workday report.

So example if today we have mapping as below:
JOB_CODE_2 --> CP11
JOB_CODE_3 --> CP12
JOB_CODE_4 --> CP13

If JOB_CODE_3 gets removed from Workday for a user, in next import the data of personas going to shift up in the report as JOB_CODE_4 value will now start showing up in JOB_CODE3. 

And as we will need to configure the provisioning logic based on CP's, the changes on personas as explained above add to many complexities.

[rushikeshvartak]

Refer https://forums.saviynt.com/t5/identity-governance/can-we-use-multi-affiliation-attributes-in-update-...