Plugin Java Classes

The plugin framework relies heavily on REST web services integration for the majority of CRUD (create, read, update, and delete) operations. To create a custom REST Resource:

• Extend the BasePluginResource class

• Secure the new endpoints

The BasePluginResource class should be used as the base class for all resources. It provides access to utility methods for accessing plugin settings, getting database connections, and more.

• getConnection – gets connection to the datasource specified in the iiq.properties file for the plugins

• getPluginName – this method should be overwritten to return the correct name of the plugin

• getSettingBool – gets value of Boolean plugin setting for plugin name returned by getPluginName()

• getSettingInt – gets value of int plugin setting for plugin name returned by getPluginName()

• getSettingString – gets value of String plugin setting for plugin name returned by getPluginName()

• prepareStatement – convenient security method for getting Java PreparedStatement object for any database queries that are required

• Signature is prepareStatement(Connection, String, Object...) where the String would be the SQL statement you want to execute

• Object... a list of the parameters values, if any, to be used

• authorize – should be overwritten by implementers, but by default only ensures that SystemAdministrator can see everything

Introduce additional methods to handle the various endpoints required by the plugin.

The plugin framework enables you to include custom task implementations or services with your plugin. These items rely on executor classes that contain the business logic for these services. The following executors are currently available:

• Service Executors

• Task Executors

• Policy Executors

You must specifically declare the classes to be exported for each of the executors. Only classes specifically declared are accessible from the rest of IdentityIQ. If a class is not declared, it will fail to instantiate when you open the plugin. Classes are declared in the manifest.xml file.

Use the following attributes to declare classes:

• serviceExecutor

• taskExecutor

• policyExecutor

For example:

<entry key="taskExecutors"> 
  <value> 
    <List> 
      <String>com.acme.TaskExecutor1</String> 
      <String>com.acme.TaskExecutor2</String> 
    </List> 
  </value> 
</entry>

Plugin Object Properties

When defining your plugin object you must provide the list of service executors that are included. The list lives inside an attributes map under the key serviceExecutors.

• Plugin Helper methods

• All inherited Service methods

• BasePluginTaskExecutor

• Plugin Helper methods

• All inherited TaskExecutor methods

• BasePluginPolicyExecutor

• Plugin Helper methods

• All inherited PolicyExecutor methods.

Plugin Helper Methods

The list of methods that are included with the BasePlugin classes are as follows:

• getPluginName() – returns a string value of the name of the plugin

• getConnection() – returns a Connection object used to query the database

• getSettingString(String settingName) – returns a String setting value from the Plugin Settings

• getSettingBool( String settingName) – returns a Boolean value from the Plugin Settings

• getSettingInt(String settingName) – returns a integer value from the Plugin Settings

You can think of the BasePlugin classes as foundation for creating your specific objects. By using them you gain access to the Plugin Helper Methods, but you are not required to use the BasePlugin classes. You can extend directly from the parent class object.

Implementing a Plugin Service Definition

To implement a Plugin Service there are two parts. The service class, containing the business logic that you want the service to actually do, and the service definition xml, that is loaded into IdentityIQ.

• BasePluginService Class – an abstract class that extends the Service class, as well as implements the PluginContext interface. You can use this class as the foundation for your custom Plugin Service

• Service Definition – specify a pluginName attribute. This tells IdentityIQ to use the plugin class loader for this executor. If this attribute is not specified the executor class will not be found

Implementing a Plugin Task Executor

To implement a Plugin Task Executor there are have two parts. The Task Executor class, which handles the business logic for your task, and the TaskDefinition xml object, which gets loaded into IdentityIQ.

• BasePluginTaskExecutor Class – an abstract class that extends the AbstractTaskExecutor class, as well as implements the PluginContext interface. You can use this class as the foundation for your custom Plugin Executor task

• TaskDefinition – include the pluginName attribute, as this attribute tells IdentityIQ to use the plugin class loader instead of default class loader. If the attribute is not specified the executor class will not be found

Implementing a Policy Executor

To implement a Policy Executor there are have two parts. The Policy Executor class, which handles the business logic for your policy, and the Policy xml object, which gets loaded into IdentityIQ.

• BasePluginPolicyExecutor Class – an abstract class that extends the AbstractPolicyExecutor class, as well as implements the PluginContext interface. You can use this class as the foundation for your custom Plugin Policy Executor

• Policy XML – include the pluginName attribute, as this attribute tells IdentityIQ to use the plugin class loader instead of default class loader. If the attribute is not specified the executor class will not be found.

Note: BeanShell executions are referred to as scripting in this document.

The classes installed for plugins can be made available to all BeanShell executions. BeanShell (rules, scriptlets, workflows) scripting invocations are able to use all Java classes, from all plugins, that are declared as exported for scripting. The scripts should fail to load classes which are in plugins, but which are not explicitly exported.

BeanShell executions include:

• Rules

• Workflow steps (rules and scripts)

• Scriptlets

Use the scriptPackages attribute to declare the Java packages exported for use by scripts as follows:

<entry key="scriptPackages"> 
  <value> 
    <List> 
      <String>com.acme.classy.util</String> 
    </List> 
  </value> 
</entry>

Example: Using Plugin Classes From a Rule

This is a simple example of how to call the plugin classes from a rule.

The example Java class named com.acme.classy.util.ClassyUtil can be used from a rule if declared properly in the manifest.xml using the scriptPackages entry shown above.

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE Rule PUBLIC "sailpoint.dtd" "sailpoint.dtd">
<Rule language="beanshell" name="ClassyRule" >
  <Description>Returns the current timestamp by calling class from
                       ClassyPlugin</Description>
  <Signature returnType="string"/>
  <Source>
import com.acme.classy.util.ClassyUtil;
long now = ClassyUtil.now();
return "The current timestamp is: " + now;
 </Source>
</Rule>