This release of Designer contains enhancements to the policy simulator that
while not ready for final release are available as pre-release features. The new
features help users create simulator input and query response documents. These
features are functional but need some additional work to clean up the user
interface and handle error conditions. The pre-release functionality is enabled
by a simulation preference.
An additional page added to the policy simulator allows a user to select
how to create the simulator input as well as the type of operation to simulate.
It also allows the user to build the simulator XDS Input document from a variety
of template objects.
The simulator supports three methods for creating the simulator input. The user can
import a document from a file on the file system, create a input document from a
template object or paste the contents of the clipboard.
The option "Paste document from clipboard" will automatically move to the simulator input page and paste the
contents of the clipboard into the input editor. The option "Import the input document from a file" was
available in previous releases. It will display a text field and button which will allow the user to browse
for a file on the file system.
The option "Create input document" will display controls which allow the user to build the input document from
a variety of template or input source objects.
The operation combo box allows the user to select the type of operation they wish to simulate. The controls displayed on
the dialog will change depending on the operation selected. Entering data into the
displayed controls and selecting next will create the simulator input. Different operations
require different controls. For example the attribute table is only visible for
add, modify and query operations.
The Input Data combo box allows the user to select the input source or template object
to use when building the input document, by default the simulator uses the Driver Filter.
All classes included in the Driver Filter will appear in the class combo box. The
attributes in the table are also built from the Driver Filter for the selected class.
Other off-line options include using a class from the Identity Vault or application schema
of the Driver. In this mode the attributes table will include all attributes
defined for the selected class. To include an attribute in the input document
simply check the box next to the attribute name.
Selecting the next button will create an XDS Input document using the values provided
on the page. Currently using these off-line methods a default attribute value is used
and can be customized on the input page. Future releases of the simulator should allow
the user to specify the attribute values in the attribute table. The following example
shows the input document created using the Identity Vault schema class Group.
The remaining two Input Data options can only be used when the Identity Vault or
connected application are available. The "Identity Vault Object" option allows the user
browse and select an any object in the Identity Vault. The simulator will read
the object and fill in the appropriate controls based on the operation type. For add
and modify operations the simulator will display all of the objects attributes
in the attribute table. The user can then select the attributes they wish to include
in the input document and the actual eDirectory values will be included in the input
document.
The following image shows an example of an add operation created from a Identity Vault
object named "cn=User1.o=users". It contained an association value of 222111, a GUID
attribute of "lRcvRtnLvUSPrRrEgXRXiQ==" and an email address of "user@company.com".
The user can still customize the document on the simulator input page to change
values, add additional attributes or operation data.
The final Input Source option, "Application Object" uses a new Designer service called
Independent Driver Services (IDS) to communicate directly with the connected application. This
service allows IDM Driver shims to be loaded without the IDM engine.
Note, while functional this feature has not been completely tested and
will require numerous enhancements and bug fixes. It is made available
only for early access. Feel free to provide feed back but keep
in mind that this feature is still under construction.
In order for the simulator to use IDS and connect to the application the driver and
application must be configured correctly. The Driver jar files must also be copied
to the directory specified in the Simulation Java Extension preferences.
For this release the easiest way to get the Driver Shim configured correctly is to
deploy the driver to eDirectory and verify that it will start. In order for the IDS
service to connect to native drivers such as DLL's and shared objects the driver must
be configured using the Remote Loader. The error reporting and debugging capabilities
of the simulator need to be and will be improved in later releases. The following
example shows the simulator browsing to an LDAP directory through the LDAP driver
to select a user object.
Enhancements to the simulator also allow the user to build up query responses
by submitting the query directly to the Identity Vault or application through
IDS. The user can still switch to the response tab and import a reply document
from a file or enter the reply manually. The following query was generated by
a policy simulation.
In this case the query was generated by the Destination Query process and is
directed to the application. Selecting the "Submit to Application" button will send
the query using IDS through the LDAP driver to the LDAP server. The response
of the query will be generated by the Driver Shim. If the query is directed
to the Identity Vault the button label will read "Submit to Identity Vault".
The following shows the response generated for the above query.
If an error occurs while submitting the query or if the query returned an empty
reply a dialog will be displayed which will allow the user to browse for an object
to use as a template for the response.
Note, while functional this feature has not been completely tested and
will require numerous enhancements and bug fixes. It is made available
only for early access. Feel free to provide feed back but keep
in mind that this feature is still under construction.
Depending on where a policy is being simulated the input document may need to be
in the eDirectory or applications namespace. For example when simulating policies
in the Input and Output policy sets the input document should be in the applications
namespace. This means that the input document should contain the application class
and attribute names. An enhancement to the simulator will translate the input document
based on the policy set being simulated by automatically running the input document
through the mapping policies. For example the following images show the translation
of an input document when a user is simulating the policies in the Input policy set
and the Publisher Command policy set.
Notice since we are simulating the Input policy set the class and attribute
names are in applications namespace. If the user selects the Publisher Command
policy set from the combo box the simulator translates the class and attribute names
into the eDirectory namespace. In this case the "EMail" attribute is translated
to "Internet EMail Address" and "LastName" is changed to "Surname". Note however
that the translation only handles the class and attribute names. If the
values need to be in a different format the user must change the format manually.
 |
Other Enhancements & Bug Fixes |
|