The default configuration of the IdP relies on a component called a "DataSealer" which in turn uses an AES secret key to secure cookies and certain other data for the IdPs own use. This key must never be shared with anybody else, and must be copied to every server node making up a cluster.
An initial key is generated by the installer in a special kind Java keystore file called a "JCEKS" keystore, which stores secret keys instead of public/private keys and certificates. A parallel file also tracks the key version number. A tool is provided to regularly update this secret key (and increase the version), which can be pushed to cluster nodes and continually maintain the secrecy of this key. This should be done at least daily to limit the chance for, and damage from, exposure.
Each time the seckeygen utility runs, it generates a new iteration of the key and updates the key version number (and a date/time in a comment). It also maintains a limited number of earlier keys (defaulting to 3, set with the --count option), which should be set based on how often you run the script and how long earlier data used by clients needs to be readable. Any data written with the DataSealer is always encrypted with the latest version of the key, but any data encrypted with an older key can still be read as long as the key remains accessible.
To roll the key, a script similar to the following can be used in a scheduled task on one of the cluster nodes or a staging server:
#!/bin/bash IDP_HOME=/opt/shibboleth-idp $IDP_HOME/bin/seckeygen.sh \ --storefile $IDP_HOME/credentials/sealer.jks \ --storepass password \ --versionfile $IDP_HOME/credentials/sealer.kver \ --alias secret scp $IDP_HOME/credentials/sealer.* host1:$IDP_HOME/credentials/ scp $IDP_HOME/credentials/sealer.* host2:$IDP_HOME/credentials/