As development proceeds, we will enumerate features that are removed (or expected to be) along with any expected workarounds. While these are not considered “official” removals until we’re closer to an alpha stage, anything listed here is pretty likely to stay “gone”.
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.
SAML AuthnContextDeclRef Support
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.
Assertion Export
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.
The more “traditional” use case involving the use of signed assertions as a token for other systems to consume is not really a use case we want to support but in principle it should be possible to use the hub to turn an entire assertion into a base64-encoded attribute as part of a session. That may not fit in a header (which is why we did the crazy callback thing originally) but it might be more straightforward in V4 to expose a similar callback feature that could pull any attribute out of a session, which is still much cleaner than the weird “export the count and callback URLs” machinery from V3. Input on any extant use of this feature may inform our decisions on that.