Chapter 1 Working with Attributes

This chapter presents a conceptual overview of attributes as used in Identity Manager deployments. The topics in this chapter include

• Related Chapters

• What are Attributes?

• Using Attribute Conditions

• Using Secret Attributes

Related Chapters

Attributes are manipulated as part of many Identity Manager operations and are discussed throughout the documentation set. The following chapters contain a substantial amount of information related to attributes:

• Chapter 3, Identity Manager Views, in Sun Identity Manager Deployment Reference provides an extensive discussion of view attributes, registering attributes, and deferred attributes.

• Sun Identity Manager 8.1 Resources Reference provides information about resource attributes.

What are Attributes?

Attributes are name-value pairs that are used to define and manipulate characteristics of Identity Manager objects as well as external resources. Identity Manager components such as forms, workflows, and rules call attributes as an essential part of accessing and transforming data in their regular operations.

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

• Queryable Attributes

• Inline Attributes

• Extended Attributes

• Operational Attributes

• View Attributes

• Resource User Attributes

• Identity System User Attributes

• Other Standard Attributes

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.

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.

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.

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:

• An inline attribute must be single-valued because its value is stored in a single column of the parent row in the object table.

• Up to five queryable attributes can be inline for a type because the object table contains only five columns that can be used to store arbitrary attribute values.

• The same set of queryable attributes is designated as inline for every instance of a type because the correspondence between the column value and the name of an attribute is specified only by the configuration. That is, the configuration of inline attributes for a type is the only way the repository knows which attribute is stored in which column.

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.

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.

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.

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 User:

  • MemberAdminGroups

  • adminRoles

  • adminGroupsRule

• For Role and extensions of Role: role_applications

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.).

MemberObjectGroups

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.

PropertyList

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

subType

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.

authType

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.

Using Attribute Conditions

An attribute condition is an expression that tests the values of an attribute. Attribute conditions are commonly used to select the subset of objects that match certain criteria.

Each attribute condition expresses a single criterion and consists of:

• Attribute name (of a queryable attribute)

• Operator (a kind of check or comparison to be made)

• Operand (a specified set of values)

Attribute Condition Operators

AttributeCondition defines the following operators.

RelationalDataStore optimizes evaluation by translating each attribute condition into an appropriate predicate that becomes part of the WHERE clause for the operation. However, no special logic is required to handle multi-valued attributes. RelationalDataStore automatically generates appropriate SQL DML to handle this.

An attribute condition applies to each value of an attribute. (Specifically, operator NE is true if, and only if, an object has no value for the specified attribute that equals the specified operand. Operator EQ is true if an object has at least one value for the specified attribute that matches the specified operand.)

Implicitly ANDed

A set of attribute conditions is implicitly ANDed. This means that a set of attribute conditions evaluates to true if, and only if, every attribute condition in the set evaluates to true. Conversely, a set of attribute conditions evaluates to false as soon as any attribute condition in the set evaluates to false.

Identity Manager attribute conditions expose operators that are generally useful. Typically, you can express a set of selection criteria using Identity Manager attribute conditions. A few criteria cannot be expressed, but even these are often better addressed by adding (or changing the representation of) a queryable attribute.

Example Scenario: Populating Organizations with User Member Rules

You can use the following attributes to determine the set of users in a given organization:

• External (to Identity Manager) resource account attributes. In this case, you need both the resource account ID and the resource name (for example, acctid:resname) to find the matching Identity Manager user because more than one Identity Manager user might have the same acctid but on different resources.

• Identity Manager user account attributes (for example, name, location, manager).

To get the “or’ed” effect, do not use multiple attribute conditions. Instead, use the “is one of” operator with a list of operands, as follows:

<list>
  <new class=’com.waveset.object.AttributeCondition’>
    <s>firstname</s>
    <s>is one of</s>
    <list>
      <s>Nicola</s>
      <s>Paolo</s>
    </list>
  </new>
</list>

Example Scenario: Including All Users Without Administrative Roles

You need a rule to include all users except those with specified administrative roles.

Because attribute conditions are implicitly ANDed together, you can use two attribute conditions:

• Condition that selects users with at least one admin role (which in effect excludes non-administrative users). This condition specifies that a matching user has at least one value for the adminRoles attribute.

  <AttributeCondition> <s>adminRoles</s> <s>exists</s> </AttributeCondition>

• Condition that excludes users with any of a set of specific admin roles. This condition specifies that no value of the adminRoles attribute is ar1 or ar2.

  <AttributeCondition> <s>adminRoles</s> <s>is not</s> <list> <s>ar1</s> <s>ar2</s> </list> </AttributeCondition>

Taken together, these conditions specify that the user must have an admin role that is not in the specified list.

Using Secret Attributes

Identity Manager displays attribute values in clear text on the Results pages, even when you have set the attribute for display with asterisks in an Edit form. To prevent attribute valued from being displayed in the cache, you can register the attribute as secret. Secret attribute values are not displayed in clear text in the browser cache, but these attributes are processed by Identity Manager just like any other attribute.

For example, a social security number is an attribute that administrators typically register as a secret attribute.

When rendering the results table, Identity Manager checks to determine whether any of the attributes are registered as secret, and displays the values of secret attributes with asterisks only.

To register a secret attribute, add that attribute to the System Configuration object as follows:

<Attribute name=’secretAttributes’>
   <List>
     <String>email</String>
     <String>myAttribute</String>
   </List>
</Attribute>