...
Don't confuse the use of port 8443 in these default configurations with the (historical, but less common recently) IdP use of port 8443 that is described belowin the next section. That's an entirely different matter that you need to think about separately, and it's easiest to do that if you eliminate the references to this port that exist by default first.
...
Historically, Shibboleth IdP deployments have required operated with a second HTTP connector for SOAP requests from Service Providers. This connector by convention usually listens on port 8443. The separate port is used primarily because the connector has generally relied on client certificate authentication at the TLS layer to authenticate requests from SPs. It's possible to host these SOAP services on the same port as the rest of the IdP's services, but this requires used to require changes to SP configuration, so is beyond the scope of this introductory topic.
...
The IdP to date supports only a limited form of logout that does not propagate notifications to other SPs, so this is largely academic right now, but support for SOAP logout does require that the session store be on the server side, which is not the V3 default, and greatly complicates clustering. As a result, this isn't a feature likely to matter very much in most cases.
Back-Channel Support Implications
...
This is not a change from V2.
Lifecycle
The browser-facing key typically changes annually or semi-annually, and increasingly tends to be managed as part of a load balancer environment rather than on the IdP servers.
Signing Key and Certificate
...
In a non-updated install of V3, the generated signing key pair will be prefixed idp-signing (the names can be overridden if desired via the idp.properties file).
In V2, the generated signing key pair was named idp.key and idp.crt (the names typically configured via relying-party.xml). An upgraded install of V3 will maintain the V2 approach and files by default.
...
Lifecycle
This keypair ideally never changes outside of a catastrophic event.
Back-Channel TLS Key and Certificate
| Tip |
|---|
This section only applies should you choose to operate the IdP over the second back-channel port, but can be ignored otherwise. |
A second key pair essential to the security of the IdP is the private key and certificate used to enable TLS on the back channel, discussed extensively above. Depending on the SAML options used, compromise of this key can also lead to total compromise of the IdP.
...
The V3 installer (when not upgrading an older installation) will generate a key pair to use for your back-channel TLS configuration. The certificate is communicated via a <md:KeyDescriptor use="signing"> element in SAML metadata. (The use="signing" XML attribute refers to authentication generally, which includes back-channel TLS.) While most of the content of this certificate is ignored by Shibboleth SPs, the name of the server hosting the TLS endpoint does have to match the certificate's CommonName or a subjectAltName extension, following usual TLS practice. The installer does this for you automatically as best it can.
The older practice of using the same key for both digital signing and back-channel TLS is still permitted but is discouraged to limit key usage to specific purposes, which is a more secure practice. In particular, there are many more known attacks in recent years that have compromised TLS server keys than on keys used "behind the scenes".
In a non-updated install of V3, the generated back-channel key pair will be prefixed idp-backchannel but the files are not explicitly referenced by the IdP configuration because they are meant for use by the container to configure its back-channel TLS connector/listener.
In V2, the back-channel key pair was also not part of the configuration but conventionally was the same as the signing key pair. An upgraded install of V3 will not generate a new key pair and is generally assumed to be reusing the existing back-channel configuration choicesback-channel configuration choices.
Lifecycle
This keypair ideally never changes outside of a catastrophic event.
Encryption Key and Certificate
...
In V2, this functionality did not exist and so no allowance for this existed in the configuration. An upgraded install of V3 essentially defers the timing of having such a key pair and some adjustments have to be made at some point later on. If you want to perform an upgrade using a clean install to start with, using the generated key pair is fine as long as you adjust your IdP's metadata shared with every SP to reflect the use of a separate key pair for this function, as noted above. Doing this while publishing metadata containing a certificate in metadata with no use XML attribute will cause problems.
Lifecycle
This keypair ideally never changes outside of a catastrophic event.
Cookie Encryption Key
A fourth key, also new to this version of the IdP, is an AES secret key used to secure cookies and certain other data by the IdP for its own use. This key is never shared with anybody else and is copied to every server making up a cluster.
An initial key is generated in a special kind of Java keystore file called a "JCEKS" keystore, which stores secret keys instead of 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) and thereby continually maintain the secrecy of this key. This should be done at least daily to limit the chance for, and the damage from, exposure.
Lifecycle
This is a secret key that should be regular updated, though this is not absolutely essential. A simple command-line tool is provided to update the keystore and maintain older key versions as required.
Other Keys and Certificates
...