This page is out of date and replaced by Plugin Installation
As discussions have continued the shape of the proposed solution has changed. Rather that rewrite the document I have added sections. It doesn't make for great readability, but it does make for easier re-review.
During the life of IdP V4 we want to put the framework in place to allow us move away from a monolithic approach where everything anybody might want is available to a slightly more modular approach. where deployers can select what services they want.
Examples might be
This documents explores the area.
Two key things have resulted from discussion so far
This name must be
The suggestion is to use the reverse DNS notation that the author controls hence
net.shibboleth.plugins.scripting.rhino could be used by the Shibboleth project because it owns the
*.shibboleth.net domain tree.
For a product called
dist/webapp-*(in a random order). This is this done after the population from
dist/webapp(as now) and before
post-edit-webappfolder to our distribution to allow us to force the jars we want.
postConfig.xmlto setup global beans
credentials/plugins-trust/net.shibboleth.foo/truststore.ascwhich contains the public PGP keys that the deployer has accepted for use with this plugin. See PluginTrust
List properties can be edited. For example
idp.service.attribute.filter.resources = shibboleth.AttributeFilterResources (or) #idp.service.attribute.filter.resources = shibboleth.AttributeFilterResources
idp.service.attribute.filter.resources = BEAN.idp.service.attribute.filter.resources.net.shibboleth.foo idp.service.attribute.filter.resources.OLD.net.shibboleth.foo = shibboleth.AttributeFilterResources
List merging is done using
And the installation is required (via preConfig/postConfig) to define
BEAN.idp.service.attribute.filter.resources.net.shibboleth.foo which is the list merge of what it needs plus
The install package is shipped as .tgz (Linux line ending) or .zip (Windows). The distributiin must be accompanied with an armoured detached PGP signatures.
The format of an unpacked package is
|not allowed (it is refreshed by the installation)|
Contains the bootstrap information for the plugin installer
|recommended (for licenses)|
Note: changes to this file will not be installed and so the name should change with changes to ensure that the customer site has up to date licensing documentation
wildcard copied to
The installation is driven from within the (unzip'd) package itself via the service interface. So the installer just needs to unpack, add
edit-webapp/WEB_INF/lib (in the package) to the classpath and fire up service API to see what it has to do.
The Interface will have methods to return (at least) the following
|Used as per above to uniquify file and property names|
0 or more property file names to add to
|0 or more files to add to the distribution|
|0 or more files and their location. The <Path> is relative to idp-home . The user will be prompted to download these (leap of faith). The alternative for them is to download this by hand.|
|1 or more locations where a property file can be located. The properties will include those with a name derived from the plugin Id.|
A list of property files and paired with a list of properties to merge. So in the example above if would be
The plugin ID and the initial keystore are included as text (so no suspect jar need be on the classpath) in a directory with is part of the package (but not installed) called "bootstrap". This contains two files
opertya file with a single property in it
keys.txtthe signing keys. This is optional. See PluginTrust
Uninstallation cannot occur because of any changes to the configuration will render the system unusable. As part of an upgrade the webapp parts of the previous distribution will be removed but nothing else.
Doing an update consists of collecting the new version, uninstalling the old version, installing the new one.
This has many different aspects. The four most important are:
Jars can now be sourced from four different types of place
If each supplies a jar which provides the same class, precisely which class will be used will be random.
I do not believe that it is sensible to check for this. so the best we can do is provide mitigation, probably via some orthogonal configuration. This might (for instance) be a series of regexps which would make up a black list of jars not to copy. How this is communicated is tbd.
There is a new IdP version. Will the modules work with it?
This Module has a new version. Can it be installed against the IdP?
We know the IdP version (it is written during install and upgrade to dist):
#Version file written at 2020-03-11T09:59:08.023Z #Wed Mar 11 09:59:08 GMT 2020 idp.installed.version=4.0.0 idp.previous.installed.version=3
Which of course doesn't help the "How do I update my IdP" story unless the plugin writers allow some spread of supported versions so allow staggered upgrade.
Out of scope however we should make the following recommendations (tbd whether this is a SHOULD or a MUST
The file is is located at the URLs pointed to by
getUpdateURLs(). Multiple locations allow for redundancy. The property names are derived from the plugin id , with the specific version appended where this is relevant. All three digits of the version information should be present and dot-separated.
|Property Name||Property Value Description||Example|
|A list of versions in arbitrary order. All three digits of the version must be present|
Space separated list of directories where this version is to be found.
Multiple values allow redundancy.
The file name. the following four suffixes will be added during download
The maximum (exclusive) IdP version supported.
Trailing version and ppatch levels of zero are inferred
The minimum (inclusive) IdP version supported.
Trailing version and ppatch levels of zero are inferred.
This is all done from within the IdP in an admin flow.
In a later release we might chose to have an external program - this would build a classpath from
# plugin update <pluginid>
URL+/package.jar.tgz.sig(or zip equivalents)
The initial install is made fraught by the whole "bootstrapping trust" thing. You have an artefact which you don't trust which is the only place you can do to find out it. For the initial bootstrapping of trust we do not want to run any code which we do not trust. The trick is therefore to
Given a putative IdP version "it can be seen that" one can test whether the installed plugins are compatible. This leads us to two options
Behind all this is a feeling that there is a "turtles all the way down" solution by which the IdP also exports most of the Service Interface and this can therefore be used to drive update detection and testing and even "download and update" the IdP.
IdP Updates Insert
IdP update needs to be modfiied to preserve the
Nothing special. We should have no interest in deploying special windows installation technology. Windows user can just do what everyone else does. Anyone smart enough to want a plugin probably wants to (a) not be running Windows and (b) owning their jetty install.
My ideas here are not well formed yet, but there seem to be at least three different areas
Of course there are two axes of "one off testing" and regression/unit testing, I think I'd sooner concentrate on the latter and leave the former as ad hoc testing as part of the development process.
Again, this is an area where my ideas are not well formed yet. Some observations
These come in two flavors
The plugins need to obey relevant licensing restrictions. The plugin architecture allow the optional install time download of files which can help this
Building the plugin will require some new dependencies. We need to be aware of them