|
| |
| Sun Java System Identity Manager 2005Q4M3 Technical Deployment Overview | |
C
LDAP Deployment Scenario
The LDAP scenario illustrates how Identity Manager can be deployed in an environment where user accounts are defined on a LDAP resource. This scenario assumes that LDAP is the only resource to be managed. (Name of scenario 2) illustrates the process of deploying Identity Manager across multiple resource.
FeaturesThe LDAP scenario contains about 50 XML files that are loaded into Identity Manager. These files create and configure the following types of objects:
In addition, the scenario also provides several JSP files as well as a sample LDIF file that can be loaded onto your directory server. The LDIF file defines several users, several of which are managers.
The most important features of the scenario include the following:
- Managers can edit account attribute data for their subordinates. Managers are not explicitly granted the capabilities needed to access the Administrator Interface. However, they can view a linked list of their subordinates from the User Interface, and from this list, managers can access the account attributes for their subordinates.
- When a user edits account attribute data from the User Interface, the user’s manager must approve the change for it to take effect. This is optional and only works if configured.
- Users can request access to a resource. The list of available resources is generated dynamically. Any resources that are already assigned to the user, either directly or through a role, are not displayed.
- The answer to a default authentication question is derived from an LDAP attribute.
PrerequisitesThe LDAP scenario illustrates the integration of Identity Manager with the following products:
Other directory servers and e-mail servers will not work with this scenario unless you customize the provided scripts.
In addition, Directory Server and Messaging Server must use the same LDAP base context.
Loading and Configuring the ScenarioPerform the following steps to configure your environment:
Important! Do not load the scenario in an existing production environment. The scenario reconfigures several system attributes.
Step 1: Set Up Directory Server
- Create a user named IdM User in the base context, such as cn=IdM User,dc=example,dc=com. This user will be used by the LDAP resource adapter to provision to the directory.
- Change the access control on the base context (dc=example,dc=com) to allow IdM User to have full control (read, compare, search, write, delete, add).
- Enable the changelog on the Directory Server. From the Configuration tab of the Directory Server administrative console, click Data, then click on the Replication tab on the right. Check the Enable Changelog check box. If you are using Directory Server 5.0 or higher, also enable the Retro Changelog Plugin in the administrative console.
Then restart Directory Server.
- Change the access control on cn=changelog to allow IdM User to read and search.
- Import the $WSHOME/sample/scenarios/scenario1/schema.ldif file into Directory Server.
- Import the $WSHOME/sample/scenarios/scenario1/
scenario1Data.ldif file into Directory Server.Step 2: Configure Messaging Server
Note The LDAP scenario has been tested using Schema 1 for the mail server. The scenario should work with Schema 1.5 (compatibility mode) and Schema 2.
Add or modify the following option in the MessageServeroot/config/
option.dat file to ensure that the mail forwarding and autoreply features work:DELIVERY_OPTIONS=*mailbox=$M%$\\$2I$_+$2S@ims-ms-daemon, \
&members=*, \
*native=$M@native-daemon, \
/hold=@hold-daemon:$A, \
*unix=$M@native-daemon, \
&file=+$F@native-daemon, \
&@members_offline=*, \
program=$M%$P@pipe-daemon, \
#forward=**, \
*^!autoreply=$M+$D@bitbucket
Step 3: Load the Scenario
Use the following procedure to load the LDAP scenario into Identity Manager.
- Configure Identity Manager so that it can display and operate task templates. Edit the $WSHOME/config/Waveset.properties file and set gui.enableTaskTemplateEditor=true.
- Login in to Identity Manager as Configurator.
- From the Identity Manager menu bar, click Configure, and then click Import Exchange File.
Note The browser must be launched from the Identity Manager server or have access to the files contained in the idm/sample directory on the Identity Manager server.
- Enter the name or browse to the $WSHOME/sample/scenarios/scenario1
/scenario1.xml file, and then click Import.Identity Manager displays a message indicating that the file imported successfully.
- Copy the contents of $WSHOME/sample/scenarios/scenario1/jsp/ into $WSHOME/user/. These JSP files are necessary for enabling a manager to edit a subordinate’s data and for users to request access to a resource.
Step 4: Configure the LDAP Resource Adapter
Loading the scenario creates a resource named LDAP Resource. This resource must be configured to match your environment.
Use the following procedure to minimally configure the LDAP Resource. Additional configuration might be required.
- From the Identity Manager menu bar, click Resource.
Resources are grouped by type, which are represented in the list by named folders. To expand the hierarchical view and see currently defined resources, double-click the resource type folder or click + (plus sign) next to the folder.
- Right click on the LDAP Resource icon and select the Edit -> Resource Wizard option from the pop-up menu. The Resource Parameters page is displayed.
- At minimum, configure the following fields so that they match your environment:
- Host
- User DN
- Password
- Base Contexts
Note The User DN field defaults to cn=IdM User,dc=example,dc=com. This value should be changed to the user created in Step 1: Set Up Directory Server.
Click Next to display the Account Attributes page.
- No configuration is required at this point on the Account Attributes page. See LDAP Resource Attributes on page C-6 for more information about the account attributes.
Click Next to display the Identity Template page.
- The identity template defines account name syntax for users. Update the value for the identity template. For an LDAP resource, this value in the general format:
uid=$accountId$,ou=OrganizationUnit,BaseContext
Click Save.
- For now, disable the ActiveSync feature of the adapter.To do this, right click on the LDAP Resource icon and select Edit -> Edit Active Sync Running Settings. by changing the value of the Startup Type parameter to Disabled.
Also change the Proxy Administrator to Configurator or other administrator with the capabilities necessary for processing changes on the resource.
Click Save.
- Restart the application server in order to disable the ActiveSync functionality.
Step 5: Configure Email Templates
In the LDAP scenario, Identity Manager sends an email in the following circumstances:
Use the following procedure to configure the Identity Manager email templates.
- From the menu bar, click Configure, and then click Email Templates.
- Click the link for LDAP ActiveSync Account Creation Notification.
- Change the values of the SMTP Host and From fields. Edit other fields as desired.
- Click Save.
- Repeat steps 2 through 4 for the Account Update Notification email template and any other template you wish to implement.
After you have loaded the LDAP scenario and made the necessary configurations, there are no specific steps that you must perform. However, it is recommended that you use the procedures listed in the remainder of this chapter to explore the capabilities provided in the scenario. Unless otherwise specified, all files mentioned in this scenario are loaded by default.
Sample Directory OverviewThe scenario1Data.ldif file defines several default users, some of which are managers. The following table lists each user and indicates the user’s manager and subordinates, if any.
To view end-user functions of this scenario, log in to the User Interface with the User ID listed in the table. The password for all users in this scenario is hello.
Creating and Configuring Identity Manager ObjectsThis section discusses how selected Identity Manager objects are created and configured as a result of loading the LDAP scenario. These objects are needed to support this scenario.
LDAP Resource Attributes
The users defined in the scenario1Data.ldif file contain attributes from standard object classes such as inetOrgPerson. Additional attributes are defined in Messaging Server object classes such as inetmailuser. If you are using the LDAP scenario with a mail server other than Messaging server, you must update the schema map for the LDAP resource.
The following table lists the account attributes that were added for the LDAP scenario. If you are using a directory server or e-mail server other than those supported for this scenario, you may need to make changes to the account attributes.
In addition, the following LDAP attributes are queried on Directory Server, but are not mapped to Identity Manager:
Admin Roles
The AdminRole-User.xml file creates two admin roles:
The User admin role is defined in the AdminRole-User.xml file. This admin role assigns the User Account Administrator capability to the My Employees organization and allows a manager to edit the data of his or her subordinates. The User admin role also grants the Approver capability to the Top organization.
Roles
The Mail Users role assigns the LDAP resource to the user. The role is defined in the Role-MailUser.xml file.
If a user exists in the directory and it contains the inetuser, ipuser, inetmailuser, inetlocalmailrecipient, and userpresenceprofile object classes, the user will be assigned the Mail Users role when it is created in Identity Manager. If one or more of these object classes are missing, the role is not applied to the user.
When a user is created from Identity Manager and the Mail Users role is enabled, an email account will be created on the Messaging Server upon reconciliation. Since the user has a mail account, it will pass the rule Is Mail User (Rule-IsMailUser.xml).
The LDAP scenario assumes that there might be users defined in the directory that should not have mail accounts. If all users in the directory should have an email account, then do the following:
Object Groups
The scenario creates the following object groups:
Users — The virtual organization in which reconciled users are placed. This organization is defined in the ObjectGroup-Users.xml file.
My Employees — This virtual organization is assigned in the User admin role. It invokes the Get My Subordinates rule. This organization is defined in the ObjectGroup-MyEmployees.xml file.
Login Application and Login Module Group
Identity Manager uses pass-through authentication to resolve the validity of the LDAP password for the end-user pages. The Administrative GUI uses the Identity Manager user’s password. To enable this feature, the scenario uses the following files to create the LDAP Login Module Group for the User Interface.
General Configuration
The following files configure miscellaneous aspects of the LDAP scenario.
Configuration-UserUIConfig.xml — Adds the manager attribute to the SummaryAttrNames and QueryableAttrNames attributes so that administrators can search for users by specifying their manager’s distinguished name.
Configuration-UserExtendedAttributes.xml — Adds manager to the view of the User object.
Configuration-CustomMessageCatalog.xml — Defines strings that are displayed in the on the user interfaces.
The following table lists the form and process map changes.
Creating User AccountsCreating user accounts is one of the most important activities that an administrator performs. In the LDAP scenario, the majority of the user accounts are created when Identity Manager initially loads accounts from the directory server. However, other accounts will be loaded by ActiveSync, or created by an administrator in Identity Manager. This section describes the process of creating users with each of these mechanisms.
Using Reconciliation to Create Users
Before performing a reconciliation, the reconciliation policy must be configured, and a user form must be assigned to the user performing the reconciliation.
Reconciliation Policy
Reconciliation policy allows the administrator to select the server to run reconciliation, determine how often and when reconciliation takes place, and set responses to each situation encountered during reconciliation. You can also configure reconciliation to detect changes made natively (not made through Identity Manager) to account attributes.
Identity Manager provides a default global reconciliation policy, which can be inherited for any resource. However, the LDAP scenario requires some changes to the default policy, and these changes are defined in the Configuration-ReconcileConfiguration.xml file.
There are two significant changes to the default policy:
- The proxy administrator is set to Reconciliation Admin. When a reconciliation response is performed, it is performed as this administrator. The Reconciliation Admin has been configured to create users with the User Form with Questions user form. If you need to login as Reconciliation Admin, the password is reconadmin.
If you want to use a different user to perform this function, assign the default user form to User Form with Questions. In addition, ensure the user has the Bulk Account Administrator capability.
- The UNMATCHED situation is configured to create a new user based on resource account. When Identity Manager detects an account on the resource that does not have a corresponding account on Identity Manager, it creates a new Identity Manager user.
User Form
The User Form used for reconciliation (User Form with Questions) is defined in the UserForm-UserFormWithQuestions.xml file. This user form is meant to be used for reconciliations and load-from-resource operations only.
The default user form contains overhead that is not necessary for loading account data. The User Form with Questions form has been trimmed down so that it defines the following:
- The user’s global full name, which is determined by concatenating the user’s first and last names
- The user’s organization, which is set to Top:User
- The answer to the user’s authentication question. (See Setting Answers to Authentication Questions on page C-21 for more information.)
Account information loaded from a resource is stored in a User object and can be accessed from the User view. As a result, detailed information about each user does not need to be referenced in the user form. The User Form with Question form contains minimal data to help speed the process of reconciliation. In a production environment with thousands of users, the reconciliation process can take hours. Therefore, eliminating all unnecessary fields and attributes speeds up the reconciliation process.
The full name and authentication answers remain in the user form because they are derived attributes. The organization specifies the Identity Manager virtual organization into which the user object should be placed.
Workflow
The LDAP scenario uses the standard Create User workflow when creating user accounts via reconciliation.
Testing Procedure
After the LDAP adapter has been configured, you can perform a reconciliation so that user data can be populated into Identity Manager.
Log in to Identity Manager as Configurator and initiate a full reconciliation by right-clicking on the LDAP resource and selecting the Full Reconcile Now option. When reconciliation is complete, the status of all reconciliation attempts is displayed.
Using ActiveSync to Create Users
ActiveSync is another mechanism for loading resource account data into Identity Manager. ActiveSync “listens” or polls for changes to a resource, detecting incremental changes in real time. Because ActiveSync is designed to detect changes, it should not be used to load account information into Identity Manager for the first time.
The LDAP scenario enables changes from LDAP to be propagated into Identity Manager. Once a new users are detected with the ActiveSync functionality, the new users can immediately log in to the end user pages to manage their accounts.
The scenario also creates a temporary password and emails it to the new user. This is necessary for two reasons. First, it is possible to create an account in LDAP without a password. Therefore, the user would not be able to log in to Identity Manager. Secondly, passwords are usually not readable from LDAP. This means that if the LDAP ActiveSync is to be the authoritative source of the user's password, Identity Manager will not be able to synchronize the passwords on other resources with the LDAP password. In order for the passwords to be consistent among all resources, a temporary password should be used, which the user will use to login and change all resource passwords.
User Form
The LDAP ActiveSync Form translates ActiveSync attributes into Identity Manager user attributes. A temporary password (change12345) is created in this form.
The viewOptions.Process field (listed below), causes the LDAP ActiveSync Create User and LDAP ActiveSync Update User workflows to run for creates and updates respectively. For other operations (such as delete), the normal user workflows will be run.
<Field name='viewOptions.Process'>
<Comments>Use the optimized create and update workflows.</Comments>
<Expansion>
<switch>
<ref>feedOp</ref>
<case>
<s>create</s>
<s>LDAP ActiveSync Create User</s>
</case>
<case>
<s>update</s>
<s>LDAP ActiveSync Update User</s>
</case>
<case default='true'>
<null/>
</case>
</switch>
</Expansion>
</Field>
Workflow
The TaskDefinition-LDAPActiveSyncCreateUser.xml file defines the workflow to run when a user is created through ActiveSync. This workflow is run whenever a user is discovered on the resource.
This workflow has been reduced to two actions. The first action is to provision the account in Identity Manager. The workflow then sends an email notification that contains the temporary password (chagne12345) to the newly-created user.
Also, the resultLimit workflow attribute is set to 0. This also helps speed up the workflow in that the results in the repository.
Email Template
The EmailTemplate-LDAPActiveSyncAccountCreationNotification.
xml file defines an email template that sends a temporary password to the newly created user.Testing Procedure
Prerequisites
The LDAP resource must be configured for ActiveSync. In Step 4: Configure the LDAP Resource Adapter on page C-4, ActiveSync was disabled. Run the Active Sync Wizard by right clicking on the LDAP resource and selecting Edit > Active Sync Wizard.
- On the Synchronization Mode page set the Input Form field to LDAP ActiveSync Form. Then click Next.
- On the Active Sync Running Settings page:
- Change the Startup Type to Automatic or Manual.
- Set the Proxy Administrator to Configurator or other administrator with the capabilities necessary for processing changes on the resource.
- Specify a directory to which a log file will be written in Log File Path.
- Assign a value such as 5 minutes in the Poll Every field.
Then click Next.
- On the General Active Sync Settings page, set the Filter Changes By field to cn=IdM User. This will prevent changes that were provisioned into the resource from Identity Manager from being reprocessed as Active Sync events.
Then click Save.
Restart Identity Manager to allow the changes to take effect.
Procedure
Use the following steps to test that Identity Manager creates a new user when an account is detected on an ActiveSync resource.
- Create a new inetOrgPerson in the base context directory using the directory server’s native tools. Do not use Identity Manager to create the user.
- Wait for the amount of time specified in the Poll Every field until the ActiveSync changes are loaded into Identity Manager. In some circumstances, you might need to start ActiveSync.
- In Identity Manager, click the Accounts tab. The user has been added to the Users organization.
- Log in to the User Interface using the new user's account ID and temporary password.
- Use the “Change Password” link to change the user's password.
The end result is that users created externally in LDAP are given accounts in Identity Manager. A temporary password is set on the LDAP resource, and the user is notified of the temporary password.
Using Identity Manager to Create Users
The LDAP scenario requires customized user forms, workflows, task templates, and notifications. These aspects are discussed in detail.
User Forms
The following user forms help create new Users
Custom Tabbed User Form
The LDAP scenario replaces the Tabbed User Form with the Custom Tabbed User Form. The standard Tabbed User Form controls the layout of the Create and Edit User pages. These pages have several navigation tabs that allow the administrator to set or view a user’s identity, assignments, capabilities, and resource attributes. The Custom Tabbed User Form is essentially the same, except that it uses a field reference to “Resource Tabs” in the UserForm-CustomDynamicUserForms.xml file (Custom Dynamic User Forms) instead of MissingFields. This will generate an LDAP tab if the user has been assigned an LDAP resource, either directly, or through a role. The Custom Dynamic User Forms in turn references the Custom Dynamic LDAP User Form.
To register a replacement Tabbed User Form, the userForm form mapping must be changed. The scenario automatically changes the userForm value to Custom Tabbed User Form.
Custom Dynamic LDAP User Form
The Custom Dynamic LDAP User Form controls the LDAP-specific attributes on the Create or Edit User page. It divides the LDAP-specific attributes into two sections: User Attributes and Mail Attributes.
In the User Attributes section, the Manager field contains a drop-down menu containing a list of managers. This list is populated by calling the Get Managers rule, which checks for accounts on the LDAP resource where the ismanager attribute is set to Y. The rule returns the entrydn attribute for each account that meets that criterion.
The Groups multi-select box is populated by the Get LDAP Groups rule. This rule queries the resource and returns a list of LDAP groups. If the account is already a member of an LDAP group, the group is placed in the Current Groups box.
On the Assignments navigation tab, if the Mail Users role is assigned to a user, then the Mail Account Created field contains a value of Yes. If the LDAP resource is assigned directly, without the role, then the Create Mail Account button is displayed. When this button is clicked, then the user is assigned the Mail Users role, and the button disappears.
The user form performs a validation on any value entered in the Primary Email and Other Email fields. The system checks for matching email addresses on the directory server. If a match is found, an error message is displayed.
Workflow
In the LDAP scenario, a task template is launched when a user is created from the Administrative interface. A task template is a set of components and product enhancements that enable administrators to configure workflow behavior through the Administrative Interface, instead of writing customized workflows to achieve the same result.
Task templates can be accessed by clicking Tasks, then the Task Templates subtab.
A task template contains the following elements:
- TaskDefinitionRef — Defines which TaskDefinition will be launched to perform the action, in this case, to create a user. Standard workflows are often defined as a TaskDefinition.
- FormRef — A reference to a form that can generate a user interface for configuring a TaskTemplate.
- Variables — Contains attributes that are used in configuring the task. Variables are not discussed here.
(Cross reference to new Task Template documentation.)
The following XML fragment shows the top of the TaskTemplate-CreateUser.xml file:
<TaskTemplate id='#ID#TaskTemplate:CreateUser' name='Create User Template' taskType='TaskConfiguration' visibility='invisible'>
<TaskDefinitionRef>
<ObjectRef type='ProvisioningTask' name='Create User'/>
</TaskDefinitionRef>
<FormRef>
<ObjectRef type='UserForm' name='Create User Template Form'/>
</FormRef>
...
</TaskTemplate>
The TaskTemplate is named Create User Template. The TaskDefinitionRef points to the Create User ProvisioningTask, which is the standard workflow for creating users. The FormRef refers to the Create User Template Form, a pre-defined form that controls the process of creating a user through a TaskTemplate.
Approvals
The Create User Template task template defines an approval workflow that runs when a user is created in Identity Manager. This task template does not configure notifications or other template features, but they can still be implemented, if desired, in this scenario.
To enable the Create User Template, the following prerequisites must be met:
- The createUser process map must be updated to point to the Create User Template. Click Configure, then the Form and Process Mappings subtab. Under the Process Mappings section, change the value for createUser from Create User to Create User Template. This mapping has already been configured in the LDAP scenario.
- The Get Managers rule (Rule-GetManagers.xml) uses the ismanager attribute to determine whether an account belongs to a manager, as shown in the following XML fragment:
<map>
<s>searchAttrsToGet</s>
<list>
<s>cn</s>
<s>dn</s>
<s>ismanager</s>
</list>
<s>searchScope</s>
<s>subTree</s>
<s>searchFilter</s>
<s>(&(objectclass=inetorgperson)(ismanager=Y))</s>
</map>
If you use a different attribute to convey this status, change the rule to match this customized attribute. If you do not use this type of attribute, remove all references to the ismanager attribute. In this case, also change final string in the map to the following:
<s>(objectclass=inetorgperson)</s>
In this scenario, a create user request requires approval from the user’s manager, who is not an Identity Manager administrator. The manager is determined by an approval query. The following fields have been pre-configured for this scenario:
- Determine additional approvers from — The Query option indicates the account IDs of approvers will be determined by querying the LDAP resource. The parameters of the query are constructed from the Resource Attribute to Query and Attribute to Compare fields.
- Resource Attribute to Query — The entrydn attribute is queried on the resource. The query is searching for the user’s manager.
- Attribute to Compare — The value of user.accounts[LDAP Resource].manager is compared to the value in the entrydn resource attribute. A match indicates the approver of the new user has been found.
- Approval times out after — The default value is 1 day. If the manager does not approve the request to create the user, an approval request will be sent to the manager’s manager. (The Escalation Administrator Query is identical to the Approval Administrator Query.) Note that an approval request can only be escalated once. If the second-line manager does not approve the request in the specified time, the request is not forwarded to the third-line manager.
- Approval Attributes — Attributes that will be displayed on the approval notice. The new user’s first name, last name, email address, and LDAP groups are displayed on the notice, but these values can be changed by the approver. See (cross-reference) for more information about the approval user form.
If the LDAP resource is configured so that an approver is required on the resource, that approval must occur before the manager receives the approval request.
Notifications
The LDAP scenario uses a standard workflow process, Notification Evaluator, to handle notifications. The Notification Evaluator process has been extended by adding an activity named Process User Manager.
The Process User Manager activity calls two rules:
Upon fetching the value of the manager’s account ID, Identity Manager will attempt to send a notification email to the manager. The email template must be configured correctly
Updating User AccountsIn general, the workflow processes that occur when changes are made to account mimic those that occur when accounts are created. The processes are simpler, however, because reprovisioning an existing user is less complicated than provisioning a new user.
Updates Discovered by Reconciliation
Data changes discovered by reconciliation go through the same general process as when creating a user. The User Form with Questions form controls the process.
See Using Reconciliation to Create Users on page C-11 for more information.
Updates Discovered by ActiveSync
The LDAP ActiveSync Update User workflow defines how ActiveSync updates are performed. When changes are discovered via ActiveSync, Identity Manager triggers the reProvision workflow service.
See Using ActiveSync to Create Users on page C-12 for more information.
Updates Performed with Identity Manager
In the LDAP scenario, user data can be edited by an administrator from the Administrative Interface, or by an end-user or manager from the User Interface. Regardless of how this data is changed, Identity Manager runs the same workflow and handles approvals and notifications in the same manner. See Using Identity Manager to Create Users on page C-15 about the workflow, approvals, and notifications.
The Update User Template TaskTemplate defines the workflow. It is an abbreviated version of the Create User Template TaskTemplate. In most cases, it is less urgent to change attributes of an existing user than to create the user in the first place. Therefore, the Update User Template TaskTemplate does not include these features.
Notifications work the same as when creating a user.
The updateUser process map must be updated to point to the Update User Template. This mapping has already been configured in the LDAP scenario, but to replicate this, click Configure, then the Form and Process Mappings subtab. Under the Process Mappings section, change the value for updateUser from Update User to Update User Template.
Implementing Changes to the User InterfaceThe User Interface presents a limited view of the Identity Manager system that is specifically tailored to users without administrative capabilities. By default, the User Interface allows users to change passwords and modify account attributes.
The LDAP scenario adds the following functionality to the standard user interface:
- Provides a default authentication question. The answer to the authentication question is read from the carLicense attribute of the inetOrgPerson object class.
- A user can change a variety of account attributes, including LDAP group memberships. Changing the any value requires approval from the user’s manager.
- A user can request access to a resource.
- If the user is a manager, change attributes of his or her subordinates.
These features are discussed in detail below.
Setting Answers to Authentication Questions
If a user forgets his password, or his password is reset, he can answer one or more account authentication questions to gain access to Identity Manager. These questions, along with the rules that govern them, are defined in the account policy.
The Default Lighthouse Account Policy in this scenario contains the default authentication question “Car license plate number?”. When an account is first reconciled, the User Form With Questions form loads the value of the carLicense attribute of the inetOrgPerson object class. The user form performs some additional processing so that the value of carLicense is used as an answer to the authentication question.
However, it should be noted that license plate number may not be the best attribute to use for authentication questions, as this information is often omitted from the corporate LDAP servers. Also, a license plate number is not a secure piece of information, so an unauthorized person could easily reset another person's LDAP password.
A better attribute would have ACIs in the directory that restrict read access to the owner and high-level administrators, such as IDM User and directory administrators. The availability of such an attribute will vary for each directory server.
If such an attribute is not available, you could expand the scenario so that the user must specify an employee ID as well as the license plate number. To do this, you must update the resource’s schema map, update the account policy, and update the User Form with Questions form. Again, this scenario is not secure if employee IDs are publicly available.
Resource
The schema map must define any attribute that is used in any user form, rule, or other Identity Manager object. In this scenario, the employeenumber LDAP attribute has already been mapped to the employeeNumber user attribute.
Account Policy
The account policy can modified from the Administrative Interface by clicking the Configure tab, then the Policies subtab. Select the account policy to be edited and enter a new question, such as “Enter Employee ID”, under the Secondary Authentication Policy Options heading.
To add the question directly to the Policy-DefaultLighthouseAccountPolicy
.xml file, modify the questions attribute list as follows.<Attribute name='questions'>
<List>
<Question>Car license plate number?</Question>
<Question>Enter Employee ID</Question>
</List>
</Attribute>
User Form
Replace the FieldLoop block in the “User Form with Questions” form with the following:
<FieldLoop for='questionName' in='waveset.questions[*].name'>
<Field name='waveset.questions[$(questionName)].answer'>
<Expansion>
<cond>
<eq>
<ref>waveset.questions[$(questionName)].question</ref>
<s>Car license plate number?</s>
</eq>
<ref>global.carLicense</ref>
<cond>
<eq>
<ref>waveset.questions[$(questionName)].question</ref>
<s>Employee number?</s>
</eq>
<ref>global.employeeNumber</ref>
</cond>
</cond>
</Expansion>
<Disable>
<and>
<neq>
<ref>waveset.questions[$(questionName)].question</ref>
<s>Car license plate number?</s>
</neq>
<neq>
<ref>waveset.questions[$(questionName)].question</ref>
<s>Enter Employee ID</s>
</neq>
</and>
</Disable>
</Field>
</FieldLoop>
This code block determines whether each question defined in the authentication policy matches text specified in a <s> element. If the questions do not match, the fields are disabled.
Changing Account Attributes
The LDAP End User Form determines which account attributes are displayed and whether the attributes can be edited. When any attribute is edited, the user’s manager is notified of the change. The manager must then approve or reject the change. For more information about the implementation of this feature, see Using Identity Manager to Create Users on page C-15
The LDAP End User Form allows users to request changes to the LDAP groups they are a member of. To manage LDAP groups, the ldapGroups attribute must be added to the adapter’s schema map. In this scenario, the manager and employeeNumber attributes from the inetOrgPerson object class have also been added to the schema map to track who is the manager of the user.
The User Form calls the Get LDAP Groups rule. This rule gets the list of LDAP groups available on the directory server.
The LDAP End User Form also contains fields named Manager and Manager Name. The Manager field contains the value returned from the manager LDAP attribute. The Manager Name field, however, is derived by the Get Manager Name rule. This rule looks up the LDAP user listed in the Manager field and retrieves this user’s first name (givenName) and last name (sn), then concatenates these values.
If the user is a manager, the Subordinates table is populated with the user IDs, names, and email addresses of subordinate users. See Manager Editing Subordinate Data on page C-23.
Manager Editing Subordinate Data
In the LDAP scenario, managers do not have the ability to log in to the Administrative Interface. However, managers are able to edit attributes of their subordinates because the scenario creates a virtual organization, an admin role to control the organization, and provides several rules that determines whether a manager/subordinate relationship exists.
Virtual Organization
The My Employees organization contains users whose manager LDAP attribute matches the distinguished name of the logged in user. If a user is not a manager, then the organization is empty, and the user cannot act on other accounts. Note that a manager can act on direct reports only. A second-line manager can edit the data of a first-line manager, but not the first-line manager’s subordinates.
The organization is assigned the Get My Subordinates rule. This rule has an authType of UserMembersRule and determines whether users can be a member of this organization. The rule in turn calls the Get LDAP Resource Name and Get Subordinate Account IDs rules. The Get Subordinate Account IDs rule uses the resource returned in the Get LDAP Resource Name rule to determine where to search for LDAP users whose manager is the current user. The Get Subordinate Account IDs rule searches the cn, givenname, and dn attribute values on the directory and returns the value in dn.
Admin Role
The AdminRole-User.xml file creates the Users admin role. This admin role is unique in that it is automatically given to all Identity Manager users. In addition, this role has the following characteristics:
User Form
End User Subordinate Form — This form is similar to the LDAP End User Form, except that it does not have a subordinates section. It is accessed after a manager clicks on the name of a subordinate.
JSP Files
The changesSubUser.jsp file controls the display of the End User Subordinate form. It is referenced in the LDAP End User Form.
Requesting Access to Resources
The LDAP scenario gives end users the ability to request a resource account. When the user selects a resource, Identity Manager displays a set of attributes that the user can fill in to expedite the process. To enable this feature, the scenario contains customized forms, rules, and JSP pages.
Custom End User Menu User Form
When the scenario is first loaded, the configuration script changes the endUserMenu form mapping from End User Menu to Custom End User Menu. The UserForm-CustomEndUserMenu.xml file defines the Custom End User Menu form, which controls what is displayed when an end-user logs in to the User Interface.
The Custom End User form differs from the default End User menu in that it adds the link to the page that allows users to request access to resources. The following field adds the Request Resource Access link.
<Field>
<Display class='Link'>
<Property name='name' value='Request Resource Access'/>
<Property name='URL' value='user/requestResources.jsp'/>
</Display>
</Field>
Resource Request User Form
In the default Administrative Interface, the Tabbed User Form is displayed when creating or editing users. On the Assignments navigation tab, the Individual Resource Assignments multi-select box allows the administrator to assign one or more resources to the user. This multiselect box is the primary construct of the Resource Request User Form.
However, an end-user does not have the capability to view a list of available resources. To get around this limitation, the form calls the Get Unassigned Resources rule. This rule has two elements of note:
- The RunAsUser element specifies the user account that will be used to query for available resources. The example uses Configurator perform this task. In a production environment, you would create an administrator account with minimal capabilities to query for resources.
- The rule invokes the FormUtil method getUnassignedResources. This method builds a list of all accessible resources minus the names of the resources that are already assigned to the user through their role.
JSP Files
To enable the feature for allowing users to request access to resources, the following JSP files must be copied from $WSHOME/sample/scenarios/scenario1/jsp/ into $WSHOME/user/.
Implementing Changes to the Administrator InterfaceModifying the Approval Page
When a manager logs in to the User Interface, a link labeled View Inbox is displayed if the manager has a pending approval request. The UserForm-ApprovalForm.xml enhances the default Approval Form by displaying attributes that have been changed.
Modifying the Find User Form
The scenario adds a new search option to the Find Users page. This option allows the administrator to locate users whose manager starts with, contains, or matches the specified text.
Enabling this feature requires modifications to the UserUIConfig configuration object and two user forms.
UserUIConfig Configuration Object
The UserUIConfig configuration object controls the account search function and how results are displayed. To search for users by manager, the manager attribute must be added to the QueryableAttrNames and SummaryAttrnames elements. QueryableAttrNames define attributes that can be searched, while SummaryAttrNames are the attributes that can be displayed in list results.The scenario adds these attributes automatically.
User Search Library User Form
The User Search Library User Form defines the manager field. This multi-part field contains the following facets:
The following fragment defines the manager field.
<Field name='manager'>
<Field name='query.clauses[clause1].conditions[manager].active'>
<Display class='Checkbox'/>
</Field>
<Field>
<Display class='Label'>
<Property name='value' value='Manager'/>
<Property name='rowHold' value='true'/>
</Display>
</Field>
<Field name='query.clauses[clause1].conditions[manager].attribute'>
<Expansion>
<s>manager</s>
</Expansion>
</Field>
<Field name='query.clauses[clause1].conditions[manager].operator'>
<Display class='Select'>
<Property name='valueMap'>
<ref>displayHints.searchOperators</ref>
</Property>
<Property name='rowHold' value='true'/>
</Display>
</Field>
<Field name='query.clauses[clause1].conditions[manager].value'>
<Display class='Text'>
<Property name='rowHold' value='true'/>
<Property name='size' value='20'/>
<Property name='maxLength' value='48'/>
</Display>
</Field>
</Field>
Find User Form User Form
The UserForm-FindUserForm.xml file modifies the default Find User Form to add a field reference to the manager field, which is defined in the User Search Library form.