...
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.
We maintain a directory of known plugins.
Plugin Versioning and IdP Versioning
...
The IdP plugin developer then develops version 1.2 of the Plugin which requires at least version 4.2.0 This is released and the versions specified for this version are 4.2,.0 and 6.0.0.
At any time the Plugin developer can change the status of any released plugin from Supported (current) to
...
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.
...
These define which operation to perform.
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 |
Other Qualifiers
These provide extra/advanced options for the command:
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 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 name | 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 name | Only used if the plugin installer needs to invoke a module operation, and allows security customization of the HTTP operation(s). |
Optional Parameter
Finally the plugin command can take one additional bare parameter - the path to a file which contains any native Spring bean definitions that may be needed. This is typically only required for the -hc
and -hs
qualifiers to perform advanced customization of HTTP operations, and should be rare.
...