Common extended identity attributes for enterprise deployments

[#1]

Beyond our standard IdentityIQ attributes, across our various IdentityIQ enterprise deployments, we commonly see these kinds of attributes, or some variation thereof deployed.  This is meant to serve as a baseline example of the kinds of attributes we commonly see.  Feel free to implement attributes to meet your business needs, in this list or otherwise.

Attribute Name Suggestion	Data Type Suggestion	Example	Description
Title/Position	String	e.g. Janitor, Developer, etc.	This attribute typically describes a person's job title or position in words.  Sometimes, to be more precise, this can also be a position or job code/identifier, although it may not mean much to people seeing that code/identifier. Commonly, this can be used to drive position, job, function, or role-based access at its finest-grain level. Typically most clients start with more coarse-grain access assignments first.
Phone Number	String	e.g. +1-512-123-4567	This attribute commonly describes a mobile, work, or telephone number which the identity can be reached.  Best practice, is to stick to some common, internationalized format, like the E.164 International Standard for Telephone Numbers.
Employee Identifier/Number	String	e.g. 123455739, E1234	This is some sort of unique identifier for the particular identity, and is sometimes generated by the HR source during employment on-boarding.  This may or may not be used for login purposes, and can take a variety of formats depending on the rules which they are generated. Note: This sometimes can be the same as username (below), but doesn't have to be.
Username/Corporate Login/Global ID	String	e.g. neil.mcglennon, nmcglennon	This attribute usually defines some sort of globally accepted login username which to standardize across other accounts.  These can take a variety of formats, but are generally easy to read / understand who this belongs to.  This does have the downside of being susceptible to renames if an identity is married, divorced, etc. so sometimes customers choose alternate usernames or corporate login strategies. Note: This sometimes can be the same as employee identifier (above), but doesn't have to be.
Location/Place/Country/ City/County	String	e.g. Germany, Austin Texas, United Kingdom, Singapore, etc.	This is often used in various ways, and could describe the country, city, state, or province which the identity resides.  This can be used to drive location-based access for things such as access to buildings, etc.  Sometimes this can also be multi-valued, if an identity is associated with more than one location. Best practice is to standardize on ISO 3166 language code or name.
Employee Type	String	e.g. Contractor, Employee, etc.	This attribute usually describes the type of identity we are dealing with - usually, but not limited to, an employee vs contractor type.  This along with company / organization help determine where someone fits.
Company/Organization	String	e.g. SailPoint, etc.	This attribute is often used to describe which company an identity works for.  This is especially useful in larger organizations that are composed of many different companies which may have different processes. Although rare, sometimes this can also be multi-valued, if an identity is associated with more than one company.
Business Unit	String	e.g. Engineering, Sales, etc.	This attribute is often used to describe the business functional area in which an identity works.  This can be used to drive access at the business unit level.
Cost Code	String	e.g. 12345	This is attribute is often used to describe the cost center associated with where this identity gets paid, or costs from.
Employment Status	String	e.g. Active, Retired, Leave of Absence, Terminated, etc.	This attribute defines where in an employment process this identity resides.  Commonly, at its simplest form, someone is usually either "Active" or "Terminated", although there can be a myriad of other states as well.  Sometimes these may take the form of codes or IDs from HR systems as well.  If you have multiple states from multiple HR sources, sometimes it is best practice to normalize these. This combined with "employee type" (above) can form some sort of situational baseline access as well - e.g. "Active Employee" access.
Start Date	Date or String	e.g. 2014-01-01, 2014-01-01T07:11:31Z	This attribute usually defines when an employee is set to start or begin employment.  This can be used to drive when access should be granted or other workflow processes. Best practice is to use the date datatype, or if using a string datatype, standardize on some sort of data standardization, such as ISO 8601.
End Date	Date or String	e.g. 2014-12-31, 2014-12-31T07:11:31Z	This attribute usually defines when an employee is set to end employment or contract.  This can be used to drive when access should be taken away or other workflow processes. Best practice is to use the date datatype, or if using a string datatype, standardize on some sort of data standardization, such as ISO 8601.
Organizational Level/Rank	String	e.g. Executive, Senior Management, Management, L1, L2, etc.	This attribute is used to define the level at which an identity resides.  This can help determine if an employee is an executive, manager, or a normal employee.  Sometimes in defense or military terms this could also be considered a 'rank' of sorts.  This could be as fine or coarse grain as you decide to implement.
Language	String	e.g. en_us, en_gb, de, etc.	This attribute is common in areas outside the United States, and can be used to send multi-lingual email templates, or form communications to the end user. Best practice is to standardize on ISO 639-1 language codes. Note: It is not what governs the user interface language settings.
Tax ID/SSN/Country Identification	Password or String	e.g. 123-45-6789	This attribute usually describes some form of identification method to validate or back up who the identity is.  Often times this can be a tax ID, social security number, or other form of identification.  In some countries (like the USA), this information may be extremely sensitive, and may not be opted to store at all.  If whatever identification you decide to store here is sensitive, I may suggest encrypting this information, or using a one-way hash to compare values against.

A lot of this varies from customer to customer, however you’ll want to collect things that will ultimately drive your processes. As you can see with the attributes above, a lot of this could drive roles, workflow, or some sort of provisioning actions/logic. Lastly I will add that every piece of information you collect is something you have to maintain, and data is notorious for being stale, outdated, or poise a risk for data leakage. Just because you can collect it doesn’t mean you should.

If you need more information on extending the schema, and managing extended attributes, please refer to this doc.