...
Shibboleth 3 adds a new key and pair of files that are used to encrypt the Cookie used to provide Client-side storage of session data. This is held in the sealer.jks and sealer.kver files. Periodically a chron job generates a new key pair which is added to the "sealer" files, because when a new key is generated the old key remains valid until session timeout guarantees there is no valid data still sealed with the old key.
Generic Spring Bean Parameters
The Yale Install Project stores parameters in the install.properties file (created from the Jenkins Install job parameters), plus the install-ALL.properties and the install-XXX.properties (where XXX is DEV, TEST, or PROD). These properties are loaded into the Maven environment and then the Ant environment of the Install Project and are available only during the execution of the Install job itself. Any As a result, any configuration file stored in Source Control as part of the resources/updateArtifactSubstituteVariables subdirectory of the Install Project can contain ${property.name} placeholders that will be replaced by the value of a corresponding property at Install time.However, at Shibboleth startup the Spring Framework has its own variable substitution logic. as the Ant script in the Install Project copies configuration files into the /apps/shibboleth-idp directory. This produces configuration files that have literal numbers and strings as values.
Shibblleth 3 fully embraces the Spring Framework, which has its own "variable substitution from parameter file" capability called Spring Execution Language. At startup, Spring replaces %{property.name} placeholders in its XML files with the corresponding values from the shibboleth-idp/conf/idp.properties file (and other *.properties files in the conf subdirectory).
Of course, Spring will also use literal values. So we have a choice to do the property substitution at Ant install time or at Spring initialization time. Both should work. When we want decide to use the Spring mechanism, we add a line at the end of way of doing business, the problem is to get a property value defined in one of the Install Job property files transferred to the idp.properties file used by the Spring runtime. To do this the idp.properties file is itself in the Install Project as resources/updateArtifactSubstituteVariables/conf/idp.properties, and because it is in the Install Project with generic formatSubstituteVariable directory at Install time an ${foo} expressions get replaced. So in Source Control Yale adds lines to that file of the form:
property.name=${property.name}This takes the value of the property named "
Then as this file is copied from the SubstituteVariables section of the Install Project to the /apps/shibboleth-idp/conf directory, the "${property.name" in the Install Project (that is from install.properties, install-ALL.properties, and install-XXX.properties) and puts that value in this line after the "=". So if the Install Project value is "yale.edu" then when it is substituted here the line written to conf/idp.properties becomes
property.name=yale.edu
Then the same value will be assigned to the same property.name during Spring initialization and will substitute in all the Spring XML where there is a %{property.name} expression}" is replaced by a string or number from the Install job properties files. Strictly speaking, it is not necessary for the Spring property name (on the left of the =) to be the same as the Install Project property name (on the right side) but it is simpler to remember when they are. This means that you have to be sensitive to the fact that %{foo} expressions in the resources/updateArtifact directory (which are not replaced by properties) are copied unchanged to shibboleth-idp and are then replaced logically at Spring startup from the values in idp.properties that are replaced during Install.
When in doubt, look at the files after running Install in a Sandbox and compare them to the Install project to see which change and which remain the same.
DataSources
In Shibboleth 2 a Datasource (a database connection pool configuration specifying the database url, jdbc class name, userid, and password) could be configured in a DataConnector element of the attribute-resolver.xml or it could be supplied by the container (the Web Server which is to say Tomcat or JBoss). There was, however, a scary comment in the Wiki that if you use Oracle as your database (which we did) then the Shibboleth provided DataConnector implementation did not work well and they recommended using a container datasource. So that is what we did.
...