| Note |
|---|
The plugin feature is available only in V4.1 and later of the software. |
| Table of Contents |
|---|
Overview
V4.1 introduces a new Plugins are a mechanism to install non-default functionality into the IdP called Plugins. from signed release distribution packages.
Plugins:
Are distinguished from each other by a unique identifier in the style of a Java package name.
Are revised on a different schedule to the IdP itself, so upgrading the IdP does not upgrade a plugin and equally upgrading a plugin does not affect the IdP. Often, significant IdP upgrades may require plugin upgrades, but the operations are distinct.
Must be GPG signed.
May be installed and updated directly from a web-hosted file or from a local file (with associated signature).
Generally has have no configuration that it directly installs, leaving this to the Module layer to manage.
May require one or more Modules to be enabled before they can be installed, this being controlled indicated by the plugin developer.
May automatically enable a Module on install and/or disable a Module on uninstall, this being controlled indicated by the plugin developer.
It is usual that a plugin contains one or more Modules, so the usual way to add functionality via a plugin is to install the plugin, then enable the module (if not already done for you) and then complete any per-module configuration.
...
At any time the Plugin developer can change the status of any released plugin from Supported (current) to
OutOfDate meaning: Still working but a new version is available
Unsupported: Out of Support
Secadv: Security alerts exist against this plugin
Withdrawn
There are no semantics associated with these beyond that only Current Supported versions are candidates for automatically selected update. The other states are there as (dynamic) guidance from the developer to the deployer of the state of the plugin.
...
All plugin manipulation (except trust store maintenance) is done via the plugin command. Operations fall into 2 broad categories.
Plugin Discovery and
...
Automated Installation
Information about plugins is always kept separate from the plugin itself. This same information can be used to discover which plugins are available at a given URL. The -L will list them. This defaults to using the URL which is shared by all plugins developed by the Shibboleth Team (and documented here). The --updateURL allows other locations to be used.
...
Short | Long | Parameter | Description |
|---|---|---|---|
-i | --install | File Or URL | Install the provided qualifier |
-u | --update | PluginId | Update installed plugin |
-r | --remove | PluginId | Remove the installed plugin |
-l | --list | Enumerate all installed plugins | |
-fl | --full-list | Give full version details for all installed plugins | |
-cl | --contents-list | PluginId | List all files installed by the specified plugin |
-L 4.2 | --list-available | List available plugins (i.e discover plugins which can be downloaded and installed) | |
-I 4.2 | --install-ID | PluginId | Install plugin from its ID. The plugin should be available at the default endpoint (or that specified by --updateURL) |
--noCheck | Do not check for compatibility with the current IdP Version | ||
--updateURL | Specify the update URL (for -L, -I or to override the plugin provided value) | ||
--license | PluginId | Output the license information for the specified plugin |
...
Short | Long | Parameter | Description |
|---|---|---|---|
--verbose | Verbose logging | ||
--quiet | Quiet logging | ||
--logConfig | a logback file | Specify a file to use to control the logging of the plugin command | |
--version | Output the version of the plugin command | ||
--propertyFiles | file list | Any property files that are to be included when parsing a Spring file input (see below) | |
--noPrompt | Use for unattended installs. | ||
--truststore | Path to the (non default) trust store file used during installs and updates. See above. | ||
--noRebuild 4.2 | If set then the war file is not rebuilt rebuilt after the installation. | ||
-fu | --force-update | Version | Used with the -u qualifier to force the update (or downgrade) to a specific version |
-hc | --http-client | bean nameBean ID | Allows specification of an HTTP client bean used to download updates (or perform any related Module operation). For details on wiring up a client bean, refer to the HttpClientConfiguration topic. |
-hs | --http-security | bean nameBean ID | Only used if the plugin installer needs to invoke a module operation, and allows security customization of the HTTP operation(s). |
...