2.3 Creating Extended Attributes and the Objects That Support Them

Creating Extended Attributes and the Objects That Support Them

Blueprint objective 1.3 asks you to demonstrate knowledge of creating extended attributes. Objective 7.4 asks which common IdentityIQ objects can have extended attributes. The two go together: you create an extended attribute on one of those objects, and where it is stored decides whether you can search on it.

What an Extended Attribute Is

Every IdentityIQ object class has standard attributes built into the product, such as an identity's firstname, lastname, email, and manager. An extended attribute is one you add for your organization, such as costCenter on identities, privileged on accounts, or riskTier on applications. The definitions are kept in an ObjectConfig object for the class. The console command oconfig lists every class that has an ObjectConfig and its extended attributes, numbered by their extended column slot.

Which Objects Support Extended Attributes

The installation guide also lists TargetExtended.hbm.xml (permission targets) and AlertExtended.hbm.xml (activity alerts). For the exam, focus on the six rows above. Extended attribute questions almost always involve identities, accounts, applications, roles, entitlements, or certification items.

Two Ways to Store a Value

1. Non-searchable. The value is stored in the object's serialized XML attributes map. It displays and can be used in rules, but it cannot be filtered in searches.
2. Searchable. The value is copied into a real database column so that searches, filters, populations, and reports can query it. The column must already exist in the Hibernate mapping.

Searchable columns come in two styles:

• Numbered columns – properties named extended1, extended2, and so on. The Edit Identity Attributes page says the default number of searchable identity attributes is ten. The installation guide lets you add numbered properties up to a maximum of twenty.
• Named columns – a property with a meaningful name, such as costCenter. Hibernate turns camel case into a lower-case, underscore-separated database column (cost_center). When you map an attribute to a named column in the UI, you enter the .hbm.xml property name, not the database column name.

An example of adding numbered, indexed identity properties to IdentityExtended.hbm.xml:

<property name="extended1" type="string" length="450" index="spt_identity_extended1_ci"/>
<property name="extended2" type="string" length="450" index="spt_identity_extended2_ci"/>
<property name="extended11" type="string" length="450" index="spt_identity_extended11_ci"/>

Adding index="spt_identity_extendedN_ci" creates a case-insensitive index for that column. Identity attributes of type Identity, which point at another identity such as a region owner, are stored in separate extended identity fields. oconfig lists them in their own sub-list.

Creating an Extended Attribute: The Procedure

1. Plan the columns. Decide which attributes must be searchable. If the default slots are not enough, edit the relevant *Extended.hbm.xml file in WEB-INF/classes/sailpoint/object.
2. Regenerate and apply the DDL. Run iiq schema to produce new database scripts. On a new install, create the database with them. On an existing install, apply the column changes to the database.
3. Define the attribute in the UI. Use the matching Global Settings page. Give it an Attribute Name (the name rules use) and a Display Name, choose a type, and select Searchable if it needs a column.
4. Map its sources. Identity and account attributes take their values from source mappings: application attributes, application rules, or global rules (section 16.3). Application, role, and entitlement attributes are usually entered in the UI and can have allowed values, default values, and a Required flag for string types.
5. Populate it. Identity attributes are promoted during aggregation and identity refresh. Account attributes are filled from their source mappings during aggregation.

Rules That Produce Exam Traps

• Names must be unique. The documentation warns that an extended attribute must not share a name with any attribute in any application schema. If an extended attribute matches a schema attribute, values may not update correctly during aggregation. A standard prefix avoids collisions.
• You cannot reuse a standard identity attribute name for an identity extended attribute.
• Renaming is risky. Changing an attribute name can make previously aggregated values unrecognizable.
• Accounts and certification items move together. If you change the account (Link) extended attributes, make the same change to the CertificationItem attributes. This lets searchable account values be stored on certification items for searching and status icons.
• Upgrades overwrite WEB-INF. Customized IdentityExtended.hbm.xml, LinkExtended.hbm.xml, and CertificationItemExtended.hbm.xml files must be saved and copied into the new installation before upgrading the database.
• Keep the default mappings. AI-Driven Identity Security (formerly AI Services) needs every default field in the .hbm.xml files. Add columns, but do not remove the defaults.
• Account attributes can drive icons. An extended account attribute such as privileged or service can show an icon in certifications and identity pages. You set this with an AccountIconConfig entry in the UIConfig object.