| Table of Contents |
|---|
Please review these release notes before upgrading your system. You should review all the versions subsequent to the one you're running prior to upgrade.
Known Issues
None at this time.
3.
...
4.
...
1.
...
4 (
...
October 11,
...
2023)
A new version of the Windows installer was released to patch a couple of minor issues and regressions within the IIS module.
3.2.3 (July 6, 2021)
| Jira Legacy | ||||||||
|---|---|---|---|---|---|---|---|---|
|
This is a patch update that fixes a regression in the RequestMap implementation introduced in V3.2.0. Earlier versions are not impacted by this bug but are of course subject to critical vulnerabilities so this is now the only safe version to use.
3.2.2.2 (June 22, 2021)
A new version of the Windows installer was released updating the IIS module to correct a critical security vulnerability.
All WIndows deployers on IIS should review the advisory and should update to this release at the earliest opportunityupdating libcurl to 8.4.0 to address a security issue and to ensure that a more modern curl version has been shipped in case of future vulnerabilities. Other than rebuilding dependent libraries to accomodate a DLL name change, no other changes were made.
3.4.1.3 (June 12, 2023)
A new version of the Windows installer was released updating xmltooling to 3.2.4 to address a security issue. OpenSSL was also updated to 3.0.9 and a bug preventing optimized reloading of metadata via HTTP/2 was also fixed.
3.4.1.2 (March 13, 2023)
A new version of the Windows installer was released updating zlib to 1.2.13 to address a security issue. The version of libcurl was also updated to 7.88.1 in the process.
The installer was also patched to avoid overwriting file system ACLs on upgrades.
3.4.1.1 (February 8, 2023)
A new version of the Windows installer was released updating OpenSSL to 3.0.8 to address multiple security issues. The version of libcurl was also updated to 7.87.0 since it had to be rebuilt anyway.
As a general piece of advice, OpenSSL continues to be endemically impacted by bugs around their support of the hopelessly convoluted PKIX specification, and SPs should be configured whereever possible to bar the use of this code by turning off the PKIX TrustEngine. Because the V3 SP defaults to including support for PKIX by default when no <TrustEngine> element is present in the configuration, it is a good idea to explicitly configure a single engine by adding this line somewhere inside the <ApplicationDefaults> element (if no other such element is present):
| Code Block |
|---|
<TrustEngine type="ExplicitKey" /> |
Note that enabling PKIX support does not inherently even allow for evaluation of certificates anyway. Using that feature requires extensions to SAML metadata to carry trust anchors that are very likely not present in any metadata seen in the wild.
3.4.1 (January 10, 2023)
| Jira Legacy | ||||||||
|---|---|---|---|---|---|---|---|---|
|
This is a small patch to address a few bugs, in particular:
Reinforcing the xmltooling library (V3.2.3, included in this Windows release) to block an unnecessary XML Encryption construct, related to the advisory issued for the IdP recently. The SP is not believed to be vulnerable, but this is a defensive measure.
Adjusting the default ACL on Windows when the SP is installed outside of “Program Files” to prevent open write access to the folders. Note that with the huge variety of IIS security configurations, you may need to further adjust ACLs if unexpected user accounts are being used by IIS, so test before use. We will revert this change if people encounter problems, and you MUST take responsibility yourself for any ACL rules on your own servers; do not rely on us to get this right for you.
A warning has been added to the log when systems do not configure an explicit value for the redirectLimit setting. The default for this setting remains liberal for compatibility, so the warning was requested to highlight that fact.
3.4.0 (November 3, 2022)
| Jira Legacy | ||||||||
|---|---|---|---|---|---|---|---|---|
|
This is a minor update containing a new setting suggested by a contributor (thus the unplanned minor version change) controlling retries when TCP connections to shibd are used. The other changes are minimal in nature.
The Windows package contains refreshed libraries, including precautionary security updates for OpenSSL and libcurl.
TLS Renegotiation Change on Windows
Because of the update to OpenSSL on Windows, there is an inadvertent change to the default behavior of the software when interacting with sources of metadata of IdP SOAP endpoints that do not support secure TLS renegotiation. This was permitted by default before and now is not. Should this be a requirement, it is possible to leverage the <TransportOption> element (either globally or in a specific <MetadataProvider> to re-enable the option for this (see OpenSSLTransportOptions).
3.3.0 (November 30, 2021)
| Jira Legacy | ||||||||
|---|---|---|---|---|---|---|---|---|
|
This is a minor update that contains a small number of fixes, one small feature addition, and a number of additional deprecation warnings for at risk features. This version also introduces changes to the supported platforms and to the packaging process.
This is expected to be the final feature update to the SP in its current form with the project’s focus shifting to radical redesign.
Deprecations
Deprecations are now handled with a common “Shibboleth.DEPRECATION” logging category for easier identification.
While deprecating a feature does not guarantee it will be removed and not deprecating something does not guarantee its continued support, we have tried to identify the most likely features that are at risk during the redesign process that will occur before a V4 is available.
Platform Support
macOS is now an unofficial platform and the macport of the SP will be maintained only on a voluntary basis.
Support for SUSE is now partial and limited to members only, and we encourage the use of the official packages that are included with it.
Official support and packages will now be provided for Rocky Linux 8 and Amazon Linux 2.
Support for CentOS 8 will officially cease with the approaching end of that platform’s fixed release cadence at the end of 2021. We would suggest moving to Rocky Linux 8 instead if you need a free equivalent, though we will likely continue to provide CentOS 8 packages if we can, and the Rocky packages will most likely work on it anyway.
RPM Packaging
The RPMs are no longer produced online by the OpenSUSE Build Service but using a local, Docker-based process. This is a much faster process for us but it expands and constrains what we can support at the same time. As a result, a number of older platforms for which we have been unofficially producing packages but not supporting for some years will not see further package updates starting with this release. We have no plans to remove those older packages from the mirrors.
| Note |
|---|
Going forward, we will be signing packages using a project member’s key, but since this key may change over time, you may find it necessary to occasionally refresh the repository definition file we provide at https://shibboleth.net/downloads/service-provider/RPMS/ |
3.2.3.1 (August 2, 2021)
A new version of the Windows installer was released to patch a couple of minor issues and regressions within the IIS module.
3.2.3 (July 6, 2021)
| Jira Legacy | ||||||||
|---|---|---|---|---|---|---|---|---|
|
This is a patch update that fixes a regression in the RequestMap implementation introduced in V3.2.0. Earlier versions are not impacted by this bug but are of course subject to critical vulnerabilities so this is now the only safe version to use.
3.2.2.2 (June 22, 2021)
A new version of the Windows installer was released updating the IIS module to correct a critical security vulnerability.
All WIndows deployers on IIS should review the advisory and should update to this release at the earliest opportunity.
Note that in fixing this bug in the SP, a very serious vulnerability in Microsoft’s Default Document module was exposed that causes cross-contamination of requests, where a previous request’s internal state affects the state of the following request for the default document. This manifests by exposing duplicated attribute data because the SP is appending one copy of the data to a previous copy it created already.
This can be worked around in most cases by setting exportDuplicateValues="false" for the affected content, but some duplicated data from the built-in variables set by the SP still exist even with this option.
3.2.2.1 (May 26, 2021)
A new version of the Windows installer was released updating libcurl to the latest releases to address a security advisory fixed in curl 7.77.0.
...
The most significant changes are additional settings and default behavior to accomodate the Google-imposed SameSite cookie change. By default, the SP now assigns SameSite=None automatically to a subset of the cookies it may create that are explicitly only usable in a cross-site context, such as cookie-based RelayState or POST recovery features. It can optionally adjust the SameSite attribute for the session cookies it creates as well, using the new sameSiteSession property, but defaults to leaving session cookies unmarked and subject to default browser handling.
| Warning |
|---|
Please note, this new behavior is incompatible with the default cookieProps setting of "http" because SameSite=None generally applies only to "secure" cookies. A future SP change will likely adjust this default to "https", but the log already warns about this setting, though non-specifically. Also note, the changes described above by default will degrade functionality for older Safari versions on macOS and iOS due to a bug Apple refused to backport a fix for. A workaround is provided to accomodate broken clients but is left off by default to avoid a permanent state of legacy compatibility, but can be enabled via the sameSiteFallback setting in the |
...
Additional changes have been appllied to the default configuration (NOT upgrades) to harden the redirection behavior of the system to limit the use of the SP as an open redirector. A redirectLimit setting of exact has been added to the <Sessions> element.
Attribute Filtering Changes
...
This is the first release of the third-generation Service Provider software. The key documentation links are located on the SP3 space Home page, such as System Requirements, Installation, and Upgrading material.
...
Absent explicit configuration, the default digest algorithm used when creating signed messages has been updated from SHA-1 to SHA-256, reflecting industry guidance and matching the IdP V3 default. If compatibility with older systems is required, the default algorithm can be explicitly set via the <ApplicationDefaults> element, or specific rules for those IdPs may be specified via <RelyingParty> overrides. Note that in the majority of deployments, SPs rarely sign (and rarely need to sign) anything except for SAML logout messages.
...
SAML 1.1 support is not enabled by default; add back the string "SAML1" inside the <the <SSO> element to enable it.
Support for Attribute Queries is not enabled by default to eliminate a common source of confusion. This will impact behavior when interacting with out of date Shibboleth IdPs relying on SAML 1.1 without pushed attributes. Such systems should be migrated to SAML 2.0, but query support can be re-enabled if necessary by adding <AttributeResolver type="Query" subjectMatch="true"/> to the <the <ApplicationDefaults> element.
The default <TrustEngine> configuration (when nothing is specified, as in most cases) is now ExplicitKey-only and does not enable PKIX support.
...
Thus, it is a relatively simple matter to "upgrade" one's configuration:
With the original configuration, verify a working system, and check the log(s) for any DEPRECATED warnings.
Fix any settings causing those warnings until they're gone.
Update the namespace at the top of the file.
Restart, test, and fix any straggling errors.
Most of the changed defaults noted above will not apply to such a migrated system since they depend on actual changes to the configuration, and the vast majority of deployments can simply do a bit of testing, make the bump, and be good to go.
...
A set of virtual hosts can be auto-assigned a distinct entityID without the creation of <ApplicationOverride> elements to do so, using the new entityIDSelf content setting. While this does not eliminate the overhead of managing metadata for each host, it does eliminate most actual configuration overhead within the SP itself.
...