|
| |
| Sun Java[TM] System Identity Manager 7.0 Deployment Overview | |
Chapter 1
Working with AttributesThis chapter presents a conceptual overview of attributes as used in Identity Manager deployments.
Related ChaptersAttributes 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:
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 AttributesAlthough objects in an Identity Manager deployment can contain a variety of attributes, you are most likely to 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. Summary attributes 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 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 for user objects directly through the UserUIConfig object. For more information, see UserUIConfig Object.
Inline Attributes
You can designate up to five queryable attributes for each object 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.
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.
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 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.
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 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.
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 Identity Manager Workflows, Forms, and Views.
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 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.
Working with Identity System User attributes is extensively documented in Identity Manager Resources Reference.
Controlling whether Attributes are Displayed (Secret Attributes)
Identity Manager displays the value of an attribute in clear text on Results pages, even when you have set the attribute for display with asterisks in an Edit form. To prevent the attribute value from being displayed in the cache, you can register the attribute as secret. A secret attribute is an attribute whose value is not displayed in clear text in the browser cache, but that is processed by Identity Manager like any other attribute.
Identity Manager handles “secret” attributes as follows: When Identity Manager renders the results table, it checks to determine if any of the attributes are registered as secret, and displays the values of secret attributes with asterisks only.
Social security number is a typical attribute that you might want to register as a secret attribute.
Registering a Secret Attribute
To register a secret attribute, add it as follows to the System Configuration object:
<Attribute name='secretAttributes'>
<List>
<String>email</String>
<String>myAttribute</String>
</List>
</Attribute>
Attribute Conditions
An attribute condition is an expression that tests the value(s) 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 Condition Operators
AttributeCondition defines operators including:
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 IDM 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.
Populating Organizations with User Member Rules
The set of users in a given organization can be determined by:
- 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) so we can 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
Problem
Need a rule to include all users except those with specified administrative roles.
Solution
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.
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.
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.
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 lastname instead of creating a workflow to derive the same value.
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).
Partial Loading of MetaView Information
When Identity Manager populates a User view for Reconciliation, Load from Resource, or Load from File, you can designate loading only the resource account data from the resources that are assigned to an Identity Manager user that are also targets sourced from the resource being loaded (and therefore subject to change). The Identity Manager user's operational attributes that do not affect accounts – for example, account ID and organization – are always in the view, as are user extended attributes such as firstname, and lastname.
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.
Table 1-4 Meta View Attributes and Associated User View Attributes
Meta View Attribute
User View Attribute
firstname
metaView.firstname
lastname
metaView.lastname
waveset.roles
metaView.waveset.roles
User Meta View Form
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.
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