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”.
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.
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.
Application Overrides
It's difficult at this stage to fully describe without preliminary configuration examples, but the plan is to eliminate the concept of an “Application” from the agent while retaining the concept in the hub. There’s material about this design plan in the wiki elsewhere, but essentially the aspects of the Application model that pertain to SSO protocols (i.e., SAML) and to attribute handling are going to be possible to manage in the hub in a similar way. Agent configuration will continue to be responsible for mapping URLs to the associated application, but these application designations will only be “real” in the hub, so it’s a way to connect URL space to hub configuration indirectly. Because the hub is in Java, the application configurations will be reloadable (and possible to externalize to some extent) in much the same way as now.
Meanwhile, the aspects of the Application model that pertain to agent behavior are going to largely be extracted and devolved to content settings expressible via the RequestMap (or Apache settings). This will include the ability to express both session boundaries and to customize the existence and behavior of Handlers differently for different sets of content.
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.