...
Normally the configuration of keys and certificates for signing and encryption is found in conf/credentials.xml. To use this feature, it's necessary to move the critical beans defining these credentials out of this file and up into a globally visible place. The recommendation is to create a file called conf/admin/unlock-keys.xml and move the bean(s) you want to "defer" to that file (with a couple of minor adjustments).
You can copy all the Spring boilerplate from conf/global.xml and/or follow examples below, but the idea is to move the signing and/or encryption beans to this file, and then simply remove the lines referring to the private keys. You simply omit that part, and any such credential will initialize itself with only the certificate "half" in place, but no private key.
...
The PrivateKeys collection is where you provide pointers to the private keys to unlock and inject into the Credentials objects. These generally need to be turned into explicit Spring FileSystemResource beans to avoid problems with paths being misinterpreted as relative to the wrong location.
These two collections have to "line up" such that the position of the private key in one list is meant for the Credential in the same position in the other list.
...
As you can see, mostly this is a lot of boilerplate, and some cut and paste out of conf/credentials.xml that reuses the same properties typically used to define the paths to the key and certificate, entityID, etc. The use of a FileSystemResource class bean is usually required.
Because the existing signing Credential object is already assumed to be named shibboleth.DefaultSigningCredential, transplanting that with minor changes is possible. If you were defining additional keys yourself those names would be different.
...