|
| |
| Sun Java System Identity Manager 2005Q4M3 Technical Deployment Overview | |
1
Working with 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 of their regular operations.
Related InformationAttributes are manipulated as part of many Identity Manager operations and are discussed throughout the documentation set. Substantial discussion of various attributes types are included in these chapters:
Types of AttributesAlthough objects in an Identity Manager deployment can contain a variety of attributes, you are most likely to customize or work with the types introduced in the following table. Each attribute type is introduced at greater length in subsequent sections.
Summary Attributes
Every persistent object exposes a set of summary attributes. Each subclass can extend the default set by overriding the getSummaryAttributes method. Summary attributes contain the values that are returned for each item in the result of a list call.
Summary attributes are typically single-valued, because there is a limit to the total length of the summary attributes when serialized to a string.
You configure these attributes directly through the UserUIConfig object. For more information, see UserUIConfig Object.
Queryable Attributes
Every persistent object exposes a set of queryable attributes. Each subclass can extend the default set by overriding the getQueryableAttributes method.
Queryable attributes can be multi-valued, and contain the set of values used for filtering and matching.
You configure these attributes directly through the UserUIConfig object. For more information, see UserUIConfig Object.
Inline Attributes
You can designate up to five queryable attributes for each type as inline attributes. 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.
- 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.
User Extended Attributes
You can add attributes to the default list of extended attributes for a user object. These attributes, called User Extended attributes, are stored on the User Extended Attributes Configuration object in the repository.
This Configuration object defines additional attributes that are stored in the user objects in the repository. The system ignores any attribute value in the accounts[lighthouse] namespace of the User view that is not registered in the configuration object.
See the discussion of the accounts[lighthouse] attribute of the User view in the Views chapter of Identity Manager Workflows, Forms, and Views for more information on user extended attributes.
Operational Attributes
Identity Manager predefines several attributes that are required for the repository to work correctly. ID, type, and name are especially important.
ID, type and name
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 promises 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.
modified
A Java long, modified contains a value that is incremented whenever the object is modified through Identity Manager.
Immediately after the update, and until the next object of the same type is modified, this modified value will match the value of the counter attribute in the special LASTMODIFIED item for that type.
lockinfo
A Java String, lockinfo contains a value that represents a logical lock.
The lockinfo string includes the name of the locker and the time that the logical lock will expire.
counter
A Java long, counter contains an arbitrary value that can be incremented or set very efficiently without requiring a logical lock on the object.
Other Standard Attributes
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 end-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 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.
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.
Views are extensively documented in the Views chapter of Identity Manager Workflows, Forms, and Views.
Resource User Attributes
Resource User attributes (sometimes referred to as account attributes) map Identity Manager account attributes to resource account attributes in a schema map. 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 are extensively documented in Identity Manager Resources 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. This term is used interchangeably with account attributes.
Working with Identity System User attributes are extensively documented in Identity Manager Resources Reference.
AttributeCondition
An attribute condition is an expression that tests the value(s) of an attribute. Attribute conditions are typically used to select the subset of objects that match certain criteria.
Each attribute condition expresses a single criterion and consists of:
Working with Identity AttributesIdentity attributes provide a central point from which you can configure and view attribute flow within your Identity Manager deployment, regardless of where the information originates from, or how many resources — for example, SPML, Active Sync resources, the User Interface.
For specific deployment needs, Identity attributes can provide an alternative to customizing workflows and forms. For example, you can create an Identity attribute named fullname that results from appending firstname to fullname instead of creating a workflow to derive the same value.
Identity Manager permits you to select which portions of your deployment environment will incorporate Identity attributes. You can use Identity attributes throughout your deployment or limit their implementation to “applications”, including the Identity Manager Administrator Interface, Identity Manager User Interface, or during Active Sync processing, for example.
You define Identity attributes from the Configure > Identity Attributes page in the Identity Manager Administrator Interface. Consult the online help that accompanies these pages for procedures on creating, deleting, and editing attributes.
Why Use Identity Attributes?
Identity attributes provide the following advantages for your deployment:
- consistent way to apply data mapping rules within a deployment
- separation of data-transformation functions of a form from its data-display capabilities. If you’ve worked with an Identity Manager deployment previously, you’ll know that Identity Manager forms serve the dual purpose of transforming data and displaying data. Using Identity attributes reduces the amount of form-based data transformations.
- centralized view of how data flows through an Identity Manager deployment
Architectural Overview
Implementing Identity attributes involves the following Identity Manager components. The more significant components are described below.
Attribute Sources and Targets
Each Identity attribute can use input from one or more source. Inputs can include:
- resource attributes. For example, you can assign an authoritative Active Sync resource to populate firstname on other resources.
- transformations. Attributes can be derived from other Identity attributes (or user view attributes) through a rule or transformation. Meta view transformations are applied uniformly throughout the system, regardless of where a change originates. Identity Manager applies these transformations whether an attribute was derived from an Active Sync event, a reconciliation process, or a user entering information into a form in the User Interface.
- constant values. Identity attributes can be assigned constant values to provide a default value for attributes that are not available or cannot be otherwise derived (for example, password).
An Identity attribute target can be a resource or extended attribute, or operational attribute. An operational attribute is an attribute on the Identity user that controls the behavior of that user (for example, rules or assigned resources). When the output is a resource, Identity Manager writes the attribute to the resource when the attribute is changed.
You can also assign conditions under which the attribute should be pushed to a target resource. These conditions are rules that should return a value of true or false, and can also be restricted by event type (for example, create and update).
Meta View
The Meta view supports the creation and manipulation of Identity attributes. It provides a unified view of all resources in a deployment and their relationships.
Whenever you define an Identity attribute, Identity Manager creates an attribute in the metaView namespace in the User view that contains the value of this attribute, as illustrated below.
Meta View Attributes
User View Attributes
firstname
metaView.firstname
lastname
metaView.lastname
waveset.roles
metaView.waveset.roles
Related Forms
Identity Manager automatically generates the User MetaView form after you have configured or modified Identity attributes. It creates this form when an enabled application first accesses Identity attributes. For example, if you have designated the Identity Manager Administrator Interface as an enable application, Identity Manager creates this form when a user first accesses the Edit/Create user page.
Do not modify this form.
How Identity Attribute Transformations are Applied
Identity Attribute transformations are applied to the User view by including the User MetaView Form in the standard view cycling process using expansion, derivation, and default expressions. This cycle occurs when the User view is created (for a new user), checked out (for an existing user), refreshed, or checked in. The User MetaView Form is processed immediately before the standard user form for the application (for example, the Tabbed User Form). This allows the standard user form to override values set through the Identity attributes, and gives the standard user form access to values in the metaView namespace.
Note that Active Sync and SPML use a slightly different view processing cycle since they operate with multiple forms, and therefore do not allow the input forms to override values set from Identity Attributes.
Sample Scenario
The following table exemplifies the relationship between Identity attributes and the resources. In this table, the firstname Identity attribute is set by a PeopleSoft resource. Identity Manager uses the firstname and lastname attributes as source for the rule that generates for the fullname and user ID Identity attributes.
Storage of Attribute Values
Identity attribute values can be stored either locally or retrieved dynamically during runtime. Identity Manager configures locally stored attributes as User Extended attributes. When you add an attribute to the Extended User Attributes list, Identity Manager stores and maintains the attribute with the user object in the repository.
Storing attribute values in this way provides two benefits:
Typically, an Identity Manager deployment retrieves attributes on-the-fly when it loads the User view.
Using Rules with Identity Attributes
You can use a rule to generate the value of an Identity attribute. When using rules this way, keep in mind:
- Rules typically have access to the entire User view, including the MetaView namespace. Access includes the activeSync namespace, if the event is derived from an Active Sync resource.
- Rules used for Meta view transformations should act only on Meta view attributes. Avoid modifying User view attributes.
- Use rules only as sources for Identity attributes