6. Import/Deploy: What's New

(Home)     Previous     Next

1. Importing Notification Templates and Identity Vault Schema

The Identity Vault schema and default notification collection were previously imported by default when you imported a project from the Identity Vault, and when you performed a live import of the Identity Vault from the Modeler view. This release of Designer allows you to choose whether to import the Identity Vault schema and e-mail templates during import. By default, the Identity Vault schema and all e-mail templates of the default notification collection are selected for import, as shown in the following image.



Select the Identity Vault Schema and then click Remove to prevent importing the Identity Vault schema during the import process. Note that once the option to import the Identity Vault schema is removed from the list, it cannot be restored; you can only restore the options by restarting the import action.

Likewise, to prevent importing the notification templates, select the collection object and click Remove. The import interface also allows you to select which templates you want to import. In the following example, the Identity Vault schema is not imported and only the template named "MyTemplate" is imported. Unselecting all templates while leaving the template collection in the import list imports the attributes of the collection without importing the templates.



2. Importing Libraries during Project Imports

This release of Designer allows you to import policy libraries when you import a project from an Identity Vault. To import a library, select Browse to locate the library you want to import. The following image shows a single library named "GlobalLibrary" that is selected for import.

3. Optional Library Imports during Driver Set Import

This release of Designer allows you to choose which policy libraries to import when you import a driver set from an Identity Vault. To import a library, select the check box next to the library name. The following image shows a single library named "library" that is selected for import. Notice, the libraries named "testlib" and "testlib2" are not selected for import.

4. IDM Version and Engine Controls

When you deploy or reconcile a driver, the Identity Manager version of the Identity Vault server is updated to match the live system. For example, if the IDM version of a server named "prod" is set to 3.0.1 in Designer, but the actual version in the live system is 3.5.1, Designer updates the version of "prod" to 3.5.1 during a driver deployment or reconciliation. Updating the Identity Manager version allows Designer to correctly set the engine controls for the driver so that invalid engine controls are not deployed to the Identity Vault.

5. Driver Configuration Enhancements

This release of Designer includes enhancements to the Driver Configuration Wizard in order to support new features. These features include read-only object browse fields, validating object DN, and browse filters. For more information on the driver configuration features, see the Identity Manager and the Identity Manager driver documentation.

The read-only browse feature disables typing within a DN field in the configuration setup, forcing a user to browse for an object.



The validate feature forces values entered in a DN field to be a qualified dot or a dot form name, such as "cn=user.o=org". The configuration wizard displays an error dialog if the name is not a valid DN and focuses on the field that needs to be corrected.



The Browse filter option of a configuration file allows you to specify which types of objects you can browse. For example, a driver configuration writer may want to force the DN of a particular field to be an e-mail template, while forcing another to be a Notification Collection object. The Identity Vault browser enforces these restrictions, allowing the user to only select the specified object types.

6. Deploying Objects Without a Deployment Context

A pre-deployment check was added to this version of Designer to detect objects that do not have a deployment context specified on their parent library, driver set or Identity Vault. Objects that do not have a deployment context cannot be deployed to the Identity Vault. For example, a driver cannot be deployed if a deployment context is not specified on the parent driver set or Identity Vault. Previous versions of Designer would attempt to deploy and display errors in the result dialog. This version of Designer detects this error before the deployment and informs the user that the deployment cannot continue.



If multiple objects are being deployed, it is possible that some objects may have a deployment context while others may not. In this case, the user is given the option to continue or cancel the deployment. Objects that do not have a deployment context cannot be deployed and an error is reported in the result dialog.



7. Tracking Deployed Objects to Multiple Identity Vaults

Previous versions of Designer included a feature to track objects that were deployed to an Identity Vault. This allowed Designer to delete or rename the objects in the Identity Vault that were renamed or deleted in Designer. However, the previous deployment tracking mechanism was limited to a single Identity Vault. If a user changed the IP address of the Identity Vault and re-deployed, only the last deployment was managed.

This release of Designer includes an enhancement to the deployment tracking feature that allows tracking deployed objects to multiple Identity Vaults. This is useful for a user who may have multiple Identity Vaults where they are deploying the project, such as a testing or production environment.

The following is a simple example of how this feature behaves:

A user develops and deploys a project to a "Test" Identity Vault that contains two policies: "policy_a" and "policy_b." Once the user has verified that the changes are working as desired, the user changes the IP address of the Identity Vault object in Designer and deploys the project to a "Production" Identity Vault. At this point, Designer is tracking the deployed objects to both Identity Vaults.

Sometime later the user returns to the Designer project, renames "policy_a" to "policy_c" and deletes "policy_b" because it is no longer needed. The user switches the IP address back to the "Test" Identity Vault and and re-deploys. This causes the "policy_a" object in the "Test" Identity Vault to be renamed to "policy_c" and the "policy_b" object is deleted. Again, once the user has verified that the changes are working as desired, the user changes the IP address of the Identity Vault object to the "Production" environment and deploys the project. During deployment to the "Production" Identity Vault, "policy_a" is renamed to "policy_c" and "policy_b" is deleted, just as it was in the "Test" environment.

(Home)     Previous     Next