...
| Table of Contents | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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.
...
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.
...