Identity Manager 8.1 Deployment Reference

This section contains new information and documentation corrections for Sun Identity Manager Deployment Reference.

Forms-Related Documentation Issues

The following description of adding a password confirmation challenge to forms is missing from this chapter: (ID-7604)

You can use the RequiresChallenge form property to add a password confirmation challenge to select forms. When this feature is enabled, Identity Manager will challenge the currently logged-in administrator for his password before processing a request. The forms that supporting this option include:

userForm (Tabbed User Form, Wizard User Form, Default User form)

changePassword (by default, Change User Password form)

resetPassword (by default, Reset User Password form)

The property is specified different for each of the forms.

Setting the RequiresChallenge Property for User Forms

To add a password confirmation challenge to a user form, add the following RequiredElement element as shown below, with substitutions for password, email, and fullname:

<Property name='RequiredChallenge'>
    <List>
      <String>password</String>
      <String>email</String>
      <String>fullname</String>
    </List>
</Property>

The value of the property is a list of one or more of the following User view attribute names: applications, adminRoles, assignedLhPolicy, capabilities, controlledOrganizations, email, firstname, fullname, lastname, organization, password, resources, roles.

Setting the RequiresChallenge Property for Change Password and Reset Password Forms

To add a password confirmation challenge to either a changePassword or resetPassword form, add the following <RequiresChallenge> element as shown below, with substitutions for password, email, and fullname:

<Property name='RequiresChallenge' value='true'/>

where the value of the property can be either "true" or "false".

If the property is set to "true" in the form, Identity Manager will challenge the current administrator who is requesting the change to enter the password he used to log in to Lighthouse. If the challenge is not successful (that is, the current administrator's password is not entered), Identity Manager will not permit the change. If the challenge is successful, Identity Manager will permit the change request to proceed. Both password management forms support the use of the 'RequiresChallenge' form property. When this property is set to true, the user is prompted to enter the old password after specifying the new password.

Overriding Version Information

You can create two custom message catalog keys that prevent Identity Manager from displaying the version information when a user places the cursor over the help button. The UI_END_USER_VERSION key hides the version information on the end user interface, while the UI_VERSION key is used by the administrator interface.

Setting the value of the key to the empty string prevents any version information from being displayed.

The following example disables version information for both interfaces.

<Waveset>
   <Configuration name="sampleCustomCatalog">
      <Extension>
         <CustomCatalog id="defaultCustomCatalog" enabled="true">
            <MessageSet language="en" country="US">
               <Msg id="UI_END_USER_VERSION"></Msg>
               <Msg id="UI_VERSION"></Msg>
            </MessageSet>
         </CustomCatalog>
      </Extension>
   </Configuration>
</Waveset>

Other Forms-Related Issues

The "Forms" chapter is missing the following discussion: (ID-18869)

By default there are two implementations of the change password form:

The End User Password Change form is the default password change form. It presents a simple set of fields with which the user can change their password. The password policies for all resources that are assigned to the user are aggregated and summarized, and Identity Manager applies the password change to all assigned resources.

The Basic Change Password Form is present in both the Administrator and User Interfaces. It provides information about the resources that are assigned to the user and allows the user to individually select on which resources Identity Manager will change the password.

Both password management forms support the use of the 'RequiresChallenge' form property. When this property is set to true, the user is prompted to enter the old password after specifying the new password.

Issues Common to Both Workflows and Forms

The Forms and Workflow chapters of this guide are missing the following discussion about assigning scope to <Variable> elements: (ID-14915)

Identity Manager assigns a scope to all <Variable> elements when the element is declared. If you do not assign a value to the scope attribute, Identity Manager assigns it a value of local, which means that the variable can be accessed only within the XPRESS section that is declared in.

Additional Variable attributes that define scope include:

input -- Declares that the <Variable> element has local scope and that the value can be initialized by the caller.

output -- Declares that the <Variable> element has local scope but can be returned to the caller.

external -- Declares a <Variable> that has non-local scope - that is, assignments to this variable will result in assignment to this variable in the scope it was first declared in.

The following discussion of the Identity Manager whitelist feature is missing from this chapter. (ID-19474)

The Identity Manager whitelist feature makes it possible to check forms and workflows that use the SaveNoValidate action against a list of IDs or form names. Identity Manager checks the whitelist for either form names or form-owner IDs.) The list of IDs, called saveNoValidateAllowedFormsAndWorkflows, is located in the security attribute in the System Configuration object. If the form name or owner ID is on the whitelist, the form or workflow can use the SaveNoValidate action. If the form name or the owner ID is not on the list, the form or workflow is processed using a Save action. If the list is not present, all forms and workflows can be processed as SaveNoValidate.

To implement this feature in your deployment, you must add any forms or workflows using SaveNoValidate to the saveNoValidateAllowedFormsAndWorkflows list in the System Configuration object. To see the IDs or form names that you must add, check the syslog or turn trace level 4 on for com.waveset.ui.util.GenericEditForm and submit any custom forms or workflows that use SaveNoValidate. A warning including the ID will be logged. If you are getting "null" form names in the syslog, confirm that the form in the TaskDefinition that was run has a name attribute.

Workflow-Related Issues

The Workflow chapter is missing the following discussion of the handleNativeChangeToAccountAttributes workflow (ID-3275):

Whenever Identity Manager detects a native change (that is, a change not performed through Identity Manager) to the values of an auditable attribute of a resource account, it responds by running the handleNativeChangeToAccountAttributes workflow, which is associated with this System Configuration object attribute:

<Attribute name='process'>
  <Object>
    <Attribute name='handleNativeChangeToAccountAttributes' value='Audit Native
      Change To Account Attributes'/>
  </Object>
</Attribute>

This workflow logs the native change events to the event log if you have enabled the Changes Outside Lighthouse audit filter. Otherwise, Identity Manager ignores the event. Warning: Be careful which methods you call from any workflow that replaces the default workflow listed above.

Because Identity Manager launches this workflow whenever a resource account fetch reveals a native change, it must not invoke any method or workflow that would trigger another fetch of the same resource account. For example, an infinite loop will result if you call any WorkflowServices method that assembles the user view: getView(User),checkoutView(User) and possibly checkinView(User).

The fact that Identity Manager handles each native change by running a workflow allows you to hook the native change event, and to handle that native change however you see fit by replacing or adding to the default native change workflow. For example, you might choose to send email to an administrator or a user, to record the event in a database, to queue an update that would back out the native change, or even to pull that native change into and push it back out to the other resources.

The Workflow chapter of this guide is missing the following description of how to specify the subject or administrator of a source adapter task. (ID-19694).

You can assign a subject or administrator to a Source adapter task and designate the server on which it runs by editing the following attributes of the system configuration object. source.subject specifies the login name of administrator designated as the owner of this task. sources.host specifies the server on which the task runs. The new values in the configuration object are by default:

<Attribute name='sources'>
           <Object>
             <Attribute name='hosts'/> <!-- any host is the default -->
           <Attribute name='subject' value='Configurator'/>
         </Object>
         </Attribute>