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.
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.
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.
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.
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.
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.
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.