COmanage Registry supports several types of Plugins in order to easily customize and extend Registry functionality. In addition, you can write your own plugins to customize Registry to work in the ways and with the systems that you need. This page provides background about COmanage Registry plugins including how to make them available to your instance of COmanage, a description of each of the plugin types with a list of the known plugins of each type, and references to documentation to create your own plugins.

On this Page

1. About Plugins

1.1. Installing Plugins

There are a few different ways to make Plugins available for use within Registry, according to how the Plugin is distributed.

  1. Core Plugins - Commonly used. These plugins ship with COmanage and enabled by default.
  2. Supported Non-core Plugins - Less widely used. Shipped with COmanage, but not enabled by default.  
  3. External Plugins - Finally, Plugins can come from other sources (including those you write yourself) to support your needs.

1.1.1. Core Plugins

Many Plugins are already set up, and provided as “Core Plugins”; these Plugins ship with COmanage, and are enabled by default. They can be found in the app/Plugin directory.

1.1.2. Supported Non-core Plugins

In addition, there are some Plugins that are less widely used. While they are shipped with COmanage, they are not enabled by default because of the related overhead (and, in some cases, external dependencies) associated with Plugins that may only be useful to some deployments. These plugins are also shipped with Registry and can be found in the app/AvailablePlugin directory.

The simplest way to enable a Non-Core Plugin (assuming you have met any external dependencies the Plugin may require) is to symlink it from your local/Plugin directory.

After creating the symlink, you should clear caches and then update your database schema to reflect the newly available plugin.

Enabling a Non-core Plugin
$ cd $REGISTRY/local/Plugin
$ ln -s ../../app/AvailablePlugin/SomePlugin .
$ cd $REGISTRY/app
$ su -c "./Console/clearcache" ${APACHE_USER}
$ su -c "./Console/cake database" ${APACHE_USER}

1.1.3. External Plugins

Plugins that come from other sources (including those you write yourself) should be placed in the local/Plugin directory.

1.2. Configuring & Using Plugins

Once a Plugin is installed and enabled for use, how it is actually used and/or configured varies according to the Plugin type.

Plugin TypeDescriptionWhere the plugin is configured in COmanage
Authenticator

Authenticators are used to prove a CO Person's identity to an application or service. An Authenticator combined with an Identifier is a credential.  Because Authenticators are collaboration issued, they are attached to the CO Person, not to Organizational Identities (as for external credentials).

Configuration > Authenticators
Cluster

Clusters are used to represent a CO Person's accounts within a given application or service. The typical use case is managing accounts on (eg) one or more Unix servers, but there is no specific requirement for this type of service. Clusters could just as easily represent accounts in a wiki service, if there were a need for more sophisticated provisioning beyond simple user attributes (identifier, name, groups, etc).

Configuration > Clusters
Dashboard Widget

Registry v3.2.0 introduces Dashboards, simple information portals. Information is provided by Dashboard Widgets, which are implemented as Dashboard Widget Plugins. Multiple Dashboards can be defined within a CO. Dashboards include header and footer text areas appropriate for providing arbitrary html content on the landing page of a CO.

Configuration > Dashboards
Data Filter
Configuration > Data Filters
Enrollment Flow
Configuration > Enrollment Flows
Identifier Validation
Configuration > Identifier Validators
Invitation Confirmer

Job

LDAP Schema

Normalization

Organizational Identity Source
Configuration >  Organizational Identity Sources
Provisioner

Provisioning refers to the action of using Registry data to create or remove access to applications and services. COmanage Registry uses provisioning to provide the data that it stores to applications using one of three models, and in four different modes: Automatic, Manual, Enrollment-based, and Queue-based.

Configuration >  Provisioning Targets

1.3. Creating Your Own Plugins

Building your own plugin is a great was to get started with custom development for COmanage. Through plugins you can build powerful extensions to the existing Registry functionality. Building a Registry Plugin requires knowledge of PHP, CakePHP, and COmanage.

1.3.1. Start Here

The general documentation for building plugins can be found on the Writing Registry Plugins page. All plugins follow some standard conventions which are outlined on this page. In addition, some types have additional requirements as listed below.

1.3.2. Additional Requirements by Plugin Type

As described above, there are several different Plugin Types, each with their own additional requirements. You can find these details at the links below:


2. Plugin Library

Below is a list of known plugins that are available to the COmanage Registry community. Please let us know if you know of other plugins that are not listed below. (Or, maybe you have created your own plugin that you want to share here!)

2.1.1. Authenticator Plugins

  • Page:
    Certificate Authenticator Plugin — The Certificate Authenticator plugin manages information about X.509 Certificates for CO People. (experimental)
  • Page:
    Password Authenticator Plugin — The Password Authenticator plugin manages passwords for CO People. (experimental)
  • Page:
    Privacy IDEA Authenticator Plugin — The Privacy IDEA Authenticator plugin provides an interface for tokens managed by a privacyIDEA authentication server. These tokens can be used to implement Multi-Factor Authentication (though instructions for doing so are beyond the scope of this document). (experimental)
  • Page:
    SSH Key Authenticator Plugin — The SSH Key Authenticator plugin manages SSH Public Keys for CO People.

2.1.2. Cluster Plugins

2.1.3. Dashboard Widget Plugins

2.1.4. Data Filter Plugins

  • Page:
    Data Scrubber Filter Plugin — The Data Scrubber Filter Plugin filters which attributes are passed from an Organizational Identity Source.
  • Page:
    Elector Data Filter Plugin — The Elector Data Filter evaluates available attributes and elects one based on configured Precedence Rules. The elected value is passed to the associated Provisioning Target.
  • Page:
    Group Filter Plugin — The Group Filter Plugin filters which CO Groups are passed through to the connected context. Rules are processed for each CO Group passed to the Group Filter Plugin.
  • Page:
    Group Name Filter Plugin — The Group Name Filter Plugin replaces a CO Group Name with an Identifier, so that the name of the CO Group appears to be the Identifier.

2.1.5. Enrollment Flow Plugins

  • Page:
    DuplicateCheckEnroller Plugin — The Duplicate Check Enroller Plugin checks whether the enrollee has been registered in the past thus preventing Enrolling again and creating duplicates. The check takes place after the start step of the Enrollment Flow. This means that the Enrollment flow should have an Introduction text configured.
  • Page:
    IdentifierEnroller Plugin — The Identifier Enroller Plugin allows the enrollee to select one or more identifiers as part of the enrollment process. This happens after email confirmation (and so after the initial petitioner attributes are collected).
  • Page:
    MeemEnroller Plugin — MEEM is the MFA Enrollment and Exemption Manager. It is intended to coordinate enrollment in Multi-Factor Authentication. MEEM does not work with any specific technology, but is intended to work with Enrollment Flows and, indirectly, Authenticators.
  • Page:
    NationalityEnroller Plugin — The NationalityEnroller allows a Petitioner to self assert their national affiliation(s), which are then stored as Identity Documents, with a Document Type of Self Assertion. This plugin supports Attribute Enumerations for the attribute Identity Document (Issuing Authority, Self Assertion).
  • Page:
    ServiceEligibilityEnroller Plugin — The Service Eligibility Enroller Plugin allows for Registry Services to be selected for a CO Person Role. Despite its name, the Service Eligibility Enroller can be used without Enrollment Flows.

2.1.6. Identifier Validator Plugins

2.1.7. Invitation Confirmer Plugins

Content by label

There is no content with the specified labels

2.1.8. Job Plugins

2.1.9. LDAP Schema Plugins

Content by label

There is no content with the specified labels

2.1.10. Normalization Plugins

Content by label

There is no content with the specified labels

2.1.11. Organizational Identity Source Plugins

  • Page:
    API Source — The API Organizational Identity Source Plugin is designed to integrate using RESTful APIs and message buses.
  • Page:
    Env Source — The Env Organizational Identity Source Plugin is designed to pull attributes from environment variables, generally populated by web server authentication modules.
  • Page:
    File Source — The File Organizational Identity Source Plugin is designed to integrate using CSV files.
  • Page:
    LDAP Source — The LDAP Organizational Identity Source Plugin is designed to integrate with an LDAP server.
  • Page:
    netFORUM Source — The netFORUM Organizational Identity Source Plugin is designed to integrate with the Abila netFORUM Association Management System via the XML API (xWeb).
  • Page:
    Novi Source — The Novi Organizational Identity Source Plugin is designed to integrate with the Novi Association Management Software platform using the Novi AMS API.
  • Page:
    ORCID Source — The ORCID Organizational Identity Source Plugin is designed to integrate with the ORCID API in order to create Organizational Identities and to securely link an ORCID iD to an existing CO Person Record.
  • Page:
    Salesforce Source — The Salesforce Organizational Identity Source Plugin is designed to integrate with Salesforce via the Force.com REST API.
  • Page:
    SQL Source — The SQL Organizational Identity Source Plugin is designed to integrate inbound data via a SQL database. SqlSource is available as of Registry v4.1.0.

2.1.12. Provisioner Plugins

2.1.13. Vetting Plugins