We as an organization are new to a IdenityNow and have recently started with Onboarding a new source as Active Directory. We do have some specific requirements of Certain attributes to be determined dynamically for User’s account based on their country, job title etc.
The implementation consultants we have employed have presented intital solution where they have put the dynamic attributes directly on user’s Identity Attributes as shown in the picture.
We really doubt this being a good design practice. Ideally they should be part of account attributes Since we are still developing out understanding around Sailpoint IDN solution, I would appreciate the help around this topic.
Isn’t that the better way to calculate these values dynamically when account request is made.?
But As I said we are starting, wouldn’t the list of attributes keep on increasing as we onboard new systems and have similar target specific requirements .?
Hi @kruna_sshah ,
I also second to @iamnithesh and your consultants.
If you want to re-utilize common user attributes across various target systems (now or in future), it’s always good to have them in your identity attributes.
Also, the list of attributes doesn’t grow exponentially over the time as most of them would be sorted in the initial phases, where you onboard critical systems that drive the LCS of the user.
Here are some insights, which might help you in future.
It’s not a good idea to create Identity attributes unnecessarily as it will impact System performance (For example, Refresh Identity Cube Task will calculate values for all Identity Attributes).
I would create Identity attributes only if
It needs to be synchronized to the source as we don’t have update account provisioning policy form, we go for attribute sync. In Create account provisioning policy form, If you select Identity attribute for account attribute mapping then only sync will be available for the same account attribute.
If you are going to use this identity attribute in some other sources
if you need an identity attribute in search as we cannot build search queries to extract a specific attribute from a source. It is easy to pull identity attributes in search.
This is exactly what needs to be taken care of and good planning is important for the same. Most of the Identity attributes will have their values determined by corresponding account attributes from Authoritative sources. However, you may have the need to create few attributes to get their values from target sources based on the business needs. Based on your original question it seems like you are trying to populate some attributes for Active Directory using the user’s details from another source. This is exactly where I would utilize Identity Attributes as trying to directly refer (by means of a transform in Provisioning Policy or in a rule) might not be an effective solution. Also, you need to consider the simplicity in your design so that it is easily understood by people who would be working on it in future.
Also, if some of these values are same for all users, they can be stored as Application attributes and directly referred to from Before Provisioning Rule.
Last but not the least, a good design can be achieved by collective thoughts of all stake holders and it is important to express your concerns and have them addressed
It’s much clearer to the administrator taking over managing the solution if attributes are sourced from the Identity. Attributes added by rules or Account Attribute Transforms are effectively hidden from the front-end. A well-thought-out Identity Profile with intuitive names of transforms can make the sources of data clear much more clear.
