About Server Plug-Ins

A server plug-in is a third-party component added to ActivID CMS to support functionality on the server side. ActivID CMS calls enrollment plug-ins each time a user attribute is set or retrieved (this corresponds to when calls are made to the setAttributes and getAttributes functions of the Generic Plug-In SPI A Service Provider Interface (SPI) consists of a set of constant definitions and method declarations without implementations and intended to be called or used in a pre-determined generic manner with a set of outputs that meet pre-determined abstract rules and expectations.).

The setAttributes and getAttributes functions use linkParameters, a list of attributes needed by the plug-in to match the identifier of the user inside ActivID CMS with the identifier of the user in the external repository.

The attributes are managed by the ActivID CMS portal in the same way as standard LDAP user attributes (attributes that can be displayed in a lookup, updated during issuance, or printed during issuance). For enrollment plug-in attributes, the naming convention is: plug_in_name:attribute_name (for example, GenericPluginSample1:MyUserID).

Defining a Generic Plug-In

Generic plug-ins are implemented using Java. To develop a generic server plug-in, you must implement all the methods of the generic server plug-in interface as described.

1. Write the Java code to implement the server plug-in. See Coding a Generic Server Plug-In. Then incorporate the server plug-in code into the appropriate .jar file.

2. Describe the plug-in attributes in the appropriate .properties file.

Guidelines to Set Up All Plug-Ins Types

Use the following list of guidelines to set up all plug-ins:

• Set the plug_in_name.class to the name of the Java class for plug-in implementation.

• Set the plug_in_name.conf_file to the name of a specific configuration file given to the plug-in by ActivID CMS in the init function.

• Set the plug_in_name.link to the list of attribute names whose values are needed by the plug-in to match a user entry on its repository. This parameter is used in the setAttributes and getAttributes functions.

  Important: If you have configured ActivID CMS to work with more than one type of directory, you may need to specify the directory type by adding a suffix with the directory short name to the plug_in_name.link property key (for example, plug_in_name.link.msft-ad). For details about the directory short names, see Configuring the Generic Plugin.

Guidelines to Set Up Non-Enrollment Plug-In Types

Use the following list of guidelines to set up non-enrollment plug-ins:

Important: If you have configured ActivID CMS to work with more than one type of directory, you may need to specify the directory type by adding a suffix with the directory short name to the plug_in_name.input and plug_in_name.output property keys (for example, plug_in_name.input.msft-ad).. For details about the directory short names, see Configuring the Generic Plugin.

• Set the plug_in_name.input to the list of attribute names whose values are passed as input to the server plug-in. (This invokes the method.)

• Set the plug_in_name.ouput to the list of attribute names whose values are returned as output from the server plug-in. (This invokes the method.)

• Add the plug-in name to the server plug-in list corresponding to the logical step where the plug-in is to be invoked. (This invokes the method.) For example, to declare the GenericPluginSample1 server plug-in on the user information retrieval screen of the device issuance process, the entry in the generic_plugin.properties file should look like the following example:

  Copy

  USER_INFO.plugin.server = GenericPluginSample1

Guidelines to Set Up Enrollment Plug-In Types

Use the following list of guidelines to set up enrollment plug-ins An enrollment plug-in is involved every time a user attribute is set or retrieved by ActivID CMS. This makes it possible to map user attributes to repositories other than ActivID CMS’ standard LDAP (for example, such as IDMS, databases, or XML files).:

To identify the plug-in as an enrollment plug-in, add a comma-delimited list of the EnrollmentPlugins at the beginning of the generic-plugin.properties file as illustrated next:

Copy

EnrollmentPlugins=GenericPluginSample1,GenericPluginSample2

Copy your own .jar file and third-party packages to the following directory:

cms_install_dir\aims.war\WEB-INF\lib

Where cms_install_dir is the ActivID CMS installation directory.

Important: The cms_portal directory, used in previous versions of ActivID CMS, no longer exists. With the migration to WildFly in ActivID CMS 6.0, that directory is now called aims.war.

Compiling a Generic Server Plug-In

To compile the generic server plug-in, the following external .jar files must be added to the project:

• aims-spi.jar

• ac-interfaces.jar

• slf4j-api-2.0.12.jar

These files are located in the cms_install_dir\aims.war\WEB-INF\lib directory, where cms_install_dir represents the installation directory of ActivID CMS.

Deploying a Generic Server Plug-In

To deploy a generic server plug-in, complete the following steps.

1. Export GenericPlugin as a .jar file (GenericPlugin.jar).

2. Stop the ActivID CMS server.

3. Copy the .jar file into the %PROGRAMDATA%\HID Global\Credential Management System\custom.war\WEB-INF\lib directory on the ActivID CMS server.

4. Add the package containing the plug-in to the class path for ActivID CMS.

5. Configure the generic plug-in using the %PROGRAMDATA%\HID Global\Credential Management System\Shared Files\generic_plugin.properties file.

6. Restart the ActivID CMS server.

Coding a Generic Server Plug-In

A server plug-in class must implement the following Java interface:

com.activcard.aims.plugin.generic.GenericPluginInterface