Understanding the User View

The User view is the collection of attributes that
contain information about an Identity Manager user, including:

Attributes stored in the Identity Manager repository

Attributes fetched from resource accounts

Information derived from other sources such as resources,
roles, and organizations

The user view is most often used with forms that are designed for the
pages that create or edit users. These pages launch workflow processes that
store a changed user view until it is necessary to push the updated view information
back out to Identity Manager and associated resources. While the user view
is stored in a workflow process, the workflow process can manipulate attribute
values through workflow actions. Workflow can also expose attribute values
for user input through manual actions and approval forms.

How the User View Is Integrated with Forms

The user view is often used in conjunction with a form. Forms contain
rules that control how data is presented through HTML fields and is processed
after the HTML page rendering the form is submitted. A system component called
the form generator
combines a form definition and a view to produce HTML that a browser then
displays.

View attribute values are displayed by assigning them to an HTML component
in the form. (See Chapter 7, HTML Display Components for more information on how view attributes can be displayed.)

Views are implemented as instances of the GenericObject class. This class
provides a mechanism for the representation of name/value pairs and utilities
for traversing complex hierarchies of objects through path expressions. A path expression is a
string that is interpreted at runtime to traverse an object hierarchy and
retrieve or assign the value of an attribute.

You must understand how to write path expressions to assign valid form
field names. For more information on using path expressions, refer to the
section titled Path Expressions.

How the User View Is Integrated with Workflow

Workflow processes that contain a user view typically store it in a
workflow variable named user. You can reference a view
in the workflow expressions by prefixing user to a user
view path (for example, user.waveset.accountId). The string waveset identifies the attribute named accountId as
belonging to another object named waveset, which itself belongs to the user
view object.

Approval forms are written for a view known as the WorkItem view.
The Work Item view by default contains all the workflow variables under an
attribute named variables. If the approval form is written
for a workflow that contains a user view, the prefix variables.user. is
used to reference attributes in the user view (for example, variables.user.waveset.roles). See WorkItem View later in this chapter
for more information.

Generic Object Class

At a high level, objects are simply named collections of attributes,
which are name/value pairs. The value of an attribute can be an atomic value
such as a string, a collection such as a list, or a reference to another object.
You can represent almost any object abstractly with the Map, List, and String Java classes.

Within the Identity Manager system, the GenericObject class provides
a simple memory model for the representation of arbitrary objects and collections.
It includes features for easily navigating object hierarchies to access or
modify attribute values.

The GenericObject class implements the java.util.Map interface and internally uses a java.util.HashMap to
manage a collection of name/value pairs. The entries in this map are called attributes. The value of an attribute can be any Java object that is able
to serialize itself as XML. The most common attribute values found in a GenericObject:

The following are instances of the following classes:

String

Integer

Boolean

EncryptedData

List

Date

GenericObject

X509cert

You can construct complex hierarchies of objects by assigning Lists or GenericObjects as attribute values. Once
you have assigned attribute values, you traverse this hierarchy to access
the values of an attribute.

Path Expressions

A path expression is a string that is interpreted
at runtime by the GenericObject class to traverse an object
hierarchy and retrieve or assign the value of an attribute. Identity Manager uses
a system of dots and brackets to represent objects and attributes in the hierarchy.

You use path expressions as the value of the name attribute in form
fields when customizing a form (for example, <Field name=’user.waveset.roles’/>).

Traversing Objects

The following simple example illustrates a GenericObject with
two attributes:

name (String)

address (GenericObject) The address object,
in turn, has an attribute named street, which is a string.

To create a path expression to the street attribute
of the address object, use address.street.

Path expressions use the dot character (.) to indicate traversal from
one object to another. This is similar to the way dot is used in Java or the ’->’
operator is used in C. Paths can be long, as illustrated by this example:

user.role.approver.department.name

Traversing Lists

You can also use path expressions to traverse values that are lists.
Consider an object that has an attribute children whose
value is a java.util.List. Each object in the list is itself
a GenericObject with a name attribute and an age attribute.
Write the path to the name of the first child as:

children[#0].name

Path expressions use square brackets to indicate the indexing of a list.
The token between brackets is the index expression. In
the simplest case, this is a positive integer that is used to index the list
by element position.

Typically, the position of an object in a list is arbitrary. Index expressions
can also specify simple search criteria to identify one object in the list.
Objects in a list typically have a name attribute, which serves to uniquely
identify this object among its peers. Path expressions support an implicit
reference to an object’s name attribute within the index expression.

For example

children[hannah].age

The preceding path expression obtains the list of objects stored under
the children attribute. This list is searched until an
object with a name attribute equal to hannah is
found. If a matching object is found, Identity Manager returns the value of
the age attribute.

Example: Using the = Operator

<ref>accountInfo.accounts[type=vms].name</ref>

accountInfo.accounts[type=vms].name returns a list
of names for VMS resources. It returns a list of only one element if only
one exists.

Using the == Operator

children[hannah].age is equivalent to children[name==hannah].age. If you search using type=LDAP for example,
you would get a list of names of LDAP resources. However, if you use the ==
operator, the result is a single object. For example, children[parent=hannah].occupation returns a list of occupations for all of hannah’s children,
but children[parent==hannah].occupation returns a single
occupation (not in a list) for whichever child was found first.

If more than one account with type vms exists, then
either example will return the first account found with no particular guaranteed
ordering.

Calculating Lists

You can also write path expressions that calculate List values that
are not stored in the object. For example:

accounts[*].name

When an asterisk is found as an index expression, it implies an iteration
over each element of the list. The result of the expression is a list that
contains the results of applying the remaining path expression to each element
of the list. In the previous example, the result would be a list of String objects. The strings would be taken from the name attribute of
each object in the accounts list.

Path expressions with * (asterisk) are used with the FieldLoop construct
in forms to replicate a collection of fields.

Account Types and User-Oriented Views

When you assign an account type to a user, Identity Manager makes available
the account type as well as the accountId. When working
with the user-oriented views, including the User, Enable, Disable, and Deprovision
views, follow these addressing guidelines:

Use a value of null to indicate an account of the default
type. Reference an accounts of the default type by resource name for example,
accounts[corp-ad]

Use a type-qualified name instead of the resource name to
reference an account of a specific type. The type-qualified resource name
takes this form:

<resource name>|<type of account>

To reference the account data for the account of type Admin on
the resource corp-ad, reference accounts[corp-ad|Admin].

User View Attributes

Whenever you create or modify a user account from a web browser, you
are indirectly working with the user view. From the perspective of altering
user account information, it is the most significant view in the Identity Manager system.

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.

Introduction

Like all views, the user view is implemented as a GenericObject that contains
a set of attributes. The values of the attributes in the root object are themselves GenericObjects. Attributes can be nested.

The user view contains the attributes described in the following table,
which are further defined in subsequent sections.

Table 3–1 Top-Level Attributes User
View

Attribute

Description

waveset

Contains information stored in the Identity Manager repository (the WSUser object). This is sometimes referred to as the basic
view.

accounts

Contains the values of all resource account attributes fetched from
resources. These are typically the values that are edited with forms.

accountInfo

Contains read-only information about the resources and accounts associated
with the user.

display

Contains the read-only runtime state for the interface. It is used only
during interactive editing of the user. display.session describes
login and access information. display.subject identifies
the account under which the user is logged in. display.eventType indicates
whether the user view is servicing a create or an update operation.

global

Contains attributes that are synchronized across all resource accounts.

password

Contains attribute values that are specific to the user’s password,
password expiration, and target systems.

When you design a form, the field names are typically paths into the
user view objects waveset. global, and account attributes (for example, global.firstname).

Selecting the Appropriate Variable Namespaces

The user view provides several namespaces for deriving account-related
information. The following table summarizes these variable namespaces.

Table 3–2 Account-Related User View
Attributes

Account-Related Namespace

Description

waveset.accounts

Used internally for difference detection during check-in operations.
It contains the starting values for all account attributes. Do not modify
this value.

accountInfo.accounts

Derived read-only information about the accounts that are linked to
the user and their associated resources. Use this attribute in forms, but
do not modify.

accounts

Stores the read/write copies of the account attributes. Updatable fields
should point to this namespace.

global

Stores copies of global attributes. Values in this area appear only
if the form defines global fields, or if you are using the special MissingFields
reference. (The form determines how global attributes are processed.)

If you set a global attribute in a workflow, you must also define a
global field in the form. Simply depositing a global value in the view is
insufficient.

Referencing Attributes

Within a form, you can reference attributes in two ways:

Use the name attribute of a Field element
by adding the complete attribute pathname as follows:

<Field name=’waveset.accountId’>

For more information on setting the Field name element in a form field,
see the chapter titled Identity Manager Forms.

Within workflow, you can reference Field attributes
as process variables (that is, variables that are visible to the workflow
engine) or in XPRESS statements for actions and transitions. When referencing
these attributes in workflow, you must prefix the path with the name of the
workflow variable where the view is stored (for example, user.waveset.accountId).

Attributes with Transient Values

You can define fields that store values at the top-level of the user
view, but these values are transient. Although they exist throughout the life
of the in-memory user view (typically the life of the process), the values
of these fields are not stored in the Identity Manager repository or propagated
to a resource account.

For example, a phone number value is the result of concatenating the
values of three form fields. In the following example, p1 refers
to the area code, p2 and p3 refer to
the rest of the phone number. These are then combined by a field named global.workPhone. Because the combined phone number is the only value you want propagated
to the resources, only that field is prepended with global.

In general, use the top-level field syntax if you are:

not pushing a field value out to Identity Manager or any other
resource

the field is being used only in email notifications or for
calculating other fields.

Any field that is to be passed to the next level must have one of the
path prefixes defined in the preceding table, User View Attributes.

waveset Attribute

The waveset attribute set contains the information
that is stored in a WSUser object in the Identity Manager repository. Some attributes
nested within this attribute set are not intended for direct manipulation
in the form but are provided so that Identity Manager can fully represent all
information in the WSUser object in the view.

Most Used Attributes

Not all attributes are necessary when creating a new user. The following
list contains the waveset attributes that are most often
visible during creation or editing. Some attributes are read-only, but their
values are used when calculating the values of other attributes. All waveset attributes are described in the sections that follow this table.

Table 3–3 Most Used Attributes of
the waveset Attribute (User View)

Attribute

Editable?

Data type

waveset.accountId

Read/Write

String

waveset.applications

Read/Write

String

waveset.correlationKey

Read/Write

String

waveset.creator

Read only

String

waveset.createDate

Read only

String

waveset.disabled

Read/Write

String

waveset.email

Read/Write

String

waveset.exclusions

Read/Write

List

waveset.id

Read

String

waveset.lastModDate

Read

String

waveset.lastModifier

Read

String

waveset.locked

Read

String

waveset.lockExpiry

Read/Write

String

waveset.organization

Read/Write

String

waveset.questions

Read/Write

List

waveset.resources

Read/Write

List

waveset.resourceAssignments

Read/Write

List

waveset.roleInfos

Read/Write

List

waveset.roles

Read/Write

String

waveset.serverId

Read/Write

String

waveset.accountId

Specifies the visible name of the Identity Manager user object. It must
be set during user creation. Once the user has been created, modifications
to this attribute will trigger the renaming of the Identity Manager account.

For information on renaming a user, see Business Administrator's Guide.

waveset.applications

Contains a list of the names of each application (also called resource
group in the Identity Manager User Interface) assigned directly
to the user. This does not include applications that are assigned to a user
through a role.

waveset.attributes

Collection of arbitrary attributes that is stored with the WSUser in
the Identity Manager repository. The value of the waveset.attributes attribute
is either null or another object. The names of the attributes in this object
are defined by a system configuration object named Extended User
Attributes. Common examples of extended attributes are firstname, lastname, and fullname.
You can reference these attributes in the following ways:

waveset.attributes.fullname

or

accounts[Lighthouse].fullname

You typically do not modify the contents of the waveset.attributes attribute. Instead, modify the values of the accounts[Lighthouse] attributes. When the attribute is stored, values in accounts[Lighthouse] are copied into waveset.attributes before storage. waveset.attributes is used to record the original values of the
attributes. The system compares the values here to the ones in accounts[Lighthouse] to generate an update summary report. See the section on the account[Lighthouse] attribute for an example of how to extend the
extended user attributes.

waveset.correlationKey

Contains the correlation value used to identify a user during reconciliation
and discovery of users. You can directly edit it, although it is generally
not exposed.

waveset.creator

Contains the name of the administrator that created this user.

This attribute is read-only.

waveset.createDate

Contains the date on which this account was created. Dates are rendered
in the following format: MM/dd/yy HH:mm:ss z

Example

05/21/02 14:34:30 CST

This attribute is set once only and is read-only.

waveset.disabled

Contains the disabled status of the Identity Manager user. It is set
to a value that is logically true if the account is disabled. In the memory
model, it is either a Boolean object or the string true or false. When accessed through forms, you can assume it is a string.

You can modify this attribute to enable or disable the Identity Manager user,
although it is more common to use the global.disable. (Prepending global. to a variable name ensures that the system applies the value
of that variable to all resources that recognize the variable, including Identity Manager.)

Once this value becomes true, the user cannot log in to the Identity Manager user
interface.

waveset.email

Specifies the email address stored for a user in the Identity Manager repository.
Typically, it is the same email address that is propagated to the resource
accounts.

Modifications to this attribute apply to the Identity Manager repository
only. If you want to synchronize email values across resources, you must use
the global.email attribute.

You can modify this attribute.

waveset.exclusions

List the names of the resource that will be excluded from provisioning,
even if the resource is assigned to the user through a role, resource group,
or directly.

waveset.id

Identifies the repository ID of the Identity Manager user object. Once
the user has been created in Identity Manager, this value is non-null. You
can test this value to see if the user is being created or edited. This attribute
is tested with logic in the form. You can use it to customize the displayed
fields depending on whether a new user is being created (waveset.id is
null) or an existing user account is being edited (waveset.id is
non-null).

Example

The following example shows an XPRESS statement that tests to see if waveset.id is null:

<isnull><ref>waveset.id</ref></isnull>

waveset.lastModDate

Contains the date at which the last modification was made. It represents
the date by the number of milliseconds since midnight, January 1970 GMT. This
attribute is updated each time a user account is modified.

This attribute is read-only.

waveset.lastModifier

Contains the name of the administrator or user that last modified this
user account.

This attribute is read-only.

waveset.locked

Indicates whether the user is locked. A value of true indicates
that the user is locked.

waveset.lockExpiry

Specifies when the user lock expires if the user’s Lighthouse
Account policy contains a non-zero value for the locked account expiry date.
This attribute value is a human-readable date and time.

waveset.organization

Contains the name of the organization (or ObjectGroup)
in which a user resides. An administrator can modify this attribute if he
has sufficient privileges for the new organization.

Since changing an organization is a significant event, the original
value of the organization is also stored in the waveset.original attribute,
which can be used for later comparison.

waveset.original

Contains information about the original values of several important
attributes in the waveset attribute. The system sets this
value when the view is constructed and should never be modified. The system
uses this information to construct summary reports and audit log records.

Not all of the original waveset attributes are saved
here. The attributes currently defined for change tracking are:

password

role

organization

To reference these attributes, prepend waveset.original. to
the attribute name (for example, waveset.original.role).

password

Specifies the Identity Manager user password. When the view is first
constructed, this attribute does not contain the decrypted user password.
Instead, it contains a randomly generated string.

The password attribute set contains the attributes
described in the following table.

Table 3–4 Attributes of the password
Attribute (User View)

Attribute

Description

password

Identifies the password to be set

confirmPassword

Confirms the password to be set. The password should match the value
of password.password

targets

Specifies a list of resources that can have their password changed

selectAll

Specifies a Boolean flag that signifies that the password should be
pushed to all of the resources

accounts[]

Specifies a list of objects that contains information about each of
the resources. This attribute contains two attributes, which are described
below.

accounts[<resource>]. selected

Boolean. When set, indicates that the password should be changed on
the resource.

accounts[<resource>]. expire

Boolean. When set, indicates that the password will expire.

This attribute is set to false if the user changes his own password.
However, if an administrator changes another user’s passwords, the flag
is set to true.

To prevent the password from being expired when administrators or proxy
accounts other than the user change a password on an account, set

accounts [<resource>].expire = <s>false</s>

This setting ensures that

the password is not expired

Identity Manager does not force the user to change the password again

waveset.passwordExpiry

Contains the date on which the Identity Manager password will expire.
When the view is initially constructed, the memory representation will be
a java.util.Date object. As the view is processed with
the form, the value can either be a Date object or a String object that contains a text representation of the date in
the format mm/dd/yy.

waveset.passwordExpiryWarning

Contains the date on which warning messages will start being displayed
whenever the user logs into the Identity Manager User Interface. This is typically
a date prior to the waveset.passwordExpiry date in the
same format (mm/dd/yy).

waveset.questions

Contains information about the authentication questions and answers
assigned to this user. The value of the attribute is a List whose
elements are waveset.questions attributes.

The waveset.questions attribute set contains the
attributes described in the following table.

Table 3–5 waveset.questions Attributes
(User View)

Attribute

Editable?

Description

answer

Read/Write

Encrypted answer to the question

id

Read

System-generated ID for the question

name

Read

Name used to identify this question

question

Read

Text of the authentication question

The name attribute is not stored. The system generates
the name by transforming the id. This is necessary because
question IDs are typically numbers, and numbers that are used to index an
array in a path expression are considered absolute indexes rather than object
names.

For example, the path waveset.questions[#1].question addresses
the second element of the questions list (list indexes start from zero). However,
since there may be only one question on the list whose ID is the number 1,
the ID is not necessarily suitable as a list index. To reliably address the
elements of the list, the system manufactures a name for each question that
consists of the letter Q followed by the ID (in this example, Q1). The path waveset.questions[Q1].question then always correctly addresses the
question.

waveset.resources

Contains a list of the names of each resource that is assigned directly
to the user. This list does not include resources that are assigned to a user
through a role or through applications. You can add only unqualified resource
names to this attribute. To find all resources that are assigned to a user,
see the section on the accountInfo attribute.

waveset.resourceAssignments

Qualifies the assigned resource list. (This attribute parallels the
existing attribute waveset.resources attribute.) All resources
in this attribute appear as unqualified in waveset.resources.
Even if a user is assigned only an account of non-default type, the resource
will appear in waveset.resources.

You can add new assignments made to either waveset.resource or waveset.resourceAssignments, with the lists automatically resynchronizing
when the view is refreshed. This adds an assignment for an account of default
type. You can add both qualified and unqualified resource names to waveset.resourceAssignments. This adds an account of the specified type based on the qualifier.

waveset.roleInfos

Contains a list of objects that contain information about the roles
assigned to this user.

Table 3–6 waveset.roleInfos Attributes

Attribute

Description

approvalRequired

(Boolean) Specifies whether approval is required for this optional role.
If the value of directlyAssigned is false, and assignmentType is optional, this value determines if approval is required for
this optional role or not

assignedBy

Identifies which role assigned to the user contains this role. If directlyAssigned is false, this value is the name of the directly
assigned role or roles that resulted in this role being assigned

assignmentType

Specifies how the indirect role is assigned. If directlyAssigned is
false, this value will be either required, conditional, or optional.

directlyAssigned

(Boolean) Specifies whether the role is directly assigned to the user.

events

Maps the name/date entries that define events to be processed for this
role (for example, activation date and deactivation date).

name -- allowed values include:activate and deactivate. activate
indicates when to provision this role. deactivate indicates when to deprovision
this role.

date -- Date for associated event.

info

(Object) Contains role information that should not appear when determining
user-role assignment changes. This object can have the following attributes:

* typeDisplayName - role type display name / message key

* description - user-provided description of the role

name

Specifies the role name

type

Specifies the role type as defined in the Role Configuration object.
Valid types include BusinessRole, ITRole, Application Role, Asset Role.

state

Specifies role assignment state. Valid values include assigned or pendingActivationDate.
You can define additional custom states.

waveset.roles

Contains the names of the roles assigned to this user. An administrator
can modify this attribute if he has sufficient privileges for the new roles.

Since changing a role is a significant event, the original value of
the role attribute is also stored in the original view, which can be used
for later comparison.

waveset.serverId

Use to set unique server names when your deployment includes multiple Identity Manager instances
that point to one repository on a single physical server. See Installation Guide for
more information.

accounts Attribute

The accounts attribute contains a list of objects
for each account linked to the Identity Manager user. Each account object contains
the values of the account attributes retrieved from the resource.

The name of each account object is typically the name of the associated
resource. If more than one account exists for a given resource, the object
names take a suffix of the form |n where n is
an integer. The first account on a resource has no suffix. The second account
has the suffix |2. The third account on a resource has |3, etc.

For example, if you have a resource named Active Directory that defines
an account attribute named Profile, the view path to this attribute would
be:

accounts[Active Directory].Profile

If this view path were used in a form field, it would prevent the value
of the global.Profile attribute from being propagated to
the Active Directory account.

Note –

You may want to use account-specific attributes in forms rather
than global attributes to prevent propagation of values to all resources

Overriding Resource Attributes

In addition to setting account attributes, you can also specify resource
attributeoverrides for each account. Resource
attributes are attributes that are defined for the resource definition in Identity Manager,
and consequently for the resource type. They are not attributes associated
with an individual account. Examples of resource attributes include the host
name of the server, or the base context in a directory.

You may want to create an account on a resource, but use a different
value for one of the resource attributes. You could do this by duplicating
the resource and changing the value, but excessive resource duplication can
be confusing. Instead, resource attributes can be overridden on a per-account
basis in the view.

Resource attribute overrides are stored in the attribute object under
an attribute named resourceAttributes. If, for example,
the resource defined an attribute named host, this could
be specified in the view with the path:

accounts[Active Directory].resourceAttributes.host

Note –

Although overriding resource attributes is not recommended, sometimes
you cannot avoid it. You might choose to overwrite a resource to avoid creating
duplicate resources that point to the same physical resource but differ by
one attribute. For example, in a customer environment that has multiple Active
Directory servers, it may make more sense to override the resource attribute host in the form than to create a new resource. Contact your Identity Manager support
representative for more information.

accounts[Lighthouse]

Sets the values of only the attributes stored in the Identity Manager repository.
When a view is created, it contains a copy of the attributes in the waveset.attributes attribute set. When the view is saved, the system compares the
contents of accounts[Lighthouse] with waveset.attributes to generate and update reports and audit log entries. Although
this attribute is stored in the Identity Manager repository, changes to this
attribute are not automatically propagated to resources.

The Extended User Attributes Configuration object
defines the attributes that are allowed in this view. The system ignores any
name found in this set of attributes that is not registered in the configuration
object.

The following code is a sample of the Extended User Attributes Configuration
object. This object maintains the list of attributes that are managed by the waveset.attribute set.

This object can be modified to extend the list from the default firstname, lastname, and fullname attributes.
In this case, an attribute called SSN has been added.

accounts[Lighthouse].delegates

Lists delegate objects, indexed by workItemType,
where each object specifies delegate information for a specific type of work
item

If delegatedApproversRule is the value
of delegateApproversTo, identifies the selected rule.

If manager is the value of delegateApproversTo, this attribute has no value.

This attribute takes the attributes contained in the Attributes of accounts[Lighthouse].delegate*
Attributes table.

accounts[Lighthouse].delegatesHistory

Lists delegate objects, indexed from 0 to n, where n is the current number of delegate history objects up to the delegate
history depth. This attribute takes the attributes contained in the Attributes
of accounts[Lighthouse].delegate* Attributes table.

accounts[Lighthouse].delegatesOrginal

Original list of delegate objects, indexed by workItemType,
following a get operation or checkout view operation. This attribute takes
the attributes contained in the following table.

Table 3–7 Attributes of accounts[Lighthouse].delegate*
Attributes

Attributes of accounts[Lighthouse].delegate* Attributes

Description

workItemType

Identifies the type of workItem being delegated.
See Delegate object model description for valid list of workItem types.

workItemTypeObjects

Lists the names of the specific roles, resources, or organizations on
which the user is delegating future workItem approval requests.
This attribute is valid when the value of workItemType is roleApproval, resourceApproval, or organizationApproval.

If not specified, the value of this attribute default is to delegate
future workItem requests on all roles, resources, or organizations
on which this user is an approver.

toType

Type to delegate to. Valid values are:

manager

delegateWorkItemsRule

selectedUsers

toUsers

Lists the names of the users to delegate to (if toType is selectedUsers).

toRule

Specifies the name of the rule that will be evaluated to determine the
set of users to delegate to (if toType is delegateWorkItemsRule).

startDate

Specifies the date when delegation will start.

endDate

Specifies the date when delegation will end.

accounts[Lighthouse].properties

The value of this attribute is an object whose attribute names correspond
to the properties defined by the user. User properties allow arbitrary custom
data to be stored with the user in the Identity Manager repository. You can
then use properties in forms and workflows. A property is similar in some
ways to an Extended User Attribute, but are not limited to primitive data
types such as strings or integers.

Identity Manager defines the tasks system property,
which is used by the Deferred Task Scanner to cause workflow tasks to be run
at some date in the future. The value of the tasks property
is a list of objects. The following table defines the attributes that belong
to objects in the list.

Table 3–8 Attributes of accounts[Lighthouse].properties

Attribute

Description

name

Identifies the name of the TaskDefinition object to run.

date

Specifies the date on which to run the task.

taskName

Identifies the TaskInstance that is created. If none is specified, Identity Manager generates
a random name.

owner

Identifies the name of an Identity Manager administrator that is considered
to be the owner of the task. If none is specified, the default owner is Configurator.

organization

Identifies the Identity Manager organization that the TaskInstance will
be placed in. If none is specified, an organization controlled by the task
owner is selected at random.

description

Descriptive text that will be stored in the TaskInstance when it is
created. This text is displayed in the task status page of the Identity Manager Administrator
Interface.

Sample Use

You can use the accounts[Lighthouse].properties value
to display a table of the deferred tasks assigned to a user. This list is
added to the form library named Default User Library, which is found in sample/formlib.xml.

The field that displays the deferred task table is named Deferred Tasks.
After modifying the waveset.properties attribute, the deferred task table
is now referenced by the default Tabbed User Form. If any deferred tasks exist,
the table will be displayed at the bottom of the Identity tab panel.

accounts[Lighthouse].viewUserForm

Used to display a view-only User form. This view-only form displays
field information as Labels, to ensure that the administrator cannot change
values, although he can list, view, and search on this user information. (The
administrator selects a user from the accounts list, then clicks View to see user details.)

accounts[<resource>].properties

Used to store account properties in the Identity Manager repository.
Use this attribute if you have some information about the account -- for example
the date it was created -- that cannot be stored as a native account attribute
on the resource.

accounts[<resource>].waveset.forceUpdate

Used to specify a list of resource account attributes that will always
be sent to the resource for update when a user is modified and that an attribute
value remains available to resource actions. This attribute is required for
resource actions to be run when a user is unassigned from a resource.

The following field definition from a user form uses a Solaris resource.
(<resource> has been replaced with the name of the resource.):

The preceding code causes Identity Manager to send the delete
after action and Homedirectory attribute
to the provisioner and resource adapter.

global Attribute

You can use the global attribute set of the user view to conveniently
assign attributes to many resource accounts (including Identity Manager). The
value of the global attribute is an object whose attributes
are referred to as global attributes. When the view is
saved, the system assigns the value of each global attribute to all resource
accounts that define the global attribute name in their schema map. These
values are also propagated to the Identity Manager repository if there is an
extended attribute with the same name.

For example, two resources R1 and R2 define an attribute named fullname. When
the attribute global.fullname is stored in the view, this
value is automatically copied into attributes accounts[R1].fullname and accounts[R2].fullname.

You can also use global attributes to assign extended attributes that
are stored in the Identity Manager repository. If a global attribute is also
declared as an extended Identity Manager attribute, it is copied into accounts[Lighthouse].

Note –

Do not use global.accountId when creating accounts.
The account ID is created by the DN templates on the resources. Using global.accountId overrides this, which may cause problems.

Referencing Two Different Fullname Attributes

The global attribute can be used in combination with
the account attribute for the same attribute name. For
example, on an Active Directory resource, the structure of the fullname is lastname, firstname. But all other resources
that have a fullname use firstname lastname.

The following example shows how you can reference these two fields in
a form.

In the preceding example, creating a new user works as expected. However,
when you load the user, the fullname attribute from the
Active Directory resource can be used to populate the global.fullname field.

A more accurate implementation for this scenario would be to declare
one resource to be the authoritative source for an attribute and create a Derivation rule such as the following:

By defining a Derivation rule, the value of the fullname attribute in the LDAP resource will be used first to populate
the fullname field. If the value does not exist on LDAP,
then the value will be set from the AD resource.

accountInfo Attribute

Contains read-only information about resource accounts associated with
the user. It is used within system views besides the user view. Some information
in this view is a duplicate of the information found in the waveset.accounts attribute. There are two reasons for this duplication:

Information in this view is structured so that it is easier
to use in forms

This view can be used as a component of other views without
including the entire waveset view.

Most account information is stored in the accountsInfo.accounts attribute.
Other attributes simply contain lists of account names. It is common to use
a FieldLoop in a form to iterate over the names in one
of the name list attributes, then use this name to index the account list
attribute.

For example, the following form element generates a list of labels that
contain the names of each resource that is assigned indirectly through a role.

Lists (in flat list format) resources assigned to the user through the
role.

accountInfo.privates

Lists (in flat list format) resources assigned directly to the user.

accountInfo.toCreate

Lists names of all resources currently assigned to the user but for
which accounts do not yet exist in Identity Manager.

accountInfo.toDelete

Lists names of resources that are no longer assigned to the user, but
that are still known to exist.

accountInfo.types

Lists each type of resource that is currently assigned to the user or
through Reserve Groups.

accountInfo.typeNames

Lists unique type names for every assigned resource.

accountInfo.accounts

Contains a list of objects that themselves contain information about
each associated resource account. Elements in the accounts list are referenced
by name, where the name is the name of the resource.

Example

accountInfo.accounts[Active Directory].type

Objects found in the accountInfo.accounts list have
the following attributes, as defined in the following table.

Table 3–10 accountInfo.accounts. Attributes
(User View)

Attribute

Description

attributes

Information about all the account attributes defined by this resource.

name

Name of the resource where the account exists or will be created.

id

Repository ID of the resource.

type

Resource type name.

accountId

Name of the user’s account on this resource.

assigned

True if the account is currently assigned. Accounts that are not assigned
can be deleted by Identity Manager.

protected

True if the account is currently protected. This means that update or
delete operations on the account are ignored.

passwordPolicy

Information about the password policy defined for this resource.

accountInfo.accounts[ ].attributes[ ]

Contains information about all the account attributes defined by this
resource. These attributes are listed on the schema map page of the resource.
The value of the attribute is a List of objects.

The following table defines the attributes that these objects contain.

Table 3–11 accountInfo.accounts. Attributes
(User View)

Attribute

Description

name

The name of the Identity Manager resource account attribute. This name
is defined in the resource schema map.

syntax

The syntax of the attribute value. The value of the syntax attribute
is one of the following values.

int

string

boolean

encrypted

binary

complex

Refer to the Resource Reference to determine if binary or complex attributes
are supported for the resource. An exception is thrown if you attempt to send
binary or complex attributes to a resource that does not support these attributes.

Binary attributes should be kept as small as possible. Identity Manager will
throw an exception if you attempt to manage a binary attribute that is larger
than 350 KB. Contact Customer Support for guidance if you need to manage attributes
larger than 350 KB.

multi

True if the attribute allows multiple values.

If you are designing a form, do not worry about the declared resource
account attribute types. The user view processing system makes the appropriate
type coercions when necessary.

accountInfo.accounts[].passwordPolicy

A resource can be assigned a password policy. If an attribute has an
assigned password policy, the value of this attribute will contain information
about it.

The following table defines the attributes in the accountInfo.accounts[resname].passwordPolicy.

The name of policy. This corresponds to the name of a policy object
in the Identity Manager repository.

summary

A brief text description of the policy including information about each
of the policy attributes.

attributes

The value of this attribute is another object that contains the names
and values of each policy attribute.

Applications that display policy information typically display the summary
text, but if you need more fine-grained control over the display of each policy
attribute, you can use the attributes map.

Forms that provide an interface for changing and synchronizing passwords
often use this information.

accountInfo.accounts[Lighthouse]

This special entry in the accountInfo list is used
to hold information about the Identity Manager default password policy. This
is convenient when displaying password forms since information about the Identity Manager password
and policies must be displayed along with the information for resource accounts.

This element is present only when pass-through authentication is not
being used. The resource type is Lighthouse.

accountInfo Resource Name Lists

The accountInfo view includes attributes that contain
lists of resource names. Each list is intended to be used in forms with FieldLoop constructs to iterate over resources with certain characteristics.

The accountInfo attributes that can contain resource
names are:

assigned

created

fromRole

private

toCreate

toDelete

accountInfo.assigned

Identifies the resources that are assigned to the user. If you are designing
a form, you can call this attribute to display a list of resources that are
assigned from the role, applications, and that are directly assigned to a
user.

accountInfo.typeNames

A list of unique type names for every assigned resource. This is used
in Disable expressions in forms where you want to disable fields unless a
resource of a particular type is selected.

This returns the same information as the path accountInfo.types[*].name but is more efficient, which is important when used with Disable expressions. This list can include common resource types.

You can determine the resource type names by bringing up the resource
list from the Identity Manager Administrator Interface. The Type column on this page contains the names of the
type of currently defined resources. The options list next to New Resource also contains the names of the resource
adapters that are currently installed.

accountInfo.types

This attribute contains information about each type of resource that
is currently assigned. The value of the attribute is a List (objects).

The following table shows the attributes that belong to each object.

Table 3–13 accountInfo.types Attributes
(User VIew)

Attribute

Description

accounts

List of accountIds for each account assigned to the
user that is of this type

name

Resource type name

For example, you can determine a list of IDs for all UNIX accounts with
the following path:

accountInfo.types[Unix].accounts

display Attribute

The display attribute contains information that relates
to the context in which the view is being processed. Most of the attributes
are valid only during interactive form processing.

The following table shows the most used display view
attributes.

Table 3–14 Most Used display Attributes
(User VIew)

Attribute

Description

eventType

Indicates whether the user view is servicing a create or update request,
as indicated by the values create or update (read-only).

session

A handle to an authenticated Identity Manager session. This attribute
is valid only during interactive editing session in the Identity Manager Administrator
Interface. It is provided as an access point into the Identity Manager repository.
The value of this attribute can be passed to methods in the com.waveset.ui.FormUtil class.

The display.session attribute is not valid in the
following cases where form processing may occur:

in the bulk loader

during background reprovisioning

in unsynchronized actions or approvals

Best practices suggest using this attribute only within a Property or Constraints element. In almost all existing
forms, display.session is used only in Constraints elements.

subject

An object holding information about the credentials of an Identity Manager user
or administrator. This value is set in almost all cases, but is typically
used in workflow applications called during background activities where the display.session is no longer valid. The subject can be used to get
a new session. In this case, it is used for gaining access to the repository.

state

A handle to a _com.waveset.ui.util.RequestState_ object
that in turn contains handles to objects related to the HTTP request such
as the _javax.servlet.http.HttpSession_.

Default itemType Behavior

Typically, only wizard itemTypes cause a workflow
to transition directly to a WorkItem if the requester is the owner of the
workItem.

When itemType is set as follows, the workflow will
not transition into a WorkItem, but will instead appear under the Approval
tab:

approval

custom

itemType

Overriding Default Behavior

You can override behavior in the User view by setting the allowedWorkItemTransitions option as a property of the form as follows:

Deferred Attributes

A deferred attribute is an attribute that derives
its value from an attribute value on a different account. You declare the
deferred attribute in a view (and the WSUser model), and the provisioning
engine performs this substitution immediately before calling the adapter.

If the deferred attribute derives its value from another resource’s
GUID attribute, the source adapter does not need to take action. However,
if the source attribute is not the GUID, the adapter must return the attribute
in the ResourceInfo._resultsAttributes map as a side effect of the realCreate
operation. If the adapter does not return the attribute, the provisioning
engine will fetch the account to get the value. This is less efficient than
modifying the adapter to return the value.

When to Use Deferred Attributes

Use deferred attributes when creating new accounts to specify that the
value of an account attribute is to be derived from the value of an attribute
on a different account that will not be known until the source account has
been created. One common example is to set an attribute to the value of the
generated unique identifier.

Using Deferred Attributes

There are two main steps to defining a deferred attribute:

To Define a Deferred Attribute

Ensure that the account is created on the source resource before
the second account is created. Do this by creating an ordered Resource Group
that contains both resources and assigning the Resource Group to the user.

Set the special attributes in the User view for the accounts that
are to be created as indicated by the following sample scenario. Each deferred
attribute requires two view attributes: one that identifies the source account,
and one that identifies the source attribute. Set these using paths of the
following form:

where <resource> would be replaced with an actual
resource name and <attname> replaced with an actual
attribute name.

For example, assume a scenario in which the following
two resources are created: 1) a resource named LDAP that generates a uid attribute when an account is created; 2)a resource named HR, which
contains a directoryid attribute named directoryid,
whose value is to be the same as uid in the LDAP resource.

The following form fields set the necessary view attributes to define
this association.

This Derivation expression invokes the dumpFile method,
which generates the file after the User form is displayed for the first time.
The form_inputs variable is automatically bound to the
view that is being used with this form.

In the preceding example, the String argument to the dumpFile method
is a file system path, where you substitute a valid path for c:/temp/view.xml.