PluginDevelopment

1 Overview
2 Contents
3 Building a Plugin
- 3.1 Constructing the Service
- 3.2 Shibboleth Developers
  - 3.2.1 The Service definition
  - 3.2.2 /META-INF/services/net.shibboleth.idp.plugin.IdPPlugin
- 3.3 Constructing the Implementation Project
  - 3.3.1 Dependency Management
  - 3.3.2 Dependency Collection
  - 3.3.3 Managing the Version
- 3.4 Constructing the Distribution Project
  - 3.4.1 Distribution Pom example
- 3.5 Maintaining the Update Property File
  - 3.5.1 Properties
  - 3.5.2 Wildcarding the Version
  - 3.5.3 Example
- 3.6 Managing Packages 5.2
  - 3.6.1 Example

Overview

Plugins are a mechanism to securely introduce function into an IdP in a manner which does not require lockstep versioning with the IdP. They do not include, by themselves, any configuration, but part of the functionality that they include can be (and usually is) one or more Modules.

The Plugin Installer and the IdP Installer work together to insert the plugin's content into the war file of a deployed IdP. A plugin adds functionality by arranging jar files to be included into the WEB-INF\lib folder of the war file. Other resources are expected to be produced by enabling Modules and should usually be embedded within one of the plugin's jars.

Given that the war file is the only thing a plugin contributes to, configuration issues are out of scope for a plugin. Configuration management is delegated to the Module abstraction.

webapp
- Contains the contents which will be included into the war. There must be at least one jar file contained inside webapp\WEB-INF\lib and the jar files in that folder must implement exactly one service of type net.shibboleth.idp.plugin.IdPPlugin
bootstrap
- This folder:
  - MUST contain a file called plugin.properties.
    - This should be a property file with at least one property, "plugin.id".
    - The ID is used to locate the default truststore that verifies the GPG signature. The trust store will reside within a folder, named after the plugin ID, nested inside the IdP's credentials folder, e.g., idp.home/credentials/<pluginid>/truststore.asc
    - It must match the plugin ID that the plugin identifies itself with. By convention, plugin IDs are associated with the package name of the plugin to ensure uniqueness.
  - MAY contain a file called keys.txt being the public key(s) used to sign the distribution. This enables the plugin installer to perform a one-time, "leap of faith" credentials check, and thereafter to prevent use of an unauthorized key.
Packages^5.2
- This folder contains any tar.gz or .zip files which the plugin installer will unpack. See below

Building a Plugin

Given the constraints above you can use any mechanism you chose to build a plugin. However the format of the archive (and its signature) is conducive to being created automatically by maven and the IdP distribution contains support classes for constructing the service.

When doing this it is usual to have two subprojects. One contains the code for the plugin and the other uses the output of the first to build the package.

Constructing the Service

The easiest way to construct a plugin service is to build a class derived from the PropertyDrivenIdPPlugin class. This uses a property file to implement the IdPPlugin interface.

Shibboleth Developers

Shibboleth developers ONLY use the subclass FirstPartyIdPPlugin which references the Shibboleth "standard property" file location that manages plugin compatibility metadata (https://shibboleth.net/downloads/identity-provider/plugins/plugins.properties), which is the only file in the java-idp-plugin-mgmt project.

Build the implementing class by deriving it from the PropertyDrivenIdPPlugin class and supply the class as the parameter to the constructor.

The Service definition

package org.example;
public class ExamplePlugin extends PropertyDrivenIdPPlugin {
    public ExamplePlugin () throws IOException, PluginException {
        super(ExamplePlugin .class);
    }
}

Declare the class as a service by creating the /META-INF/services/net.shibboleth.idp.plugin.IdPPlugin file.

/META-INF/services/net.shibboleth.idp.plugin.IdPPlugin

org.example.ExamplePlugin

Create the properties file used to implement the plugin service. This is a file in the same package as the implementing class and has the name plugin.properties

plugin.id = org.example.ExamplePlugin
# Only used when package manifest is not available, such as within Eclipse
plugin.version = 1.0.0

The full list of properties is:

Property	Required?	What	Description

Property	Required?	What	Description
plugin.id	Y	Identifier	This is the unique identifier by which the plugin is described. It is used when manipulating the plugin (for instance doing an update). NOTE This file name and property name are purposely the same as required in the bootstrap location of the distribution. This enables one file to be used. See below.
plugin.version		two or three dot-separated numbers	This is current the version of the plugin. If configured correctly, the PropertyDrivenIdPPlugin class will use the version derived from the manifest of the containing jar to provide the version. This is a fallback if the manifest cannot be located.
plugin.license		location (in a jar file) of a text file	This is the (in jar) location of a file containing any licensing details. It is used only when the deployer requests it, and satisfies the spirit of providing the relevant licenses for a plugin. plugin.sh --license org.example.shibbolethplugin.ExamplePlugin
plugin.url.0 plugin.url.1 ...	Y	URL	These are the URLs where the plugin compatibility property files (below) are located. Multiple locations may be specified to allow for redundancy.
plugin.modules.required		Space-delimited list	The names of any modules which need to be enabled before the plugin installer will install this plugin. This is the only sense in which plugins may "depend" on other plugins; it's the module(s) exposed by those plugins that are identified as required.
plugin.package.n.source^5.2		Classpath location	The location of a zip or tar.gz file to be unpacked by the plugin installer. See below
plugin.package.n.destination^5.2		Filesystem location	The directory to unpack the package to. See below
plugin.package.n.windows^5.2		true or false	Should the package be unpacked on Windows platforms. Default is true
plugin.package.n.nonwindows^5.2		true or false	Should the package be unpacked on non-Windows platforms. Default is true
plugin.package.n.stripTopLevelDir^5.2		true or false	Should the top level directory of the package be skipped when unpacking. Default is true.

Constructing the Implementation Project

In constructing the POM for the implementation project, you need to pay attention to three aspects: dependency management, dependency collection (for use in building the package) and managing the version. The Plugin Archetype may help.

Dependency Management

Any code you rely on from the IdP should be scoped "provided". You should avoid dependencies on impl modules.

Be careful in your use of IdP versions. In general you should build against the lowest version of the IdP that you support (i.e. the version you specify as idpVersionMin)

Any code that you require to be shipped along with the plugin should be declared as "compile" or "runtime". Transitive dependencies of your plugin should only be mentioned if they are not IdP-provided (philosophically, a provided jar cannot have a dependency since you are not providing it, you are relying on it). However you must mention those transitive dependencies of your plugin which are not supplied by the IdP installation and these should be scoped as "runtime".

This last is not only good hygiene (so you know what you are using) but also a requirement for dependency collection (see below).

Dependency Collection

The following plugin stanza will copy the "compile" and "runtime" dependencies into a directory from which they can be collected by the distribution project.

Managing the Version

The following plugin stanza will place the current version into the manifest,.

it is critical that the <name> be the path to your plugin's package and that it be terminated with a /

Constructing the Distribution Project

The distribution project is a simple "pom" package with one plugin - the assembly plugin to create the zip and tar.gz files.

Distribution Pom example

The work is all done in the assembly files. This collects together at several groups of files into the package

The webapp directory gets:
- The jar file created by the implementation project
- The dependencies assembled by the implementation project
- Optionally, any other files which may need to do into the idp.war file
The bootstrap directory gets:
- The shared property file
- Optionally, the file of keys associated with signing this distribution

The following example build the tar.gz. The zip version is similar, but may decide to preserve line endings for any rare text files.

Maintaining the Update Property File

An important motivation for plugin development is avoiding lockstep deployment with IdP versions. Further it is important that a plugin's IdP depenedencies can change over time. The information which describes a plugin's state and dependency is therefore not included in the plugin; rather it contains a URL. The URL points to a property file which contains information about the plugin and its versions and their IdP compatibility.

The plugin installer consults this URL to list all possible versions and their requirements (plugin -fl plugin-id) but also (and more importantly) to select and automatically download the latest version of the plugin for the current IdP version (plugin -u plugin-id)

Obviously this information can be changed at any time, allowing plugins to be retired or have their life extended.

One file may document multiple plugins and (of course) multiple versions of the plugin, so all property names are prefixed by the plugin ID and per-version properties are postfixed by the version.

Properties

The following properties should be provided:

Name	What	Description

Name	What	Description
PluginId.versions	Space separated list of versions (three dot-separated numbers)	The versions of the plugin which are available.
PluginId.downloadURL.<version>	A URL	The "directory" part of the the location of this version of this plugin.
PluginId.baseName.<version>	A file name	The "root" name of the two files which make up the plugin. The `downloadURL` is prepended and the four followig extension appended: .tar.gz .tar.gz.asc
PluginId.idpVersionMax.<version>	An IdP version (three dot-separated numbers)	The first IdP version that this version of this plugin will not work with. (exclusive)
PluginId.idpVersionMin.<version>	An IdP version (three dot-separated numbers)	The first IdP version that this version of this plugin will work with. (inclusive)
PluginId.supportLevel.<version>	One of Current OutOfDate Unsupported Secadv Withdrawn	A description of the current status of this version of this plugin. This property is solely a statement of API compatibility and the only semantic associated is that the plugin verb will only consider plugins with support level of Current for automatic update. The ‘Unsupported’ category is deprecated (since it confuses the notions of support and API Compatibility.

Wildcarding the Version

The dowloadURL and baseName for versions managed by a Nexus repository are usually predictable given the version number. Hence a simplified wildcarding is allowed for these two property classes.

If the property name contains the string %{version}, then properties for all declared version numbers will be defined with the %{version} string in both the property name and property value being replaced.

If the property name for a specific version is defined elsewhere, then for that property and that version only the replacement does not take place.

Example

Managing Packages^5.2

Packages are a way of distributing third party projects' distributions in a plugin.

A package is a collection zip or tarball which the plugin installer unpacks into the idp.home directory. On each installation any previous project will be removed and the contents reinstalled. The contents of the packages should not be edited by the deployer.

The unpacking of packages is managed via the Package subinterface Interface of the Plugin. It is more usual to configure it via the plugin property file as detailed above.

PluginDevelopment

Overview

Contents

Building a Plugin

Constructing the Service

Shibboleth Developers

The Service definition

/META-INF/services/net.shibboleth.idp.plugin.IdPPlugin

Constructing the Implementation Project

Dependency Management

Dependency Collection

Managing the Version

Constructing the Distribution Project

Distribution Pom example

Maintaining the Update Property File

Properties

Wildcarding the Version

Example

Managing Packages 5.2

Example

Managing Packages^5.2