Sun Identity Manager Deployment Guide

Types of Attributes

Although objects in an Identity Manager deployment can contain a variety of attributes, you typically work with the attribute types described in the following sections:

Summary Attributes

Every persistent object exposes a set of summary attributes. Summary attributes are configured in the Identity Manager Schema Configuration object and contain the values that are returned for each item in the result of a list operation. Each PersistentObject subclass can extend the default set of attributes by overriding the getSummaryAttributes method.

Summary attributes are typically single-valued, because there is a limit to the total length of summary attributes when serialized to a string.

You configure these attributes for user objects directly through the Identity Manager Schema Configuration object. For more information, see IDM Schema Configuration Object.

Note –

The SummaryAttrNames section of UserUIConfig is no longer used in Identity Manager.

Queryable Attributes

Every persistent object exposes a set of queryable attributes. Queryable attributes contain the set of values used for filtering and matching, and these attributes are configured in the Identity Manager Schema Configuration object. Queryable attributes can be multi-valued.

Note –

The QueryableAttrNames section of UserUIConfig is no longer used in Identity Manager.

Inline Attributes

You can designate up to five queryable attributes for each object type as inline attributes. Inline attributes are configured in the Identity Manager Repository Configuration object.

Note –

Inline attributes are no longer configured in UserUIConfig.

Designating an attribute as inline asks the data store to optimize the performance of queries against that attribute.

Identity Manager typically stores each value of a queryable attribute as a row in an attribute table that is separate from the main object table. The attribute table can be joined to the object table to select objects that match an AttributeCondition.

Identity Manager stores the value of an inline attribute, however, directly in the object table for that type. Designating an attribute as inline allows Identity Manager to generate more efficient SQL. A column expression on the main object table is faster than a JOIN to (or an EXISTS predicate against) the corresponding attribute table. This improves the performance of any query against the attribute.

You can characterize inline attributes as follows:

Extended Attributes

Extended attributes are just attributes that are not built-in, such as employeeNumber for User. Most customers want to be able to query by employeeNumber, so you can add this attribute as a queryable extended attribute through the configuration.

Note –

It is a best practice to prefix extended attributes with a deployment-specific prefix to prevent potential conflicts with new core attributes in future releases of Identity Manager.

For example, when adding an extended attribute to User to record the employeeNumber, use a prefix associated with the company, such as acme_employeeNumber. If a future Identity Manager release incorporates a built-in user attribute named employeeNumber, the two attributes will remain distinct. Otherwise the built-in attribute takes precedence.

Because extended attributes are not built-in, these attributes must be in the <IDMAttributeConfigurations> section of the IDM Schema Configuration object. This section captures the attribute names, syntax (such as string, int, and date), and whether the attribute is single-valued or multi-valued. The IDMObjectClassConfiguration captures which attributes are in which object classes because named attributes can actually be in more than one object class, such as MemberObjectGroups.

Note –

The IDM Schema Configuration object is protected with the IDMSchemaConfig authType.

Administrators needing to view or edit the Identity Manager schema for Users or Roles must have the IDMSchemaConfig AdminGroup (capability) assigned. The Configurator user has this AdminGroup assigned by default.

For more information about User extended attributes, see the discussion about the accounts[lighthouse] attribute of the User view in the Views chapter of Deployment Reference.

You can expose built-in attributes and extended attributes as queryable or summary. Some built-in attributes have REFERENCE syntax, but extended attributes are not allowed to be REFERENCE.

The <Comments> section of the effective schema contains information about available internal attributes, as well as extended attributes for relevant objectclasses. You can view this information from the Identity Manager Debug pages by clicking the Display Schema button and selecting ObjectClass Schema from the list.

Note –

Extended attributes are supported for User, Role, and extensions of Role only.

Some built-in attribute references for User and Role are not queryable or summary by default, but you can expose the following attributes:

For attribute definitions, click the Display Schema button on the Debug Pages to view the IDMObjectClass schema. Administrators must have View rights for IDMSchemaConfig to view the IDMObjectClass schema.

Operational Attributes

Identity Manager predefines several attributes that are required for the repository to work correctly. ID, type, and name are especially important.

Every PersistentObject stored in the repository has a globally unique internal identifier (ID). An ID value is unique across time and space, and a generated ID value is never re-used. (Some predefined Identity Manager objects have well known identifiers that are defined as program constants. These are known as fake IDs.) The repository ensures that an object’s ID will never change.

Objects of the same type typically map to the same Java class. That is, they are constructed as instances of the same Java class when deserialized. Where there is not a one-to-one correspondence between type and Java class, every object of the same type at least uses the same mechanism to look up the corresponding Java class. (For example, some types of objects expose a class attribute that contains the fully qualified class name.)

An object’s name must be unique within type. That is, only one object of a type can have a particular name. (However, another object of a different type can have the same name.) Thus, each type effectively defines a subordinate namespace. You can change an object’s name, but you cannot change an object’s ID.

View Attributes

A view is a collection of name/value pairs that are assembled from one or more objects stored in the repository, or read from resources. The value of a view attribute can be atomic, such as a string, a collection such as a list, or reference to another object.

Whenever you create or modify a user account from the Identity Manager Administrator or User Interfaces, you are indirectly working with the User view. Workflow processes also interact with the User view. When a request is passed to a workflow process, the attributes are sent to the process as a view. When a manual process is requested during a workflow process, the attributes in the user view can be displayed and modified further.

Working with views is extensively documented in the Views chapter of Deployment Reference.

Resource User Attributes

Resource User attributes map Identity Manager account attributes to resource account attributes in a schema map (right side). The list of attributes varies for each resource. You can remove unused attributes from the schema map page. However, adding attributes might require editing the adapter code.

The Resource User attributes are used only when the adapter communicates with the resource.

Working with Resource User attributes is extensively documented in Resource Reference.

Identity System User Attributes

Identity System User attributes define an internal Identity Manager value that corresponds to a Resource User attribute. The Identity System User attributes can be used in rules, forms, and other Identity Manager-specific functions. Identity Manager displays these attributes on the left side of the schema map.

Working with Identity System User attributes is extensively documented in Resource Reference.

Other Standard Attributes

You can use some of the other standard attributes to restrict access to objects (such as MemberObjectGroups, subType, or authType) or to represent historical information (such as the creator and date created.).


Every persistent object belongs to at least one object group. Each value of this multi-valued attribute is the ID of an ObjectGroup object.

ObjectGroups are exposed as Organizations in the Identity Manager Administrator and User Interfaces. ObjectGroup membership governs Session-level authorization (that is, administrator and user access to repository objects), but the repository itself ignores object group membership.

creator, createDate, lastModifier and lastModDate

These values record historical information about each object. These attributes are maintained (but are not used) by the repository.


Every persistent object can contain an arbitrary list of Properties. This feature is not widely used.


Every persistent object can have a subType attribute. For example, Identity Manager uses Attribute.SUBTYPE to select separate lists of the available correlation rules and confirmation rules.


The authType attribute allows fine-grain authorization to be performed (that is, access to be scoped or restricted) for users who do not control any organization (object group). These subjects would otherwise have no access in Identity Manager’s standard authorization scheme.