Jetty, Windows and IdP 3.4

[Rod Widdowson]

After a fun packed week I have a plan for how to do the jetty install for the Windows Installer in 3.4.  I’m detailing it here to
allow some review. 

I should start by restating some of the requirements and underlying assumptions

* We want to ship Jetty 9.4 with IdP 3.4
* We are looking to a future in which we can provide a “starter kit” jetty-base for (non-windows) deployers.  
* On Windows, we minimise the configurability and scope of the embedded Jetty.
* On Windows we MUST respect current allowed configurations moving forward.
	
The bundled jetty which is available after a windows install has exactly one configuration file (jetty-base\start.d\idp.ini).  We
only guarantee to respect the settings to the properties listed in that file (when it was first installed).  However we MUST respect
these properties (although we allow ourselves the right to rename properties during install).

These constraints leads inexorably to the fact that we need to maintain a separate stream.  This can be rebased to the mainline
before every release, and those files forked from jetty must be reviewed as part of the release process to ensure that there is no
divergence.  I will make the step explicit in the documentation [1].

Below I list all the files that will differ between this stream and mainline.  I’ll also make some recommendations for changes to
the mainline.

start.d/idp.ini 
This is the sole point of configuration for windows installs. It will remain substantially unchanged.  

* Remove jetty.context.path , jetty.war.path and jetty.static.data.path  properties
   (prior to removing support for these properties in 4.0)
* Rename the properties to their new names
* Clean up comments, in particular with respect to absolute and relative paths
* This file will *NOT* contain and --module statements (they are a moving part we do not want to expose)
* I would suggest that the mainline version changes the setting of idp.war.path and jetty.war.path
   to make them system properties
                      -Didp.war.path=..\foo\idp.war
   See idp.xml below
* I would suggest that the mainline version not ship with the “changeit” password, but rather contain
   instructions on how to make the truststore the keystore.
	
start.d/idp-system.ini (Windows branch only)

A new “reserved to us” file which is there uniquely to contain the --module commands we need.

start.d/idp.ini.rewrite.property.names

* Remove from mainline.  
* Update in the windows branch to contain all the property name changes needed by Jetty 9.4

webapps/idp.xml

* Continue the previous version which allows use of properties to drive the context path and the war file path
* I suggest that the mainline version uses system properties.

webapps/static.xml 

* Leave as it is (using properties) BUT
* I suggest that mainline removes the use of properties and/or replaces them with system properties

modules/logback-logging.mod (Windows branch only)

This file is copied from the jetty distribution but with the section setting the system property (org.eclipse.jetty.util.log.class)
removed.  We move this setting up to the procrun configuration.  We need to do this because otherwise jetty forks and this breaks
the IdP in hard to diagnose ways.
	
etc/jetty-deploy.xml (Windows branch only)

This file is copied from the jetty distribution, but with the addition of start.d/idp.ini as a property file.  This allows the
property replacement in the webapps folder to work.

etc/idp-backchannel.xml

I suggest that in both branches we change the property names to be idp.
	
etc/jetty-ssl-context.xml (Windows branch only)

This file is copied from the jetty distribution , but with the following property setting removed.  
    KeyManagerPassword
    TrustStorePath
    TrustStorePassword
    TrustStoreType
    TrustStoreProvider
These changed are needed to allow the keystore and truststore to be the same file but only controlled by one set of properties.

In addition the spurious addition of jetty-base to the KeyStorePath is removed (allow absolute paths in idp.ini which we allowed
(and possibly even encouraged) in previous versions

And In 4.0 ?

* Remove support for the jetty.war.path and idp.context.path properties.  This might allow us to remove jetty-deploy.
* Unless (until?) jetty changes, we are constrained to ship jetty-ssl-context and logging-logmack.mod
* We could remove the backchannel stuff (although that has been the easiest part of the 9.4 upgrade process)

Rod

[1] https://wiki.shibboleth.net/confluence/display/DEV/V3WindowsInstaller