Page Comparison

...

Outbound SAML Artifact Binding Support

This does NOT refer to supporting IdPs that use the SAML Artifact binding to issue responses (the callback model that is similar to how CAS and OpenID typically function) but to the virtually unused capability to issue SAML requests to an IdP by sending artifacts and relying on IdP callback into the SP to resolve the message. This feature was more of an “accident” of the SAML design than a real feature anyone needed or used and we won’t be supporting it.

Workaround

None. The normal request process relies on redirects and so there is no obvious reason to use this feature, and most non-Shibboleth IdPs don’t support it anyway.

Inbound SOAP Single Logout Support

The SP supports SOAP-based logout inbound, but this is difficult to successfully implement given the common (bordering on universal) use of application sessions independent from the SP. Given the complexity of supporting SOAP inbound, it is planned to remove the feature in favor of front-channel logout support only. This is not a totally firm decision, but would be a helpful reduction in code.

Workaround

Switch to front-channel logout.

SAML-Specific Naming of Features

A number of features/settings will probably get renamed to be more portable and less SAML-specific. This will probably include anything based on the “entityID” term, anything based on SAML-specific fields such as “AuthnContextClassRef”, etc. In most cases, they will simply have more generic names replacing them. We’ll make some case by case determinations about removal vs. deprecation.

Workaround

Unless noted otherwise, these will be naming changes in general, not actual removal of features. These are typically configuration settings, and not likely to impact application code.

...

The old session objects contained a SAML 2.0 AuthnContextDeclRef if one was used in place of a class reference in the assertion. DeclRefs are virtually unused and are SAML-specific and hard to “abstract” into a more general representation. This also extends to removal of the dedicated authorization rule support in both XML syntax and Apache.

Workaround

The “claims/attributes” mapping features should be substantial enough such that the hub can extract a DeclRef into an attribute that could be mapped to any desired name (such as the old name used in the standard exported variable set). The authorization rules can be adjusted to check for an attribute/value.

...

This is regarding the feature outlined in AssertionExport. It’s a lot of code to implement for a very small number of use cases that are probably fairly historical for the most part since using SAML assertions for anything but SSO these days has been replaced by OAuth. It was quite complex for an application to use as well, so is planned for removal.

Workaround

One of the use cases for this was sometimes advanced extraction of custom data from assertions. That will be much simpler to implement in Java in the hub to populate attributes from the custom data.

...

Essentially what was originally handled inside the SP will be divided into two sets, and the agent aspects simplified as much as possible to reduce the complexity for application deployers and moved to hub deployers.

Workaround

None per se, but it will become more important than ever to get people to stop misusing overrides for many use cases already addressed such as overriding an SP’s entityID based on content. That will be handled, but differently, by allowing hubs to compute the setting in dynamic ways in Java/JavaScript, much as the IdP supports. This will also allow plugging a hostname into an entityID pattern much as now. Bottom line, things that don’t require an override now will be even more awkward to use overrides to address, so it will be important to transition off of them for those cases.