Using the Generic Plug-In SPI with Non-CMS Repositories

This section introduces the fifth of the use cases—support for using 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. with non-CMS repositories. Use cases are comprised of subsections that briefly describe and define how some type of ActivID CMS functionality can be integrated into a custom application.

Use Case: ActivID CMS Fetching Cardholder Attributes from Non-CMS LDAP Directories

Use Case Goal

To make it possible for ActivID CMS to fetch and access cardholder data from repositories other than ActivID CMS-configured LDAP directories, create a server-side plug-in using the ActivID Generic Plug-In SPI.

Context

ActivID CMS manages cardholder (user) attributes. User attributes are those that are displayed when a user lookup is performed for a device issuance or in the Help Desk. User attributes can also be stored in or printed on the device itself. ActivID CMS creates users and prompts for user attributes whenever a new user is created. By default, user attributes are LDAP attributes. User attributes can be defined in ActivID CMS to be:

  • Prompted for on user creation (User Management)

  • Displayed on User Lookup and Help Desk

  • Updated at device issuance

  • Printable at card issuance

  • Sent to plug-ins (for example, to perform user information lookups, to be stored on smart cards or to prove an identity)

User attributes can be any of the following different supported types:

  • Text

  • Password (obfuscated when typed in)

  • Photograph (loaded as binary data from file).

There may be situations where user attributes need to be retrieved from and stored in repositories other than an LDAP directory configured using ActivID CMS.

A server-side generic enrollment plug-in 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). can be written to handle the retrieval of user attributes that are stored in non-LDAP repositories.

Objectives

Extend the ActivID CMS reach and its sources of user information.

Solution

To create a server-side generic enrollment plug-in that fetches attributes from a repository that is not the default LDAP directory configured using ActivID CMS, you can use the ActivID Generic Plug-in SPI. When ActivID CMS needs to read the value of an attribute that is managed by the plug-in, the getAttribute() method is called.

When ActivID CMS needs to modify the value of an attribute managed by the plug-in, the setAttribute() method is called. It is the role of the generic plug-in to communicate with a third-party repository (for example, an IDMS A collection of systems, processes, procedures, applications, database management systems, and interfaces that work together to manage and protect the identity information of PIV card applicants. The IDMS generally falls within the IDPRS domain., a database, another directory, or a CA).

Generic Plug-In Architecture

Examples

If a custom integration requires specific user attributes that are not included as attributes in the LDAP directory, but are in a third-party repository to be printed on or stored in the card, an enrollment plug-in can be developed to fetch those attributes when ActivID CMS needs them. In addition, if the value of any of these attributes is modified by ActivID CMS, the plug-in can be configured to modify those attributes in the third-party repository.

For More Information

For more information, refer to About the Generic Plug-In SPI.