The Provisioning view is only available for Designer projects that contain a User Application driver. After you set up an Identity Manager project and configure an Identity Vault and driver set for the project, you add and configure a User Application driver.
To use Designer to configure the Roles tab of the User Application, you must additionally add a Role Service driver to your project.
To add the User Application driver to a project, the driver must be installed and deployed in your environment. For more information, see NetIQ Identity Manager Setup Guide for Linux or NetIQ Identity Manager Setup Guide for Windows.
In an open Designer project, create a new driver by using one of these methods:
Click Provisioning in the Palette, then drag the User Application icon onto the modeler.
Right-click the driver set for your project, then select New > Driver.
Click the driver set for your project, then select Model > Driver > New.
Select User Application Base from the list of driver base packages in the Driver Configuration Wizard, then click Next.
Specify the properties you want to use for the driver:
Specifies the either the User Application driver created when you installed Identity Manager or a new User Application driver.
Specifies the DN of the User Application Administrator.
Specifies the password for the User Application Administrator.
Specifies the name or IP address of the application server where you deployed the User Application.
Identity Manager uses this information to perform the following actions:
Trigger workflows on the application server to connect to access workflows, such terminate and retract
Update cached data definitions
Specifies the port for the host server.
Specifies context of the User Application. For example, IDMProv.
Applies to workflows that start automatically
Specifies whether you want to use an identity other than the User Application Administrator to start workflows. To use an alternate identity, select Yes.
For more information, see the Identity Manager User Application: Administration Guide.
Click Next, then Finish.
(Optional) Deploy the email templates to support email notifications in your workflows.
When you add a User Application driver, Identity Manager adds email templates to the Default Notification Collection. You must explicitly deploy the templates. They are not deployed by default when you deploy the driver. For more information about deploying the templates, see Setting Up E-Mail Notification Templates in the NetIQ Analyzer for Identity Manager Administration Guide.
In the same project where you created a User Application driver, click Provisioning in the Palette, then drag and drop the Role Service icon onto the Modeler.
Select Role and Resource Service Base from the list of driver base packages in the Driver Configuration Wizard, then click Next.
Specify the name you want to use for the driver and click Next.
Specify the properties you want to use for connecting the driver to the User Application. If you have already configured the User Application driver, the Driver Configuration Wizard should prepopulate the fields with the correct information, but we recommend you double-check the specified properties. Use the following information to configure the driver:
Field |
Description |
---|---|
User-Group base container DN |
Specify the DN of the root container that the Role Service driver services. |
User Application Driver DN |
Specify the DN of the User Application Driver object that hosts the role system. For example, system\driverset1\UserApplication. |
User Application URL |
Specify the URL used to connect to the User Application. The default URL is http://127.0.0.1:8180/IDMProv. |
User Application Identity |
Specify the DN of the User Application Administrator. For example, cn=admin,ou=sa,o=data. |
User Application Password |
Specify the Application Password you specified for the User Application driver. |
Click Next.
Click Finish.
After creating the Role Service driver, you can optionally modify some of the driver configuration settings and modify the additional settings described in Table 2-1. To customize the additional settings:
In the Modeler, right-click the Role Service driver and select Driver > Properties.
Select Driver Configuration (in the left pane).
Click the Driver Parameters tab.
Click the Driver Options tab. You can modify the driver’s properties that you specified when you created the driver as well as the properties described in Table 2-1.
Click OK to save the changes.
Table 2-1 Additional Settings for Customizing the Role Service Driver
Field |
Description |
---|---|
Number of days before processing removed request objects |
The number of days the driver should wait before cleaning up request objects that have finished processing. This value determines how long you are able to track the status of requests that have been fulfilled. |
Frequency of reevaluation of dynamic and nested groups (in minutes) |
The number of minutes the driver should wait before reevaluating dynamic and nested groups. This value determines the timeliness of updates to dynamic and nested groups used by the User Application. In addition, this value can have an impact on performance. Therefore, before specifying a value for this option, you need to weigh the performance cost against the benefit of having up-to-date information in the User Application. |
Generate audit events |
Determines whether audit events are generated by the driver. |
Identity Manager includes a standard set of email notification templates.
When you create a User Application driver, any email notification templates that are missing from the standard set are replaced. However, existing email notification templates, which might come from an earlier version of Identity Manager, are not updated. To replace existing templates with new templates:
Expand the Outline view.
In the Default Notification Collection, delete the email notification templates that you want to replace.
Right-click Default Notification Collection and select Add Default Templates or Add All Templates.
You can also use this command at any time to update email notification templates without creating a new User Application driver.
To deploy the email notification templates to the Identity Vault, right-click Default Notification Collection and select Live > Deploy.
You can allow request reviewers to approve or deny a request using e-mail. The e-mail notification can include links that can be used for approving or rejecting requests to help you easily respond to the request without logging in to the identity applications.
IMPORTANT:If request reviewer forwards the mail to another user, action links for approval or rejection action do not work.
An request reviewer can respond to the notification email in the following two ways:
When the request reviewer clicks Approve or Deny link in the e-mail, the identity applications composes a new email with the required subject and content. The request reviewer can enter comments in the e-mail send it after adding the comments.
Before replying to a notification, a request reviewer can modify the subject line of the e-mail. However, ensure that the keyword (Approve or Deny) along with the alpha-numeric unique code is not changed.
IMPORTANT:To reply to the notification e-mail, set the ‘from’ address of the request reviewer mail server as same as the incoming mail server.
Before setting up the Email Based Approval, review the following checklist:
Checklist Items |
|
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
In Designer, open the project where you want to install Email Based Approval package and perform the following steps:
Right-click on the Identity Manager engine and select Properties > Packages.
Click icon to add new package and select Email Based Approval Templates package.
Install the package and click OK.
Expand Default Notification Collection and select all the Email Based Approval templates.
Deploy the selected templates on to your Identity Vault.
In Designer, select the required Email Based Approval templates to deploy the workflow:
Create a PRD workflow, select the Notify participants by E-mail check box.
Right-click on the Approver icon, and select Show E-mail Notification.
Select one of the following e-mail options as:
Notify,
Reminder
Escalation Reminder
From E-mail Template drop-down list, select Email Based Approval Provisioning Notification template.
Repeat Step 1 through Step 4 for the workflows that requires approval.
NOTE:Email Based Approval allows request reviewers to process the requests which is not associated with complex forms.
Add the source ECMA script for the required field based on the selected template.
After creating a PRD, deploy the workflow.
To allow users to approve or reject requests from an email:
Log in to the Identity Manager Dashboard.
Select Administration > Email-based approval.
For more information, see the Help in the Dashboard.
To enable Digital Signature service, perform the following:
In Identity Manager Dashboard, navigate to the Email based Approval page.
In Email Content Options panel, select the Include action links with digital signature option.
In Configuration Update Utility, ensure that you have specified the Identity Vault certificates details and updated the Email Server Configuration fields to enable digital signature service on the outgoing e-mails. For more information about the User Application Parameters, see Email Server Configuration in the NetIQ Identity Manager Setup Guide for Linux or Email Server Configuration in the NetIQ Identity Manager Setup Guide for Windows.
To setup a digital signature support, perform the following steps:
In Configuration Update Utility, specify the private keystore and private key certificate properties.
NOTE:If private key certificate alias contains any special character, then rename the certificate alias.
Import the private key certificate by running the following command:
<JRE_BIN_PATH>/keytool -v -importkeystore -srckeystore <privatekey_certificate_path>-srcstoretype PKCS12 -destkeystore <keystore_path> deststoretype JKS
(Conditional) Rename the imported certificate by running the following command:
<JRE_BIN_PATH>/keytool -changealias -keystore <privatekey_store_path> -alias "<old_alias_name>" -destalias <new_alias_name>
Ensure that the outgoing mail server is configured on each nodes of the cluster, you can configure this mail server using Configuration update Utility. For more information, see Email Server Configuration in the NetIQ Identity Manager Setup Guide for Linux or Email Server Configuration in the NetIQ Identity Manager Setup Guide for Windows.
On cluster environment, you must specify the IP address of the ActiveMQ server in server.xml file of the other nodes in the cluster, which is set to localhost by default. Look for the brokerURL attribute for the AcitveMQ server in the server.xml and replace the localhost with the ActiveMQ server IP address.
If you enable or disable the Email Based Approval (Off/On) or change the incoming mailbox properties, then restart all the cluster nodes for the change to take effect. You must also verify the connection between the mailbox host and other servers.
This section helps you to troubleshoot the general issues while configuring Email Based Approval.
In provisioning request e-mail, if recipient’s mail address, or Approval or Deny Tokens are missing, enable the Email Based Approval option.
If a request reviewer cannot find the Approve or Deny link in the e-mail, review the Email Based Approval settings.
If a request reviewer cannot compose an e-mail after clicking the Approve or Deny link, verify whether the default e-mail client is configured. (For example: Microsoft Outlook)
You can verify the Email Based Approval settings using the catlina.out events logs.
For example, if you want to verify the status of Email Based Approval, look for the following entries in the catlina.out property file:
INFO com.novell.soa.notification.impl.EmailReceiverEngine- [RBPM] Email based approval feature is turned on. Starting the incoming mailbox service soon.. INFO com.novell.soa.notification.impl.jms.JMSConnectionMediator- [RBPM] Starting JMS notification system INFO com.novell.soa.notification.impl.EmailReceiverEngine- [RBPM] Successfully started persistent JMS notification system for email based approval INFO com.novell.soa.notification.impl.EmailReceiverThread- [RBPM] Starting asynchronous notification system INFO com.novell.soa.notification.impl.EmailReceiverEngine- [RBPM] Mailbox service for incoming mail started successfully without any warning INFO com.novell.soa.notification.impl.EmailReceiverEngine- [RBPM] Email based approval token cleanup service started successfully.
NOTE:This section is applicable only for Identity Applications 4.7.1.
Controlled Permission Reconciliation Services (CPRS) currently supports Active Directory, Multi-Domain Active Directory (MDAD), LDAP, Loopback, Delimited, and REST drivers.
Perform the following tasks to make custom entitlement available for Identity Applications using Designer:
Install custom entitlement package which by default installs cprs common package.
Create an entitlement (DirXML-Entitlement) object for the driver. For example: Cubicle
For more information, see Creating Entitlements through the Entitlement Wizard in theNetIQ Designer for Identity Manager Administration Guide.
To make the new entitlement available for Identity Applications Resources perform the following tasks:
NOTE:To access Identity Applications Resource Catalog, navigate to Administration > Resources in Identity Manager Dashboard. For more information, see Listing Resources in NetIQ Identity Manager - Administrator’s Guide to the Identity Applications.
Right-click on the specific driver and click Properties. Navigate to GCVs > Custom Entitlements tab.
In List of Custom Entitlements, add the entitlement object names that needs to be listed in the Identity Applications user interface.
NOTE:
These entries are case sensitive.
CPRS supports only the Identity Manager 4.0 and later entitlement format.For more information, see Entitlements Formats in NetIQ Identity Manager Entitlements Guide.
By default, the cprs-supported, role-mapping, and resource-mapping flags are set to True and the data-collection flag is set to False.
(Conditional) If you wish to configure the flags, create a boolean GCV in the following format:
drv.cprssupported.<entitlement-name>, drv.datacollection.<entitlement-name>, drv.rolemapping.<entitlement-name>, drv.resourcemapping.<entitlement-name> respectively.
To include an additional XML to an entitlement:
Specify the Name as drv.entitlement.extensions.<entitlement-name>.
Select the Type as String.
Select the Multi-line option.
You should add the additional entitlement extensions between <entitlement-extensions></entitlement-extensions> XML node. For more information, see Modifying Entitlement Extension.
(Conditional) For localization of entitlement, add the localization values for the entitlement in the L10N_<locale> mapping tables.
Deploy and start the driver for the changes to take effect.
If Identity Manager is of Style4 entitlement, then you need to define the parameter tag.
Ensure that the entitlement extension XML contains the following information:
Parameter node for building codemap values.
The <parameters> node defines the list of parameters.For more information, see DTD.
(Conditional) If the entitlement is dealing with accounts, then the <account> node provides information about the account status (such as status, attribute name, active and inactive values). For more information, see DTD.
(Conditional) If you want to run a different query to fetch permission from the connected application, then provide the specific query in the <member-assignment-query> node. This node is applicable only for <entitlement> type account. For more information, see DTD.
(Conditional) In case of multi-valued entitlement, if the permission information needs to be retrieved from a specific attribute of the connected application, then provide the specific information in the <member-assignment-extension> node. Member assignment information are available on both account and group entitlements, however they are retrieved differently. For more information, see DTD.
The following is a sample of entitlement extension XML for two different entitlements:
Example 1:
To manage custom entitlement in the connected application such as Cubicle, where the permission value is stored in the AssignedTo attribute.
<entitlement-extensions> <parameters> <parameter mandatory="true" name="ID" source="association" /> <parameter mandatory="true" name="ID2" source="association" /> </parameters> <native-value source="src-dn" /> <member-assignment-extensions> <query-xml> <read-attr attr-name="AssignedTo" /> </query-xml> </member-assignment-extensions> </entitlement-extensions>
Example 2:
This example shows how account node and member-assignment-query node needs to be defined.
<entitlement-extensions> <account> <account-id source="src-dn" /> <account-status active="FALSE" inactive="TRUE" source="read-attr" source-name="Account_STATUS" /> </account> <parameters> <parameter mandatory="true" name="ID" source="read-attr" source-name="RESTACCOUNT" /> </parameters> <member-assignment-query> <query-xml> <nds dtdversion="2.0"> <input> <query class-name="User" scope="subtree"> <search-class class-name="USer" /> </query> </input> </nds> </query-xml> </member-assignment-query> </entitlement-extensions>