...
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.
...
The full list of properties is:
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 |
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 | 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. |
Constructing the Implementation Project
...
The following properties should be provided:
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
|
.zip
| ||
PluginId.idpVersionMax.<version> | An IdP version (three dot-separated numbers) | The first IdP version that this version of this plugin will not work with. |
PluginId.idpVersionMin.<version> | An IdP version (three dot-separated numbers) | The first IdP version that this version of this plugin will work with. |
PluginId.supportLevel.<version> | One of
| 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.
...